Happy ending story: Bitrix24 integration with Asterisk
Today CRM and telephony integration is vital. If the client listens to the automatic greeting for too long or you do not call back on the application left by him on the site, you will lose it.
How we, the integrator company informUnity , came to the creation of a mass product for the integration of Bitrix24 and Asterisk running FreePBX, and what came of it - under the cut.
Background
By the end of 2016, we had an almost ready-made solution for contact centers based on the boxed Bitrix24 and Asterisk. In practice, because the SIPML5 fork used to handle WebRTC in the browser has not yet been debugged.
We already planned the final testing and launch of the replicated product, when in December there was support for telephony in the Bitrix24 REST API. And with it, colleagues needed to integrate Asterisk and Bitrix24 using new REST methods.
Meanwhile, the need for such integration has just ripened. The link through VoxImplant included an extra link, required “dancing with a tambourine” in tuning, and deprived the “asteriskers” of freedom. Since part of the call processing logic along with SIP traffic was given to an external system.
We decided that the contact centers would wait. We carry out a specific order. Based on the results of which we are preparing an integration product for everyone.
MVP
It turned out that colleagues use as many as three Asterisk:
- one with custom contexts
- two connected to the first
This essentially complicated a simple task:
- identify responsible
- open card
- record a call in CRM
Really simple, you say. Four hours of work. So it is: if you write for yourself, then you can limit yourself only to the scripts you need. But any step to the side adds another four hours. However, we did for everyone. So our goal is not an easy way for the developer. A easy way for the user.
The basis of the solution was chosen by the FreePBX v.13 framework. It is the most popular among analogues to date. It is actively developing and includes everything necessary for our solution.
We designed the main part as a module for FreePBX.
Pros of the thirteenth version of FreePBX:
- modern interface
- convenient alerts when setting up the module
- AJAX support and
- simple module update process with table structure change
The most important thing for the module to work is to determine the appropriate contexts for integration. After all, each client has its own call processing scheme.
Today, the main work goes with the contexts ext-did-001, ext-did-002 and macro-dial-one for incoming calls and outrt-, macro-dialout-trunk - for outgoing calls.
In two months, Asterisk and Bitrix24 were integrated. Bitrix24 CRM now monitors the all-seeing eye for incoming and outgoing calls.
We have gained great experience in the course of joint work. Numerous discussions of different scenarios were not in vain. And some bugreports closed during the day. By the end of March, we had a product that we could already submit to the application catalog marked “beta”.
First results
When creating MVP, we focused on simple and transparent logic. For example, the start and end time of the conversation is tied to the channel of the external subscriber (with the incoming channel, the first channel that opens, with the outgoing channel the channel on which the called number is located). The MVP backlog did not include support for Ring Groups and FollowMe. But this did not affect the functionality, as they are replaced by Queues.
The result was not long in coming: from the first days we get 15–20 installations per day. For us it was a hypothesis test. The first beta version was a fairly crude MVP. Therefore, this result gave us strength and confidence. And with confidence came a flurry of questions on the first line.
User-friendly
Most Asterisk installations are cut off from the world and work quietly for NAT. However, getting dozens of questions from system administrators on how to configure Firewall for integration was quite surprising.
“ Port forwarding?” Of course they did. What to forward? Where to? What for? ".
The problem was not in the qualifications of users. And in the submission of information. And you won’t get off with amendments to the instructions. Similar issues almost stopped after the interface was redesigned.
It is believed that the system administrator does not care what interface to work with. This view has not stood the test of practice. It does not matter who the user is - a system administrator or a housewife. The simpler and more understandable the interface, the more loyalty to the application. At the same time, making the interface simple is incredibly difficult. Especially with regular changes. During beta testing, we tried to release at least one update per week.
Module Interface Evolution
Every week new functionality was added, internal logic was changed. The product developed incredibly fast. The analytics collected during the week became irrelevant with the release of the new version. Sometimes technical innovations were ahead of changes in the interface. Then you had to edit or completely revise user scripts. This led to major changes to the interface.
High development dynamics imposes restrictions on interface design. We set ourselves an ambitious task - to make a convenient application for connecting Bitrix24 with Asterisk. And we managed - now anyone can “make friends” with them.
Instead of an afterword
In a month and a half of beta testing, we tested many hypotheses and implemented dozens of scenarios. This is the merit of the support service.
We immediately refused tickets and email. Such correspondence does not imply a quick reaction. And the consideration of one simple question may drag on for several days.
The open lines at Bitrix24 helped us a lot. Both we and our customers use the same product. The client can always find our open line in the list of their chats and see the entire history of correspondence. We get tasks, internal communications and communication with the client in one ecosystem.
Thanks to this format, customers receive a response to an appeal within an average of three minutes. And the client is satisfied with the support and willingly shares not only problems, but also ideas for improving the product.
With the release of the stable version, we had to artificially reduce the dynamics in favor of quality: responsibility to commercial users does not allow us to experiment on a previous scale.
The assembly and testing, as well as the installation and operation of the module in Docker containers, were automated based on GitLab CI (we plan to write about this separately). We try to release updates once a week, but all the experiments were posted in the beta branch. By the way, we invite beta testers to collaborate.
This is the end of the tale, but the story of our decision is just beginning.
Product itself: link .
