In a previous post, Evaluating and Improving Voicebot Flows with Call Stats, we introduced this vital health check for the continuous improvement of voicebot performance. Call statistics gauge bot effectiveness and identify bottlenecks and potential flow disruptions in AI agent workflows.

Adding call stats to voicebot flows involves identifying where the business logic is defined and adding the corresponding logic there. For simple scenarios, recording the data can be done taking advantage of tools that might be already available for the application such as MongoDB, or using specialized tools such as OpenSearch. For consuming the data, you can build a custom UI which integrates with your application.

In this post, we will present an overview of such an implementation that relies on the open source tools FreeSwitch and Java ESL. We won’t cover Public Switched Telephone Network (PSTN) provider or voicebot underlying service specifics, as the concepts here are applicable to whichever tools you choose.

Overview of the Voicebot Architecture

Implementing a voicebot in a WebRTC application usually involves integrating PSTN, through a SIP Trunking Service, with a IP/PBX server such as FreeSWITCH which is responsible for connecting phone calls with both the bot service and the web application’s infrastructure.

A common practice is to manage FreeSWITCH events from a separate client, using an Event Socket Listener (ESL) library such as Java ESL. This allows for increased flexibility in integrating the business logic that links phone calls with the bot and facilitates routing to an agent if necessary, in real-time. At this point, it’s possible to connect directly with an agent if the client knows the exact extension.

A generic flow is described below:

The flow looks like this:

1. A user dials in through the PSTN.
2. PSTN provider connects to FreeSWITCH through SIP trunking.
3. The FreeSWITCH server checks business logic in the ESL client for handling calls.
4. As defined in the ESL client logic, the FreeSWITCH server then routes the call to the bot client service.
5. The user then starts having the conversation with the bot.
6. Meanwhile, the bot sends related actions back to the ESL client.
7. The ESL client, in turn, sends any relevant notification to the web application.
8. Actions & notifications related to the agent accepting the call are sent to WebRTC application backend service.
9. The logic for connecting the caller is added in such a backend service.
10. The FreeSwitch service then routes the call to the application infrastructure through the WebRTC Media Server. The web agent also connects to the WebRTC Media Server.

Adding Stats in Business Logic

Managing events from a separate client allows us to add custom code. This is the perfect place to record stats and metrics.

For instance, let’s say you have a recordStat method that takes a metric and a value for it, and persists it into your storage of choice. You are interested in recording data about call transfers between voicebot and agents; labeled as BotTransferStart, to know when a client has requested for a specific agent, BotTransferFail, for when the voicebot fails on transferring the call, and BotTransferFinish, when the call is successfully transferred; in order to identify bottlenecks and potential flow disruptions.

In the ESL client you define the flow as follows:

1. The flow starts with the phone user asking the voicebot to transfer to a specific agent by saying the extension. You can call recordStat here to indicate that a transfer has started.
2. Then, you check if the agent is logged in to receive the call. If not, you transfer the call to the voicemail service and call recordStat with reason AgentNotLoggedIn.
3. Next, you check if the agent is available. If not, you transfer the call to the voicemail service and call recordStat with reason AgentNotAvailable.
4. Lastly, you send the notification to the agent so he/she can take the call. If the agent doesn’t accept the call you transfer to the voicemail and call recordStat with reason AgentNotAcceptedCall.

Storing Stats in MongoDB

Another important part of adding call stats to voicebot flows is storing such stats. Usual approaches involve setting up specialized tools such as OpenSearch and OpenSearch Dashboard, which gives a lot of flexibility over the data.

However, this also adds more complexity over the architecture as it adds another node to maintain, which could be an overkill for simpler requirements. In such scenarios general purpose storage tools such as MongoDB might provide a better suited approach. This is the one we will adopt for this post.

In this case, we take advantage of the Time To Live (TTL) property of MongoDB documents to set a limit on how much time we want to keep data in order to preserve space. To do so, we start by creating an TTL index on the field that will hold the time value and set the limit.

db.stats.createIndex( { "createdAt": 1 }, { expireAfterSeconds: 2592000 } )

Then, just make sure that you set creation time when adding a stat to the database.

db.stats.insertOne( {
   "createdAt": new Date(),
   "statName": "BotTransferFails",
   "statValue": "Agent007NotAvailable"
} )

Next Steps

At this point, you are recording critical data from the voicebot flow and storing these in a MongoDB database. The next step is to actually consume that data. You can build your own custom UI which integrates with your application (our design experts can help!).

Note that while the approach shown here serves for simple requirements, the concepts are applicable for multiple scenarios. You may want to start simple and then move into a more complex scenario where you require storing data over a longer period of time. You can add an Amazon S3 bucket to store long-term data.

Also there is the option of using the more specialized tools mentioned above which will require equally specialized skills to maintain.

Call on the Integration Experts at WebRTC.ventures

If you’re looking into improving the flow of your virtual agent or implementing a voicebot or other AI-powered features into your agent’s browser, our team has the expertise you need. Contact WebRTC.ventures today!