
To facilitate the best end-to-end experience possible for users, Uber is committed to making customer support easier and more accessible. Working toward this goal, Uber’s Customer Obsession team leverages five different customer-agent communication channels powered by an in-house platform that integrates customer support ticket context for easy issue resolution. With hundreds of thousands of tickets surfacing daily on the platform across 400+ cities worldwide, this team must ensure that agents are empowered to resolve them as accurately and quickly as possible.
Enter COTA, our Customer Obsession Ticket Assistant, a tool that uses machine learning and natural language processing (NLP) techniques to help agents deliver better customer support. Leveraging our Michelangelo machine learning-as-a-service platform on top of our customer support platform, COTA enables quick and efficient issue resolution for more than 90 percent of our inbound support tickets.
In this article, we discuss our motivations behind creating COTA, outline its backend architecture, and showcase how the powerful tool has led to increased customer satisfaction.
Customer support before COTA
When customers contact Uber for support, it is important that we route them to the best possible resolution in a timely manner. One way to facilitate this is to have users click through a hierarchy of issue types when they report an issue; this provides our agents with additional context around the issue, thereby enabling them to solve it more quickly, as detailed in Figure 1, below:

Although this provides important context, not all of the information needed for solving an issue is obtainable through this process, particularly given the wide variety of possible solutions available. Moreover, the diversity of ways a customer can describe an issue associated with a ticket further complicates the ticket resolution process.
As Uber continues to grow at scale, support agents must be able to handle an ever-increasing volume and diversity of support tickets, from technical errors to fare adjustments. In fact, when an agent opens a ticket, the first thing they need to do is determine the issue type out of thousands of possibilities—no easy task! Reducing the amount of time agents spend identifying tickets is important because it also decreases the time it takes to resolve issues for users.
Once an issue type is chosen, the next step is to identify the right resolution, with each ticket type possessing a different set of protocols and solutions. With thousands of possible resolutions to choose from, identifying the proper fix to each issue is also a time-intensive process.
Introducing COTA: Customer Obsession Ticket Assistant
We designed COTA to help our customer support representatives improve their speed and accuracy, resulting in an improved customer experience.
In short, COTA leverages Michelangelo to simplify, expedite, and standardize the ticket-resolution workflow. While the current version of COTA is comprised of a set of models that recommend solutions to agents for English-language support tickets, we are in the process of building models that can process Spanish and Portuguese-language tickets, too.
Built on top of our support platform, our Michelangelo-powered models suggest the three most likely issue types and solutions based on ticket content and trip context, depicted below:

As depicted in Figure 2, the general COTA architecture follows a seven-step flow:
- Once a new ticket enters the customer support platform (CSP), the back-end service collects all relevant features of the ticket.
- The back-end service then sends these features to the machine learning model in Michelangelo.
- The model predicts scores for each possible solution.
- The back-end service receives the predictions and scores, and saves them to our Schemaless data store.
- Once an agent opens a given ticket, the front-end service triggers the back-end service to check if there are any updates to the ticket. If there are no updates, the back-end service will retrieve the saved predictions; if there are updates, it will fetch the updated features and go through steps 2-4 again.
- The back-end service returns the list of solutions ranked by the predicted score to the frontend.
- The top three ranked solutions are suggested to agents; from there, agents make a selection and resolve the support ticket.
Results are promising; COTA can reduce ticket resolution time by over 10 percent while delivering service with similar or higher levels of customer satisfaction, as measured by customer service surveys. By empowering customer support agents to deliver quicker and more accurate solutions, COTA’s powerful ML models make the Uber support experience more enjoyable.
Building the COTA backend with NLP and ML
From the outside looking in, COTA takes in contextual information about support issue and returns possible solutions, but there is much more going on behind the scenes. At its core, the COTA backend is responsible for accomplishing two tasks: identifying ticket issue type and determining the most sensible solutions for them. To accomplish this, our machine learning model leverages features extracted from customer support messages, trip information, and customer selections in the ticket issue submission hierarchy outlined earlier.
According to the feature importance scores generated by our model (and unsurprisingly), the most valuable feature for identifying issue type is the message customers send to agents about their issue before officially submitting their ticket through the hierarchy. Since the messages users send are useful for understanding what issue they are dealing with, we built a NLP pipeline to transform text across several different languages into useful features for our machine learning models downstream.
NLP models can be built to translate and interpret different elements of text, including phonology, morphology, grammar, syntax, and semantics. Depending on the building units, NLP can also register character-level, word-level, phrase-level, or sentence/document-level language modeling. Traditional NLP models are built by leveraging human expertise in linguistics to engineer handcrafted features. With the recent upsurge in end-to-end training for deep learning models, researchers have even begun to develop models that can decipher full chunks of text without having to explicitly parse out relationships between different words within a sentence, instead using raw text directly.
For our use case, we decided to first build an NLP model that analyzes text at the word-level to better understand the semantics of text data. One popular approach to NLP is topic modeling, which aims to understand the meaning of sentences using the counting statistics of the words. Although topic modeling does not take into account word ordering, it has been proven very powerful for tasks such as information retrieval and document classification.

In COTA, we use the following topic-modeling-based NLP pipeline to handle text messages, as outlined in Figure 3:
Preprocessing
We first clean the text by removing HTML tags. Next, we tokenize the message’s sentences and remove stopwords. Then, we conduct lemmatization to convert words in different inflected forms into the same base form. Finally, we convert the documents into a collection of words (a so-called bag of words) and build a dictionary of those words.
Topic modeling
To understand our user intent, we then perform topic modeling on the bag of words after preprocessing. Specifically, we use TF-IDF (term frequency-inverse document frequency) and LSA (latent semantic analysis) to extract topics. Figure 4a, below, shows some examples of the types of topics we might obtain from topic modeling:

Feature engineering
Topic modeling enables us to directly use the topic vectors as features to perform downstream classifications for issue type identification and solution selection. However, this direct approach suffers from a sparsity of topic vectors; in order to form a meaningful representation of these topics, we typically need to keep hundreds or even thousands of dimensions of topic vectors with many dimensions having values close to zero. With a very high-dimensional feature space and large amount of data to process, training these models becomes quite challenging.
With these considerations in mind, we decided to use topic modeling in an indirect fashion: performing further feature engineering by computing cosine similarity features, as illustrated in Figure 4b. Using solution selection as an example, we collect the historical tickets of each solution and form the bag-of-word representation of such a solution.
In this scenario, a topic modeling transformation is carried out on the bag-of-word representation, which gives us a vector Ti for solution i. We conduct this transformation across all of our solutions. We can map any new incoming ticket, j, to the topic vector space of the solution, T1, T2