Unifying Support Content to Enable More Empathetic and Personalized Customer Support Experiences

Content quality is critical to the support experienced by Uber’s customers. Consider an Eater who reached out for help to cancel a very delayed order. The same resolution, such as refunding the charge, can be delivered alongside a robotic-sounding message, or one where the style and tone of the response conveys true empathy and acknowledges the user’s poor experience on our platform. 

As the natural expression of the support experience, and a bearer of brand promise, support content affects how people feel, and plays a major part in how they perceive the Uber brand. In addition, support content plays the role of educating users about the product behavior and about our policies while moving them to action. Finally, support content (such as knowledge base articles) also serves to deflect commonly asked questions and reduce the number of contacts handled by our agents. In short, support content is what a disgruntled customer first sees, and hence it is imperative that this content can placate and soothe the customer, whilst also resolving the core issue, transforming customer ire into customer delight.

Uber’s Customer Care platform currently supports content across different business verticals including Uber Mobility (Rider, Driver), Uber Delivery (Eater, Courier, and Merchants), Uber For Business (Organizations and Employees), Uber Freight (Carrier, Shipper), etc. 

Different types of support content used within our platform include: 

• Help Articles (also commonly called as FAQs or Knowledge Base articles)
• Help Tree that enables discoverability of the support experiences for issues
• UI screens as part of our self-service flows
• Forms that allow users to input details about their order or trip for a specific issue
• Saved Replies, Chat snippets, Whatsapp templates, IVR configurations that are pre-authored and stored to be used by agents across different channels for providing a faster, better, and more accurate response to the user

In this article we detail the evolution of our support content platform, hereby referenced as Bliss Content, from multiple disjoint tools and fragmented feature sets into a unified platform that powers the experience for our hundreds of content creators, strategists and specialists who author the support content, thousands of agents who use the authored content as part of their day-to-day handling of support tickets, and our millions of users who consume them as a core part of their support experience.

Problems with Older Architecture

In early 2020, we decided to build a unified support content platform, as the existing systems suffered from several key problems:

1. Multiple Back-end and Front-end Tools: We had different systems for authoring and managing different content types. For example, services powering saved replies (agent canned responses) had a different content management system (CMS) tool than those powering Help Articles and Help Navigation Tree. The content creators used these tools, which had similar feature requirements such as a rich authoring UI, translations support (across ~50 different languages), personalization needs, etc.
2. No Unified Data Model: Each content type used a different data model across these different systems, making it difficult for reusing content or reusing shared features. For example, an agent could not easily pull relevant parts of a Help Article to share with the user as a chat snippet. 
3. Content Managed in Code: Some content types, such as our automation screens and IVR tree definitions, were managed and stored in code, thereby requiring a lot more manual effort from content creators to coordinate simple changes (such as making copy changes to a screen) that had to be executed by engineers.
4. Lack of Visibility on Content Associations: Different systems with different data models also meant that there was no unified way for content strategists to understand user experiences across different content types. For example, a user who visited a Help Article, then interacted with both an automation flow and an agent might encounter different styles and tone across the support content. Analytics across these systems were also difficult to gather for surfacing meaningful insights to content strategists and specialists. 
5. Broken Content Associations: Lack of visibility on content associations also leads to referential integrity issues with upstream and downstream systems that use the content. For example, a Help Article may be linked from a self-service workflow, but since each exists in different systems, deleting the Help Article will result in broken links from the self-service workflow, unless the referential integrity is ensured.
6. No Context for Powering End-to-end Personalized Experiences: Support for experimentation and personalization was limited to using local context. For example, automation screens showing policy details would not be personalized for users who may have already viewed the policy in the Help Articles and need to see only a specific section of the policy, instead of its entirety. 
7. Poor Authoring and Management Experiences:  Content creators needed permissions for different tools that had separate look-and-feel for the same operations (such as versioning, language translations, and bulk operations on content). Content administrators had to train newer folks across these different tools. Content cleanup and maintenance required a lot more manual effort. These impacted the project management timelines and new feature launches across different lines of businesses, since they would require support content to be ready prior to launch. 

In addition to the addressing the above problems, we also needed to build/improve capabilities such as:

• Granular Experimentation: Ability to experiment on a sub-part of the content, such as the salutations in a saved reply. 
• Content Variants for all Content Types: Allow variations of the content based on attributes like countries, surface, etc., which are passed at runtime. This is especially important for ensuring compliance with regulatory requirements in different markets for different lines of businesses. 
• Visibility Constraints Platformization: Visibility constraints allow content authors to specify which content can be viewed by which type of customer. For example, a rider need not see help articles meant for a driver partner. They also enable requirements such as phased content rollout which is needed for compliance purposes, etc. Visibility constraints typically use variables specific to the line of business of the content (e.g., Help Article to be shown only if Order Status is Active). Hence building new visibility constraints should not require a lot of effort. 
• Personalization of Content and Presentation: Ability to define content with variables that are populated at runtime to generate dynamic content for each user. Ability to also display content differently, such as show/hide relevant sections of a Help Article to users based on the context.
• Content Reuse Across Content Types: Ability to author once and reuse snippets of content across multiple content types.
• Content Analytics: Measure and  highlight key metrics around content usage and content quality.

CO Content Platform Architecture

Our vision for the Bliss Content platform was to have a single CMS for all the content types, with a front-end tool powering the content creator experiences, and single back end to support all necessary features of the platform. 

We approached the unified platform design as a layered architecture with 3 distinct layers: 

Content Presentation Layer

The content presentation layer defines the customer-facing interfaces for mobile and web applications. Uber edge-gateway will define the thrift/protobuf endpoints for mobile applications. The CO-Presentation service acts as a proxy to handle more complicated mapping and transmission. The web front-end service will retrieve data from dedicated back-end content services endpoints directly with the defined thrift/protobuf interface. We also defined a shared schema for UI components that can be used for rendering screens for automation flows and other surfaces across mobile and web.

Content Authoring Layer

The content authoring layer powers the core authoring experiences across all content types. This includes authoring of content with a single component as well as those with a collection of components, such as single screen vs. multiple screens that are part of a single automation flow. We also define each content component to be made up of Blocks. A block represents the smallest piece of content with individual metadata associations. For example, a saved reply could be authored as a content with one big block or as a content with 3 separate blocks: a header, body, and a footer. This allows authors to perform operations at block level, such as experimentation with different salutations in the header of the saved reply. 

Content Management Layer 

The content management layer orchestrates the shared authoring and management experiences for different content types. The layer enables shared features by leveraging the content metadata stored in the Content Management Repository. For example, content versioning, audit trail of changes, permissions, assigning visibility constraints or tags or issue type to content, search and filter operations, etc., are all powered by operations on the metadata. Direct lookup of specific content, as well as content collection lookup operations (such as for user search), are all powered by the Content Management Layer APIs.

Platform Architecture Details

With this layered approach, we were able to review our existing systems and re-map them towards the components of our Bliss Content platform architecture as shown below:

For the authoring layer, we decided to reuse an existing CMS platform at Uber. The Unified Content Service powers authoring experiences for Marketing and Web use cases at Uber, and its architecture matched perfectly with our authoring layer requirements. We collaborated closely with their team to extend their Component Editor UI tool to power authoring experiences for all our support content types. All core authoring features could now be built independently as a widget (such as the Translations Module) and used across Uber for very different content authoring use cases. 

In the management layer, we consolidated our back-end services into a single management service with a unified data model (see below), in addition to building a content management UI as a consolidated tool to power all support content management needs. Bliss Content UI serves as the one-stop tool for all content authors, specialists, and strategists to review and manage support content relevant to their region or line of business. It also redirects them to the Content Authoring UI for CRUD operations on a specific piece of content. The back-end service additionally powers direct and indirect content lookup use cases from the content presentation layer.

Data model of the core entities for different content types

Our presentation layer uses clearly defined APIs from the Bliss Content back end for all content lookup needs. This has enabled us to work towards content parity across both mobile and web. For example, each screen of an automation workflow is made up of individual components (such as Title Text, Image, Button etc.). Our presentation layer defines iOS, Android and Web modules for rendering these components. By ensuring that each new component has parity across mobile and web, we are able to ensure parity for all screens using the component. We are also able to reuse the components across different web and mobile surfaces. 

Below is a sample mock of the authoring page showing status for requested translations:

Sample mock of the Bliss Content UI landing page showing the Help Tree for Drivers is below:

Benefits of the CO Content Platform and Next Steps

The layered approach has enabled a meaningful unification of our systems that addresses all the different problems mentioned earlier. Having built the foundational components of the Bliss Content platform, we have been migrating different content types onto the new architecture and deprecating the older services. We have additionally been investing on improving the CMS features of the Bliss Content UI and started focusing our efforts towards the next level of problems:- data-driven content governance and improving the support content quality. 

The next big challenge we are looking to solve with the Bliss Content platform involves improving content quality and effectiveness through the lens of personalization, relevance, empathy, and user sentiment. Some such challenges are:

• Can we improve the relevance of response content based on what the user does next?
• Can we define, measure, and improve the “robotic score” or an “empathy score” for a saved reply?
• Can we measure and improve the user sentiment when they interact with support content? 
• Can we personalize the tone and voice of the content (e.g., switching from informal to a more formal structure) to suit the customer’s conversation patterns?
• Can we identify and highlight content clean-up actions to content strategists and admins?
• Can we automatically suggest authoring new content, such as missing Help Articles, based on data in our customer tickets?
• Can we improve content authoring with auto-suggest, catching inconsistencies on grammar/tone/voice, recommending similar content, etc.?

We are exploring and building NLP- and ML-driven approaches for extending our Bliss Content platform with the capabilities needed to solve these problems.

If you are interested in enabling effortless digital customer care experiences across different business verticals at Uber, consider applying for a role with the Customer Obsession team. We are hiring for several roles across India and US locations.