It is a very common requirement to allow 2-way integration of call-flows (IVR, callbots ...) with CRM or other systems of record (SORs). For example, to lookup data during the call in one or more systems and use the data to influence the processing and caller experience.
Here we'll show how to implement a concrete example which contains basic building blocks that can be used for a huge range of use cases.
The central aspect of such a process is that it must happen in real-time. In addition, we must make it possible for you to completely change the process at any time. So, we have to avoid tightly coupling of the call flow and your processes.
The core mechanism is to be able to send data about an active call to another system and then allow the other system to put data into the active call session.
The example use case
Let's say you allow customers to track the status of items they have ordered from your online store. And you want them to be able to ring a number to offer fast customer service. Here's your challenge: you have lots of useful customer information stored in an internal system, and as soon as they call your service line you want to be able to do a couple of things automatically using that information:
- Use the number they called to see if you can find their profile on the system.
- If it is found automatically, make their information available.
- If the profile is not found automatically, allow them to enter their customer reference number. Use this number to find their profile and get their information.
- If they are a premium customer, route their call to an agent.
- If they are not a premium customer, automatically send them an email with a unique link to check the real-time status of their order.
In order to do this, we just need to establish a way to find out what is happening on each call. This way, babelforce can send information about call/callers to your internal system, get some information back, and use it to do 2 things:
- Intelligently route calls based on customer information
- Use customer information to provide useful automated services
The sequence we are following in this article is just one example of what we can do to make your babelforce phone service more intelligent. But if you can share data and carry out actions on every call, you can create all kinds of workflows.
The flow
Here is a rough sketch of what our given example process looks like:
Configuring the actions
This example process will assume that you are familiar with the basics of working with call flows in babelforce: creating modules, and working with Triggers, Automations and Queues. For this reason, we won't go into great detail but will cover the 'magical' parts.
Scenario 1: Use the caller number to find the customer information
As soon as the call enters the platform, we need to send some of its data off to your internal system. Let's assume all calls are initially routed to an Audio Player, which plays a "Welcome" audio prompt. As soon as the call arrives, an Automation must send out the call data:
As the screenshot shows, you are sending some key call data (the caller's phone, and the call's babelforce ID) to a specified location. Note: this depends on your external service. The URL given in the image above is an example designed to show what the location might look like. Setting up a service to receive data from and send data to babelforce is essential to making this kind of automation magic work.
So what happens next? The data is sent off to your internal service and the phone number is used to try and find a matching customer profile... Great! We found one. The following image shows what data we configure our service to provide:
This is just a representation of the data being sent back to babelforce (in Postman, a popular API exploration tool). The format of the request is correct though. We configured the internal service to send customer profile information to babelforce's /sessions endpoint. Remember the {call_id} we sent originally? When it responds, your service specifies this ID in the request URL, then sends the data back in the form of "ivr.[variable]" JSON properties.
If this feels like too much to understand right now, don't worry! All this information is stored in a Postman collection file, which is linked at the bottom of this article.
All of this data is now stored in the 'session' of that call, which means it is available to us when making decisions further down the call flow.
Scenario 2: No match found for the caller number
After we sent the first action and your internal service has sent a request back, the call session will either contain some information (if a customer was found), or it won't (no customer was found). Lets build a babelforce Trigger to check this, so that we can decide what to do on the call:
This Trigger fires if it detects that a variable called "ivr.email" has been set in the call session. What if the caller's number isn't found, because they're calling from an unrecognized phone? If this is the case, we should offer a backup method.
By adding a Switch Node straight after the welcome message, we can already make a routing decision after the first few seconds of the call. Let's use our newly-created Trigger to make this decision:
The 'After Flow' setting indicates that for calls where the customer profile is not automatically found, we should route the call to an Input Reader. Here the caller should be able to type in their 7-character reference number, which will be stored by the platform.
We need to be able to send this value to your internal system. As you can see from the flow so far, in both cases (customer profile found automatically & manual reference number input), we want to route the call to another module called 'Premium check', which will check if the found record is for a premium customer.
But in the case of the manual input, we need to give the call flow a couple of seconds to send off the captured number to your internal service. So let's put an Text to Speech or Audio Player module in between, playing some default audio (e.g. "Thank you, we're finding your profile") and perform a similar in-app version of the Action we configured to send for the automatic case:
We use {app.inputReader.reference} to find and substitute the reference number - notice that we saved the 'Variable name' as "reference". As before, your service will be able to receive this data, perform a check to find a customer profile with that reference, and send a request back to babelforce to put the profile data in the call session.
So, now we have a pretty good chance of saving the caller's profile in the session of the call. Which means that it is possible using this information to influence the routing of the call. Take a quick look above at the information we receive from your internal system, as well as the desired outcomes we outlined at the very beginning. If the customer has a premium account, then give the customer the option of speaking to an agent. If not, send the customer an email with some useful information.
This is a Trigger you can use to check what information is given in the customer profile. Remember, the session now contains a variable called "ivr.premium" which is either true or false:
If this Trigger fires, it is because the caller has a premium account. Great! Now let's use it in another Switch Node:
If the Trigger doesn't fire, you want to send the call to a module which sends an email and gives the customer some more general information about tracking their order online. Again, return briefly to the image near the top of this article to see the other bits of customer information we stored in the call session. One of the them is "ivr.track_id".
Let's say your web service offers a portal in which customers can track the real-time status of their order. This unique ID forms part of a URL which customers can visit to check this. Therefore, in the module 'Send automated email' we configure a local Automation to direct customers towards this web service:
To take home
So what can we do with call sessions? Sessions are essentially a way of allowing other systems to communicate with a call whilst that call is in progress. Once this connection has been established, babelforce can enable you to gather information from the caller and from elsewhere, in order to enrich the call. In a call session rich with information, tons of possibilities open up: we can intelligently route calls to different services, trigger any other kind of action, or even affect changes directly in a connected system.
It's not a bad thing for your bottom line, either. More and more customer services can be partially or entirely automated, keeping customers happy and saving agent resources for your most complex services.
Resources
The resources below can be imported and tested in Postman, a popular API exploration tool. They show how you can:
- View active calls
- Check the session of a call
- Write data into the call session
