Use cases

Successful cases

We encourage integrating VoIP services with Kommo and are ready to provide consulting. Here are some existing VoIP integration

  • Twilio: American company that provides programmable communication tools.
  • RingCentral: a global enterprise cloud calling solution.
  • Zenvia: phone solutions for small businesses

And many more!

Understand the task

It is necessary that you fully understand the role your integration is going to play. Your integration can synchronize data about its settings, users, their rights and extensions. If you want, it may provide the ability to perform outgoing/incoming calls inside Kommo.

The calls are done by the VoIP integration, while your integration job is at the beginning (requesting the call, dialing a number, answering the call) and the end of calls (logging the call, showing the call result window). You may also import information about calls periodically.

The integration should be authorized in both Kommo and the VoIP service, and it should securely process all information.

For better performance and information consistency, you should take into account the number of integration users, and you could consider using queues and handlers for them.

If your integration has a UI/UX part, it should be beautiful. And finally, if you decide to publish it in Kommo marketplace, you should consider the requirements for marketplace integration.

Use cases

Here are a set of requirements we think should be considered.

  1. Installing and configuring integration

    Your integration should use OAuth 2.0 authorization to authorize with Kommo, and you can choose any secure way to exchange keys with the VoIP service. All produced tokens and other information should be saved. Also, the integration should provide a window for the account administrator for setup.

  2. Call logging

    Your integration could register calls between contacts and managers and link each call to the suitable entity (contact, company, lead, customer) according to our call logging algorithm.

  3. Call result

    If the call is done inside Kommo, a modal window could appear when ending the call for the manager to add a call result.

  4. Call recording

    When saving the call, your integration could link the call recording with the call note, and then Kommo will provide the ability to show a player to listen to the recording.

  5. Unknown number

    When a call from an unknown number comes, your integration could provide the manager the ability to save the number to a new contact. An incoming lead could be automatically added, and if the manager saves the number, they would be able to accept the lead and add a note and a to-do.

  6. Caller ID

    When a call is done in a user’s account, the integration can show the name of the caller with a link to the corresponding entity for better communication.

  7. Assign extensions to managers

    You can provide the ability to assign every manager (user registered in Kommo account) a phone extension number of the VoIP account.

  8. Smart forwarding

    Every contact could be assigned to a responsible user, so that when an incoming call is received, the VoIP integration should look for the contact, and find out the responsible manager and then forward the call to this manager

  9. Making call inside Kommo

    To simplify managers’ work inside Kommo, we suggest providing the ability to perform calls inside the account, by showing a keypad with buttons to manage calls and windows to display them. A notification about a call could also be provided.

In the improved version of the integration, you can also expand the capabilities and for example implement the following functions:

  1. Creating a Callback Task if the call was missed
  2. Creating call lists of contacts, companies and leads, and implementing the skip, pause and time interval.
  3. Reporting errors and recalling if connection was lost.
  4. Opening the active lead connected to the contact when answering a call from this contact.

Beginning the development

Before anything else, we highly recommend that you split the UI/UX from the integration, and we will describe our vision of how to organize the delayed asynchronous tasks so you can have more understanding for what’s coming next.

UI/UX

The UI/UX is a widget which contains an archive of files that is loaded during the creation of the integration. The widget has the integration settings which contain: description, icons, subscription to events, determination of the required scopes, integration id and integration secret. This is a general structure of a typical widget that you must stick to:

  • locale files
  • images
  • template files
  • script.js
  • Manifest.json
  • widget.php
  • scripts placed in separate modules, but used inside script.js

One of the basic files is script.js. It has standard methods for working with widgets, but the most important thing is that you can expand it as you need with additional functions which will expand the system functionality once the widget is installed.

The entire widget is represented as an object, which has callback functions that are called under certain conditions.

During development, you can use any tools and libraries. The main thing to remember is that the result of the work should be a javascript code that is executed inside script.js.

Integration

We encourage working on a MVC development environment. We usually use PHP MVC frameworks like Laminas, Laravel, and will describe everything in PHP terms. You can use any language you want, and read our documentation to get the ideas we present.

Your integration can have models where it implements the database tables and a module to deal with Kommo and generated keys. Since the UI/UX is a widget, you should also provide a connection to receive/send information to the front-end.

Your integration should process high load and work with a lot of leads, and for this we recommend using queues. The queuing system is a principle, not a specific technology. Queues ensure scalability, allowing the application speed to increase.

The queue server keeps a list of tasks that the main application sends to it, and this is its only job. A task is simply information about what needs to be done and how. It is not necessary to use an external solution to implement a queuing system. However, simplicity and the availability of ready-made solutions will make it faster, for example Gearman, Beanstalk.

For each use case, a task is created to implement the use case in a handler and submitted to the queue. A worker is a separate script that constantly checks the server for new tasks. A worker grabs a task from the queue and executes the logic associated with it.

VoIP-Integration
├── KommoAuthentication
├── Database
├── Queue
├── Widget
├── Database
├── Voip
│   ├── Task
│   │   ├── AddCallTask
│   │   ├── SaveCallEventTask
│   │   └── UpdateFromModalTask
│   ├── UseCase
│   │   ├── AddCallUseCase
│   │   ├── SaveCallEventUseCase
│   │   └── UpdateFromModalUseCase
│   └── Handle
│       └── ProcessWebhookHandler
└── Console
    └── Worker
        ├── AddCallWorker
        ├── ProcessCallWebhookWorker
        └── UpdateFromModalWorker

Let’s now discuss every use case in depth, and start with installing and configuring the integration.