Courier client interaction and scaling service
When you saw a small revision for a specific task of a specific client, it rarely happens that afterwards it (refinement, not a task) can turn into something large-scale. And yet this happens: we made a simple add-on to control conversations between customers and attracted couriers, and she took and turned into a tool for managing a call script from an external system.
Problem: lack of control
Our client, an online store, developed rapidly, and periods began to arise when couriers were not enough for all orders to arrive at the recipients in time. Just at that time, there was a boom of cleaning up everything and everyone, he did not bypass the party and the delivery service.
The store attracted external couriers and was preparing to rest on its laurels: the savings compared with hiring people went to the state tangible. But quite unexpectedly, the failure rate for delivery rose to indecency.
It turned out that with orders delivered by their own couriers, everything is fine. But with attracted something is wrong. Customers are unhappy, do not accept orders, and even write negative reviews on Yandex.Market.
Anything the courier says can be used ...
The store wanted to find out, but without recording conversations, it turned out to be an impossible task: of course, couriers used mobile phones, and there was no way to assess the quality of their communication with customers.
And then the store changed the scheme of interaction with attracted couriers. Their numbers were put into a separate category in CRM, they set up a script and now they called not the customers, but the store:
- The virtual PBX using the http request sent the caller's number to the store to the CRM;
- in CRM it was determined that the number belongs to the attracted courier;
- back to the Virtual PBX, instructions were given to start waiting for digital input with a voice prompt for the courier;
- the courier dialed the four-digit order number (instead of the 11-digit customer number);
- The virtual PBX sent the order number to CRM;
- that, in turn, matched the order number with the client's phone number and sent the Virtual PBX instructions to call that number (or all of the numbers specified by the client);
- The virtual PBX dialed the customer number (the store number was displayed) and it was connected to the courier.
From prototype to finished product
We used the service getsandbox.com , which is suitable for prototyping the server system. An account in this service allows you to create your own subdomains and register HTTP handlers for them.
JavaScript is used to write handlers. Service Bonus: There is a state system object in which you can save data between requests. This allows you to simulate multi-pass scripts. Moreover, it is possible to take into account failures and incorrect answers.
// req - incoming http request
// res - system response
Sandbox.define ('/ crm_integration', 'GET', function (req, res)
{
// set the response code, we can pass an error
res.status (200);
// denote the content type
res.type ('application / json');
// cling content
/ * DispatchIncomingDeal is a samopisnaya function, where we asked how to respond to callers: we brought a courier card and created special processing for their numbers, which I am talking about in the article * /
res.json (DispatchIncomingDeal (req));
// Stub in case you need to turn off the processing and just give out the answer "nailed"
// res.json ("{\" phones \ ": [\" 79175968108 \ "]}");
});
To get access to the contents of the client request variables, we use the req object, which will directly refer to the value.
All that had to be done was to simply sketch the courier card and, when accessing the Virtual PBX, look for the caller's number transmitted in the numa parameter.
var numa = req.query.numa;
function FindByNuma (numa)
{
return _.findIndex (state.carriers, function (obj) {return (obj.numa === numa);});
}
If the number is in the courier card, then we ask the Virtual PBX to give the courier a hint and wait for the digital input from it.
As a result, the store implemented a scheme in which:
- courier negotiations with customers are monitored (the call goes through the Virtual PBX and conversations are recorded);
- customers do not see the mobile number, but the store number;
- the probability of courier error when dialing is reduced (4 digits of the order instead of 11 digits of the customer number);
- the recipient of the order and the courier do not know each other’s numbers, which means that a direct connection between them is impossible, that is, the parties cannot call or write an SMS to clarify the relationship.
Seeing that the scheme is working, we finalized the add-in of the Virtual PBX into a full-fledged tool, which we called Interactive call processing . With it, you can implement call script control from any external system that supports http integration.
The instruction is transmitted by referring to a specific URI with call parameters, such as uis_test.getsandbox.com/crm_integration?cdr_id=123&start_time=1200&input_result=None&numa=74952345678&numb=74951234567, where:
- uis_test.getsandbox.com/crm_integration - URI of the request processor from the Virtual PBX;
- cdr_id - call ID;
- start_time - start time of the call;
- input_result — DTMF codes entered by the caller;
- numa - caller number;
- numb - the number that is called.
The external system should send an http response, which will contain a JSON instruction for the Virtual PBX. In case of client-server interaction errors in the Virtual PBX itself, we have provided the ability to specify a backup action script.
Share in the comments if other cases are interesting with the use of this tool and the possibilities opened with it.
')
Source: https://habr.com/ru/post/326410/
All Articles