Customer — Agent Matchmaking: Another Peek at Agoda’s Customer Service Tech

by Oraan Khunphisuth and Ankit Tibrewal

Introduction

Agoda is a leading travel platform, providing a vast array of accommodations, flights, and activities for travelers. With a high number of bookings, we naturally encounter a significant volume of customer service inquiries, primarily through chat. Balancing the need for human assistance with the available customer service agents is a challenge we continually address to uphold our service quality, speed, and accuracy.

In our previous article, “ Plug and Play Chatbot: A Peek at Agoda’s Customer Service Tech,” we provided an insight into how our chatbot technology functions at Agoda. This solution, combined with our Wizard solution and AI, allows us to deliver instant, high-quality support for frequently asked questions. However, we recognize that certain situations require a personal touch. For these instances, we have a system to facilitate seamless interactions between customers and our agents, ensuring each inquiry is handled with the care and attention it deserves.

Why do we need Matchmaking?

As previously discussed, despite our limited human resources, customer requests are relentless. These requests vary greatly, including factors like language, type of booking (i.e., Flights or Hotels), or priority. It’s not optimal to randomly allocate these requests to any available customer service agent. For instance, assigning requests from Chinese-speaking customers to Thai-speaking agents would be a nightmare for both.

Another example is the prioritization of each customer request. For example, if Request “A” can be handled a little later than Request “B”, then “B” gets priority. A typical scenario for this is the urgency of flight bookings: a customer’s request for a flight happening today must be served before a flight scheduled a month later.

Disclaimer

In the upcoming sections, we present a series of examples and animations to illustrate the matchmaking process for customer services at Agoda. Please note that these have been simplified for the blog’s context, ensuring they are easily understandable for our readers. They do not represent what is in production.

Terminology

Customer Service Agents (referred to as ‘Agents’)

Our Agents are highly skilled individuals equipped to handle diverse customer inquiries. Each Agent has a specific capacity (the number of requests they can handle simultaneously) and capabilities (the types of requests they can handle).

Consider a scenario where we have 30 Agents, and each can handle three requests at once. This setup enables us to handle 90 customer requests at the same time. However, capabilities vary among Agents. If, for instance, 10 of our Agents are fluent in Thai, then we can only process 30 Thai-language requests simultaneously.

Customer Request

A customer request is initiated when a customer seeks assistance via our contact page. They are required to provide their booking ID, which aids us in gathering further details about the booking. This information includes, but is not limited to, the type of booking, check-in date (or departure date for flights), and customer data. These details are crucial for prioritizing the requests and for our Agents to review and process them effectively.

An example of how a Customer Request is constructed is shown in the table below:

Matchmaking Behaviour

Before diving into the technical aspects of matchmaking, Let’s start with the intended behavior of prioritizing and categorizing customer requests before assigning them to capable agents.

As mentioned in Customer Request, each request comes with associated booking information. This information will be run through a set of predicates to determine category and priority.

Below is an example of predicates. The green background row means the predicate is satisfied for the above booking information.

Let’s assume we have several requests coming in. After they all get processed, you can see that the table shows the priority and booking information of each request.

This table shows that the request with the highest priority, identified as Request ID 1, is likely to be addressed first by an available agent. Subsequent requests are then addressed in descending order of priority. This is the concept of a Priority Queue, where the highest priority is placed on top, followed by lower priorities.

Now, let’s bring agent examples and map them with the requests they can handle. You’ll notice that some requests are manageable by multiple agents. This gives us more flexibility when matchmaking agents with customer requests.

Can you guess who will get Request ID 1? Yes, it’s Carol because Carol can handle Flight booking and English language.

Matchmaking Engine

Let’s see how this works technically. As the name suggests, a matchmaking engine is an engine that matches customer requests to capable agents.

The diagram above shows the simplified flow through which customer requests reach agents. We will explore five key components in this process:

• Chat Platform
• Booking Platform
• Spring Expression Language (SpEL)
• Request Evaluation Engine
• Agent Assigner

Chat Platform & Booking Platform

In this section, we’ll touch briefly on two fundamental platforms: the Chat Platform and the Booking Platform, both essential for retrieving information on customer requests.

Chat Platform is central to managing interactions between customers and agents. Here, customers initiate conversations, providing inquiry details, which are processed and published to a Kafka event topic. This is where our matchmaking engine steps in, consuming these events for further processing.

Booking Platform stores booking information. Our matchmaking engine sends requests to this platform for important information to categorize and prioritize a customer request.

Spring Expression Language (SpEL)

Before we dive into how the Request Evaluation Engine and Agent Assigner work, it’s important to highlight the role of the Spring Expression Language (SpEL). This is an important library that plays a crucial role in the matchmaking process in terms of request evaluation and agent assignment.

From the official documentation, SpEL is a library that supports querying and manipulating an object graph at runtime using simple expression language. To illustrate, let’s look at the simple object graphs below. Each item represents an object with a parameter mapping and corresponding values. You will notice that each item may be different in value.

Suppose we want to find items based on specific conditions on the parameter value. One could create a utility function with the necessary conditions, but this approach is not dynamic. Any change in conditions would require code changes. SpEL offers a more dynamic solution, allowing us to write expressions that efficiently query and filter items based on our criteria.

Below are examples of SpEL expressions alongside the items they evaluate. Notice how the expressions are written in a simple, easy-to-understand string.

For more information on SpEL, please check out the official Reference Documentation on Spring Expression Language (SpEL) by Spring.

Next, we will dive into how we categorize customer request conversations and how we assign these conversations to agents.

Request Evaluation Engine

Request Evaluation Engine is a rule-based evaluation engine in Routing Service. It consists of predefined groups of conditions. Each conversation is assessed through these conditions, with skills and scores determined based on the highest criteria in each group.

This process might sound familiar. It closely aligns with our earlier discussion in the matchmaking behavior and Spring Expression Language (SpEL) sections.

In this context, we use SpEL not just for filtering items, as in our earlier example, but to calculate the priority score and identify the required skills for each request.

The priority score is used as a prioritization for further operations; The higher the priority score, the more urgent the conversation is.

The evaluated conversations will then be placed into a queue to be assigned to agents.

Below is a visualization of how it works. The colour of each request indicates the different skills required.

Agent Assigner

Once conversations are evaluated and prioritized, they can be assigned to our agents.

Each evaluated conversation is characterized by two key factors: the priority score and the required skills. Those with higher priority scores are more likely to be assigned to agents first. However, this is contingent on agent availability and capability; high-priority conversations may need to wait if no suitable agents are available or if they are at full capacity.

This approach ensures that lower-priority conversations aren’t indefinitely delayed because a higher-priority conversation has yet to be assigned.

Challenges

A queue... or not a queue?

As we discussed how requests are pushed to the queue and then later assigned to agents, you may notice that this is not a linear first-in, first-out (FIFO) queue. Instead, it’s more like a linked list where a middle item can be taken out or inserted into the list. This was a complex problem in the early development stages.

Message queues like RabbitMQ or Kafka were not useful in cases where they preserve the sequence of messages. Plus, with these systems, you can’t view the information without consuming the messages, and dynamically managing messages in the queue is challenging.

Our solution was to use a database to manage request orders. While databases aren’t typically ideal for implementing queues, we optimized indexes and queries, combined with appropriate caching, to achieve high throughput.

Final Words

Has this matchmaking been successful?

At Agoda, experimentation is part of our DNA, and this matchmaking system is one such experiment. We’ve observed that categorizing and prioritizing requests have improved response and resolution times, albeit insignificant. It’s a promising start, and we’re analyzing the data to refine our approach further.

Next Steps?

We always aim to improve quality and reduce response times in customer support. High-quality support leads to customer satisfaction; quicker responses mean more efficient agents.

Categorizing agents into distinct groups presents a significant challenge, primarily due to the varied nature of customer requests. Some inquiries, like seeking information or changing booking dates, are easy to handle. Others are more complex. Our aim is to categorize and prioritize requests more effectively, allowing experienced agents to handle complex requests.

Besides the technical changes to improve the performance of our system, this is the next target we are looking at. We are actively exploring and learning to improve our customer support structure.