Let’s have a walkthrough of how we created a mass product for Bitrix24 & Asterisk integration powered by FreePBX.
Background
At the end of 2016 we had a call-center solution based on on-premise Bitrix24 almost ready. Almost means that SIPML5 fork used for WebRTC processing in browser was not working completely smoothly.
We were planning final testing and release when in December telephony support in Bitrix24 REST API showed up. With this came a need to integrate Bitrix24 and Asterisk by newly released REST API methods.
This happened just in time as Voximplant and Bitrix24 cluster required an extra layer, and this meant beating around the bush in settings and left Asterisk-lovers with no freedom at all. Moreover, part of call processing logic together with SIP and RTC traffic were given to an external system.
We decided to put off contact centers for a while. We were going to fulfill an order and fill in a void which would result in the integration of the product for everyone.
MVP
It turned out that the colleagues were using as many as three Asterisks: one with the customized context and two others connected to the first one. It complicated initially an easy task: to find a responsible manager, to open a profile, to record the call in CRM.
“Really, a copybook performance” — one geek says, — involving not more than four hours”. And that is the point. If you code for your own needs, then you can limit yourself to a few scenarios. But any deviation adds on 4 hours. However we were developing a solution for everyone. That meant that it was not easy for the developers but resulted in a user-friendly experience for the user.
The solution is based on framework FreePBX v.13. It was the most popular among the analogues at that time. It was advancing rapidly and included all the things needed for our solution.
The main part was performed as a module for FreePBX. The advantages of the 13th version of FreePBX that we used: updated interface, pop-ups at module configuration, AJAX support, module updating process was simple and included table structural changes.
It’s of high importance to define corresponding integration contexts. After all, each client has its own call processing scheme.
Today we are working mainly with contexts ext-did-001, ext-did-002 and macro-dial-one for inbound calls и outrt-, macro-dialout-trunk — for outbound.
So, it took two months to integrate Bitrix24 and Asterisk. Bitrix24 CRM all-seeing eye is monitoring incoming and outgoing calls.
We gained a lot of valuable experience working with the Bitrix24 team. Our time was well-spent. Some bug reports were being closed within one day. At the end of March the beta version appeared in the Bitrix24 marketplace.
First results
Creating MVP we followed simple logic. For instance, call starting and ending time is linked to external caller channel, i.e. with the incoming call it’s the first channel opened, with the outgoing it’s a channel with a destination number. Backlog didn’t include support of Ring Groups and FollowMe. But this didn’t affect functionality as they are substituted by Queues.
The results were not long in coming: within the first few days we saw 15-20 installments a day. We tested our hypothesis. Beta-version had a rather basic MVP but it worked for users. And it greatly encouraged us. It also encouraged users to give us valuable feedback.
With care about users
Most of Asterisk installations are cut off from the outside world. They are working perfectly behind NAT. Nevertheless, it was astonishing to get such a pull of questions from system administrators on how to configure the Firewall.
«Port forwarding? Sure, we are aware of it. But what and where is it to be forwarded?».
The problem lie not in users qualification but in data submission. Instructions did not help either. We elaborated on the interface and the questions stopped.
It’s considered to be all the same for system administrators which interface to work with. This is not how it turned out to be. Whoever the user is to be, a system administrator or a housewife, the simpler interface the more the users like it. With that in mind it was unbelievably difficult to make it simple, especially considering ongoing changes. While we were beta-testing, we were trying to release as many as one update a week.
Module interface evolution
Each week brought about new features and the internal logic was changed. The product was evolving rapidly. With every new version previously collected analytics became outdated. At times, technical innovations outran interface changes. Then we had to correct or totally reconsider user’s scenarios. This resulted in significant interface changes.
High development dynamics imposed constraints on interface designing. We set ourselves a challenging task, that is to develop a user-friendly application to bind Bitrix24 and Asterisk. And we nailed it! Now everyone can do that.
In lieu of an epilogue
Thanks to our support team a month and a half of beta-testing let us perform tens of scenarios and check numerous assumptions. We gave up writing tickets and emails at once. These do not generate a quick response and, thus, may prolong a simple request for several days.
Open lines in Bitrix24 came extremely helpful. Both ourselves and the clients were using the same product. A client could always find our open line in the list of their chats and trace back the whole conversation history. We have tasks, internal communication and communication with clients all in the same place.
Our clients receive a response on average within three minutes. The client is satisfied and share with us not only problems but also feedback on how to improve the product.
When a stable-version was released we had to limit ourselves to experiments.
Assembly and testing, and also installment and module performance in Docker-containers were automated on GitLab CI. Updates are now delivered once a week and all the experiments were brought to beta-branch. Beta-testers are welcome!
This is the end and the beginning.
