ConversationKit is Apple’s in-house dialog configuration platform, used by teams at Apple to create automated support experiences for its global customers.
Dialogs follow a tree structure with a model classified intent on the root node and user configured entities and responses. This combination creates deterministic branching.
2. Entities
Values and synonyms that users configures. The model uses entities to recognize contents of the customer’s message and navigate the dialog.
3. Actions
A variety of response types like text, lists, quick replies, API calls that improve dialog capabilities.
Dialogs can be duplicated, and duplicates can be modified to created variations of dialogs which are appropriate for specific regions.
2. Localization
Each variation or original dialog is sent to a translation services that returns translated content of the dialog. The localized version of the dialog is customer facing.
3. Mass Publish
The ability to publish multiple dialogs, variations, locales and bot level settings in a single session.
“Of the 2 Million MAUs, only 40% of conversations were automated end-to-end. The remaining 60% that were handed off to live agents were too nuanced or niche to justify configuration.”
Investigation
11
Interviews
240
Dialogs Reviewed
17
Upcoming Projects Analyzed
Insights Discovered
1. Conversations are fluid
Organic conversations always go back and forth, especially when conversations are about unfamiliar topics.
2. Trees expand exponentially
ConversationKit’s foundational structure only allowed forward and sideways movement. Conversations are unable to go back.
3. Duplicate to go back
Without the ability to go back, users are forced to duplicate chunks or entire dialogs. The deeper the point of return, the more exponential the dialog.
Objective Identified
Create a dialog platform capable of simulating all possible flow types of organic human conversations, therefore, reduce configuration time by 40% and 2x solution capacity.
Breakthrough 1: Graph Structure
Concepts
ConversationKit’s building blocks and structure heavily influenced which dialogs and how they are configured. It was crucial that the system did not restrict users from building dialogs. 3 themes were identified and focused to reach the objective:
1. Flexibility
2. Reusability
3. Visibility
Designs
With a revamped structure, components like entities, and list pickers were enhanced to provide a smoother user experience. It was here that new opportunities such as operational logic was introduced.
Feedback
The concept and design was focused towards saving time and effort that was being spent on duplicating information. It was important to get feedback at this point. After conducting playback sessions with various teams, the gap between the design and need was made clear.
Dialog Admin, AppleCare
This looks really cool and I like that we can combine dialogs, but I’m not sure how we can improve the quality of our dialogs.
Dialog Strategist, Retail
I love the graph structure, it paints a much clearer picture but the configuration is still manual and laborious.
Breakthrough 2: Conversational Intelligence
Pain Points
The feedback eluded to problems with the design iteration. The pain points went beyond user interface or duplication, the assumption that dialog strategy was due to the tree structure and components was partly true.
1. Configuration Overhead
To create a dialog, users had to identify and reply on entities(keywords) for the model to understand customer messages. This severely limited the scope of dialogs from the beginning.
2. Static Responses
Due to the keyword triggers, it was difficult to personalize responses. Dynamic responses had to be text paired with links, or external API calls.
3. Variation Complexity
It was proving challenging to create and effective and easy to follow localization system that conveyed state changes on every node.
Concepts
The product and engineering team worked tirelessly on finding ways to create a generational leap for the platform that would allow the model to be far more capable than before.
Aditya Sankhe
Let’s think of ConversationKit like a live agent in training; capable of understanding customer messages, and then looking at a script (dialog) to know what the solution is.
1. Semantic Traversal
We reimagined ConversationKit’s technical foundation to understand entire messages and use semantics to traverse dialog, using vector databases and embeddings.
2. Dynamic Responses
Semantic traversal drastically increased the scope of responses. Using entities, and variables allowed for dynamic, and personalized messages.
3. Variation Nodes
Due to the dynamic nature of the dialogs, the need for creating entire dialog variants was redundant. Instead we utilized variation nodes to choose appropriate paths for conversations based on region and language.
Solution
Design Philosophy
With the heavy reliance on semantic traversal, messages, and dynamic responses it was imperative to find an intuitive and consistent way for admins to configure dialogs.
Messages Centric UI
Leveraging the robust messages design system, ConversationKit’s mechanism could easily simulate conversations, and users could have a 1:1 comparison of complex elements link rich links. Semantic traversal also became more intuitive for users to understand and work with.
Final Designs
The product and engineering team worked tirelessly on finding ways to create a generational leap for the platform that would allow the model to be far more capable than before.
Key Benefits
1. Solution Capacity
Teams can populate all 6400 solutions with significantly lower efforts and without dedicating an entire dialog to a solution.
2. Modularized Strategy
Dialog strategy does not depend on system capabilities and can therefore be more fluid with less points of failure. Modularization of dialogs makes it easy to identify changes.
3. Generative Opportunities
The platform can also work hand in hand with upcoming generative projects. Features like generative assisted dialog graphs, impact analysis, and visualizations of generated dialogs based on message volume are in progress.