Alberto Antenangeli March 9, 2023
Call centers everywhere are always on the lookout for ways to maximize efficiency while providing superior customer service. With recent advances in AI, leaders are more interested than ever in how the latest technology can help them meet their goals for call center automation and beyond. But the question is: how?
At Nuvalence, we’ve been thinking a lot about AI and how it can help organizations tackle problems like this. Read on to learn how an automated FAQ can take phone-based IVR systems to the next level, along with a proposed design pattern that can help you get there.
Frequently asked questions (FAQs) are exactly what you’d expect them to be: a set of questions that are commonly asked by users of a service or a product. This is a perfect use case for call center automation; there is no point in having a live agent search and read out the same set of answers all day long.
Until recently, the standard way to automate FAQs was to make callers navigate a tree of options using their phone’s keypad, which many callers find frustrating. What call centers need is a tool that can understand questions posed by callers, and give them the answer that they were looking for right away.
How AI Can Help Call Center Automation
Many call centers rely on IVR technology that really took off in the 90s, and are ready for a 21st-century upgrade. We saw some interesting parallels to the 90s when we started thinking about design patterns for AI.
Some seasoned developers may recall that when Object Oriented was starting to take off, the Design Patterns book provided solutions for common problems – clean, tested, and reusable solutions that helped save time.
Fast forward to 2023, and AI seems to be reaching a tipping point – the technology is quickly maturing, and the rate of adoption is starting to accelerate. Like the 90s, there seems to be little in the way of a compilation of patterns to address common problems using AI. This article covers one particular problem – call center automation with support for frequently asked questions – and proposes a Dialogflow CX pattern to help solve it.
The Design Pattern
Dialogflow allows you to define Intents, train your Agent with phrases that can identify those Intents, and then take the appropriate action. For our FAQ case, Intents represent the different types of information the callers are after, and the training phrases are the different flavors of questions callers may ask to get the information they need. Of course, Dialogflow can be used for many different purposes, but this article focuses on the FAQ use case because it tends to be part of any system design.
Dialogflow is, in essence, an enhanced finite-state machine (FSM). Intents can be used to trigger state transitions; Webhooks allow you to call external systems to, for example, access a user’s information; state can be stored in Parameters associated with the user’s Session, etc.
When you think about actual dialogs, it is intuitive to think in terms of transitions: you start talking about sports, then find out which ones you and the other person like in common, which teams you root for, etc. The concept is similar, and an FSM is the right tool to handle this sort of problem.
There are several articles about how to properly design a good conversation (check this YouTube video on the subject), but this is not the focus of this article – we cover the design of the Agent itself.
Let’s discuss a couple of ways we can structure our Agent.
If a keypad-based system is already in place, we may be tempted to lift-and-shift it to Dialogflow. The keypad-based approach is Hierarchical, where we first determine which topic the caller needs help with, and then proceed to refine the caller’s Intent. This works well when the caller’s choices at a certain point are limited by the number of keys on a keypad.
For example, callers contacting an airline may have questions about flight departure, luggage requirements, frequent flier program, etc. With this Hierarchical approach, the caller would first say something like “flight information” and then proceed to supply the specifics like date or flight number. This approach has the advantage of creating a well-structured Agent, where we have a top flow that identifies the general Intent, and then subflows that process each specific area.
Does that work from the caller’s perspective, though? Does it provide a good experience? Let’s play this out:
Agent: “Welcome to our automated service center. What can I help you with today?”
Caller: “What is the expected departure time for Acme Airlines flight 123 departing from New York City this afternoon?”
Agent: “I see you are calling about flight information. Please state the flight number you are calling about.”
From a caller’s point of view, this interaction is frustrating. Their question had all of the required information for the Agent to provide an answer right away; why make them say it again? Bottom line: a design that might be good for a keypad is not necessarily good for a smart Agent. Generally speaking – and this is a common theme when people migrate to Cloud – lift-and-shift usually prevents you from fully benefiting from what Cloud technologies have to offer.
The other alternative is what we refer to as Flat, where all Intents are immediately detected along with the information required to process them, and the answer is provided to the caller right away. The Agent will only ask subsequent questions if any information is missing (in this example, the flight number).
Agent: “Welcome to our automated service center. What can I help you with today?”
Caller: “What is the expected departure time for Acme Airlines departing from New York City this afternoon?”
Agent: “Which flight number are you calling about?”
This creates a much more natural and pleasant user experience. However, since we want to be able to process all Intents at all times, it is tempting to have the Agent’s Start page handle all the Intents and route them to the pages that process them, like this:
The image above has ten Intents; imagine what the Agent would look like if we had to support dozens of questions – our Agent will quickly become unruly. What we need is a way to support the Flat approach, while at the same time keeping the Agent nicely structured and easy to maintain.
Structuring the Agent
While conducting analyses, it is good to think in terms of topics the caller may ask questions about, and then drill down on the specific questions for each area. But this takes us back to the Hierarchical approach that we already decided does not provide a good experience.
How can we reconcile both?
There is a subtle distinction here – the structure of the questions is different from the structure of the Agent. In other words, having a flat structure for questions does not mean our Agent must have a flat structure. Let’s have a look at how this works.
We start by creating a Subflow in charge of routing. This subflow has a Routing page with a Route Group encompassing all the Intents. Instead of matching each Intent to a specific page (which leads to the unruly Agent!), we instead capture what the Intent was in a Session Parameter, and transition to a Subflow that corresponds to the category to which that Intent belongs. In other words, we go from Intent to its category Subflow, and take note of what the Intent was.
Each category Subflow can now use that Session Parameter with the user Intent to route to the appropriate Page to handle it. With this, the Subflows only contain Routes to the pages that belong to that Subflow, making the Subflows much easier to visualize:
Once the Intent is processed by the Subflow, we simply return to the Routing Subflow to handle the next question from the caller.
Of course, Dialogflow supports Intent propagation, which allows the same Intent to be matched by more than one flow. However, capturing the user Intent in a Session Parameter also allows us to use it to support more sophisticated conversations, where the context is also taken into account when deciding what to do next. For example, if the Agent keeps matching the user request to the same Intent, it probably means that the Agent does not understand what the caller actually wants – at that point, it may be a good idea to route the caller to a live agent.
Call center automation is a complex and nuanced problem, but recent advances in AI can offer one way to solve it. The pattern proposed here is a reasonable fit for FAQ-style Agents handling a large number of questions. It helps break down the Agent into Subflows based on categories, making it easier to visualize and maintain; this is particularly important when there are multiple developers collaborating on the development of the Agent, since subflows can be individually exported and imported.
As the use of Dialogflow becomes more ubiquitous, we hope to come across other problems that lend themselves to creating patterns. When we do, we’ll share them here!