Solving Millions of Customer Queries in a Vast Product Ecosystem
Airtel has 350Mn+ customers across multiple categories who interact with Airtel for more than 3.5 lakh queries per day at all its different touchpoints. In addition to that, Airtel launched new products in the past year like Airtel Black, Xsafe and also consistently adds new propositions to retain and delight customers of existing products. As the business keeps evolving, so do the various queries raised by the customer and we need the flexibility to support the business with configurable tools that enable quick market launches and subsequent customer support.
To serve 350Mn+ Customers, Airtel is running India’s biggest customer support experience centres and to serve this large customer base across so many products Airtel needs a cutting edge technology solutions to help agents solve customer queries in efficiently and effectively.
Problems to solve
- Timely and effective resolution of these queries is of paramount importance to customer satisfaction and business continuity.
- Airtel needs capabilities and systems to support multiple businesses and reduce turnaround time to market new programs across channels.
- Airtel also needs the flexibility to quickly adopt new solutions that increase effectiveness of query resolution
- There is also a cost associated with serving each customer query, hence it is crucial to provide resolution to the customer in the least time possible
Airtel has 12000+ advisors across multiple contact centres and stores supporting these queries. This ecosystem is very dynamic, vast and spread across the country which brings its own set of operational challenges.
Problems to solve
- Advisors keep hopping on multiple sources of information, which impacts speed and accuracy of problem resolution.
- Advisor training and retraining is needed when business and its queries evolves, which brings an added cost
- The advisor also cannot be expected to remember what needs to be done or what steps to be followed for different types of requests, they need a tool that guides them to resolve the problem and communicate clearly to the customer.
System Overview: API Driven Diagnostic Engine
How does a doctor diagnose a patient’s illness?
a. By asking questions to the patient e.g. problem duration or easily noticeable symptoms
b. Investigating the medical test report for concrete indicators
Based on answers he could ask more questions/tests or he could deduce your illness and prescribe treatment.
In engineering terms, this forms a directed acyclic graph (DAG) of questions and answers. The leaf nodes could be just information or some corrective action. This is represented with following diagram.
In the modern world when a concerned customer is reaching out to an organisation for support the support agent/system should also do a diagnosis of the customer’s problem. Based on the diagnosis the agent/system could at once resolve the issue (heal/auto-heal) or he could register a complaint so that experts can fix the issue. The customer prefers the first route hence the diagnosis and actions should keep evolving. When we hear the word evolution, we compulsively think about AI but not every solution has to be a neural network. The system we are talking about can be developed fast and it’s easy to maintain too.
We have assumed that in the enterprises various systems which are enabling the enterprise to serve the customer (CRM, Order Manager, Billing, Payments etc.) can expose APIs to query their system. They should also be able to expose APIs to take action to resolve the customer’s problem.
We have summarised that one can diagnose a customer’s problem by:
a. Asking questions to the customer
b. Asking questions to the system with the help of APIs
Answer to a question could lead to another question or it could lead to an action which is backed by corrective APIs. Let’s take an example-
If my mobile internet is not working properly and I reach out to a support agent/system it could lead to several questions to the system and a few questions to the customer e.g.
Based on answers to these questions it naturally forms a directed acyclic graph (DAG). Let’s call this DAG a customer issue. This DAG has customer question steps and system check steps. We have provided an admin interface where a user can visually create this DAG.
Solution Design: A Low Code API Integration & Rule Creation Engine
On the customer query steps, you can direct advisor to ask questions. You can create new vertices based on supposed customer answers. These vertices lead the DAG to the next step. Here is a sample design of such a step.
Key features of this system are
- A no-code platform to invoke APIs
- A low-code platform to write logic on API response and calculate answers
- A no-code platform to stitch these steps (customer question and system questions) in a DAG
Implementation of each of these features is explained below.
No-Code API Invocation Platform
The first component is a no-code API invocation platform called Drift. Using Drift UI, you can define APIs and their response transformation using bazaarvoice jolt. API’s configurations (Http method, URL, query params, request body etc.) are stored in MongoDB and can be invoked by a logical name. Drift has a client-side SDK which pulls API configuration from Drift server and makes the API calls from client’s environment. All variable parameters can be defined as placeholders and a placeholder map can be supplied for substitution when these APIs are invoked by Drift SDK.
Interface of this tool is as simple as any Rest client like Postman. Even users without a technical background can create new API integrations using this component. Changes on these APIs are version controlled and earlier versions are available on UI for comparison and rollback.
Response of the API is passed through a transformation step which is written using Jolt configuration. If the response is already simple and flat, users can opt to keep the config empty. If the response is nested and complex and user only needs a few selective fields, they can opt to use Jolt configuration. We have developed a UI which auto generates the Jolt configuration when you click checkbox against fields in sample response. Here is how this platform’s GUI looks like. A look of transformation screen.
Low-Code Rule Configuration Platform
The second component is Rule-pad where you can invoke API, write logic and calculate the next possible choices. APIs are invoked by reference name using Drift SDK. One can write any logic on these API responses and deduce an output for the rule. This component also has a UI and the code is written in java dialect of Drools. These rules can be referred by their given logical name and can be compiled and debugged independently using this UI. These rules are stored in MongoDB after performing sanitary checks.
When the rule engine spins up, a service (Diagnostic Service) fetches the rules from DB and creates Drools Knowledgebase. Diagnostic Service is used to invoke rules by reference. Rule engine traverses the DAG and when it reaches a rule step, it uses Diagnostic Service to execute the rule. These rules are also version controlled and previous versions are available on UI for comparison and rollback. Here is how the rule-pad looks.
No-Code Admin Platform to Stitch DAGs
Third platform is our admin platform where you can drag and drop steps and choices to stitch together a DAG which can effectively diagnose the customer’s issue. If there is a need to add more steps or change script, admin can update that on this platform and publish it. The changes will reflect without needing any deployment. Here is how the admin platform looks.
Next logical question would be on how are we orchestrating this complex looking workflow? We’re not using heavy tools like Conductor or Temporal. We are using built-in-house Depth First Search (DFS) in this DAG.
To summarise, you can onboard an API (using Drift), write some logic on its response (using Rule-Pad) and stitch these rules in a DAG without doing a single deployment. Advisors don’t have to be retrained when a new diagnosis step is added. This dynamic workflow tells the advisor exactly what to do. Here is a snippet of advisor screen.
We have oversimplified the network journey for easy understanding of the readers, the actual network scenario contains more than 250 steps with complex checks across multiple OSS/BSS systems and network tools that diagnoses accurately in real-time. This state-of-the-art platform is also multi-tenant. New businesses or processes can be onboarded on this platform on the fly. This platform helps contact center agents in solving customer problems on all major products Airtel is offering including empowering dedicated relationship managers who provide priority resolution to Airtel Black customers.
Results
The quick and easy diagnosis has empowered the advisors to resolve queries faster and better to keep our customers happy. The reduced time for handling queries and reduced customer repeats, along with multiple product and process interventions has streamlined how Airtel operates, facilitating a 50% reduction in customer complaints and interactions. While customer queries increased exponentially, the advisors needed to handle these queries only grew linearly and has led to over 2X cost savings since its inception.
In case the advisor is not able to answer to resolve the customer query, a complaint is raised, which has a dire toll on business with inevitable customer dissatisfaction and added operational cost of a field force equipped to reach the customer and resolve the complaint. By providing our advisors with tools equipped with enough journeys to diagnose and resolve maximum customer queries, Airtel is raising the bar on its customer obsession and going the extra mile on its relentless but utopian quest to reduce customer complaints to ZERO.
Want to thank Kiran Ananth. My product manager and co-author of this article.
