A well-made call center benefits: confirms orders, recalls conferences and delivers ready meals. We at Voximplant have an ACD module and the concept of queues, with their help on the platform in a couple of hours you can put together a simple solution for distributing calls. Why is it "simple"? Really complex solutions are very different from each other, it is impossible to make a module that would fit "everyone and right out of the box." However, there is a battle-tested scheme in which clients implement the queuing logic on their backend, and our cloud helps with incoming call routing and analytics. There is a small step-by-step instruction under the cutter: how and why to make call centers for a hundred operators “for themselves”. "The working scheme, infa 100%" (s)
Healthy person tandem: backend + web client
There are no strict requirements for the backend, you can use the conditional Digital Ocean (although, at the time of writing, there were already problems with access to DO, but let's not talk about sad things) with node.js on board. The web client (or operator’s application) can be with one ready button and must keep in touch with the backend via a web socket or HTTP requests. How will it work?
Cloud - telephony center
- You create a Voximplant cloud - based JS script that accepts incoming calls. Each call raises the Started event , which has the accessURL property . The field contains the URL for communicating with the JS session of the ongoing call.
- In addition to the Started event , an incoming call also triggers the CallAlerting event , which contains information about the call: the caller’s number, the number to be dialed, and other necessary things.
- Cloud JS session makes a request to your backend using httpRequestAsync . In the request, we transfer information about the call and accessURL . While there is a request and the backend “chews” it, you can play music for the client, ask a question using speech synthesis, enable mp3 with notification / advertising and not let the caller get bored.
- The backend receives a request and searches for a free operator, i.e. those who in their client clicked on the ready button and are not talking to anyone now. When the operator is found (maybe in five minutes), the backend makes a request for accessURL , and puts the operator’s contacts in the request: user id (if the operator is connected via WebSDK or Mobile SDK), SIP URI or cell phone number.
- Cloud JS session receives an HttpRequest event with the name / number of the operator, calls the operator and connects it to the client.
- The script sends all the information about the interaction with the operator to the backend: it was possible / unsuccessful to get through to the operator, who hung up after the conversation - the operator or the client, all that can come in handy to analyze the work of the call center and determine the availability of operators. The backend receives this data and on its basis constantly “marks” the operators: how quickly they respond, who does not answer, whom and how much to ban for inactivity. These notes are constantly updated, so the backend always knows what happens to the operators.
You can do everything from scratch in a couple of hours, while you will have full control over the queues of calls, with the necessary logic and your requirements. Of course, this is the framework of the solution; we already said about the nuances that each business has its own. Based on this approach, you can implement interesting solutions. For instance:
A good feature of a complex call center is when the client is switched to “his” manager, who leads the client from the very beginning. This is convenient, because the client does not need to explain any subtleties and stuff every time from scratch, the personal manager probably already knows everything, plus this manager knows how to work with the client as efficiently as possible.
Since the CallAlerting eventcontains information about who is calling the call center, the backend can check if the incoming number has a designated manager and if so, contact it. In the case of a vacation / illness / dismissal of a manager, you can synthesize a short explanation and connect the call to another manager / operator. If the incoming number does not yet correspond to any manager, then after talking with the operator, you can ask the client the question “Do you want this manager to always answer calls?”, Then recognize the answer (“yes” / “no”) and transfer the value to a backend that will “remember” the customer’s choice.
“Own manager” works well for user loyalty, and if the attachment process is also automated, this eliminates the error of manually appointing the wrong specialist.
Need more operators
It happens that at peak hours of the load, the operators do not cope with the flow of incoming: customers in this case either do not dial up or wait a long time for an answer. Both options are so-so. The problem can be solved organizationally: hire more operators and hope that the cost of new employees will pay off with customer loyalty. But you can go from the other side too: during the load on the call center, direct calls to technical support to other specialists as well. It turns out situational "expansion" of the call center.
A couple more?
Call centers become complicated because they change over time: the market makes new demands on communication, legislation is changing, there is competition, and all sorts of interesting things happen all the time. There are many different call centers in the market, and that’s good! The flexibility of technology makes life easier for business and delights customers. If you have questions and comments on hypothetical / real examples of call centers, feel free to write in comments - we will discuss. Stay connected and don't be afraid to hover in the clouds;)