Suki - Customer Service Bot
Theralogix is a company that specializes in supplement subscriptions. Their goal was to reduce the need for call center and live agent chat interactions. Over two years, we iterated on the Suki bot to make sure that it met end user and company needs.
Research
Theralogix initially expressed interest in a voice bot and a web-based bot.
They had a much simpler chatbot that was already live. So, I requested any usage data they had from it and was able to use that data to determine what their most common requests were.
I also requested audio recordings of customer requests handled by their call centers to help me to understand what types of queries our voice bot might get, as well as the language it should use in response as a customer service agent.
Defining a Persona
I had a discussion with Theralogix about the importance of defining a persona for the bot. Since there would be multiple contributors it would be helpful to have a shared understanding of the types of things that Suki would say. Their marketing team brainstormed and created the persona of Suki: approachable, helpful, and trustworthy.
Initial Build
Overwhelmingly, the data pointed towards customers needing assistance with cancellations and returns. We did not have the ability to immediately implement something that would help with cancellations (we opted to have Suki explain how to contact customer service directly re:cancellations), so our initial focus was creating a bot that could gather information from users and create return tickets for Theralogix agents to handle.
Although it is possible to collect return information from users in a conversational manner, in this case, I decided it was better to use a form. When collecting this volume of information from a user, constant back and forth with a bot can feel tedious. The form also gives the user an immediate snapshot of the information that is to be collected, thus reducing anxiety surrounding an unknown process.
Theralogix also provided a list of frequently asked questions for Suki to be able to answer. Most did not require any kind of flow, however if users wanted to buy a product, instructions differed depending on circumstance, so I created this flow for that.
Special Considerations For Voice
A lot of the FAQ content contained answers in multiple paragraphs. I shortened the content to make it more manageable for listeners. I placed important information at the beginning of answers to increase the odds of people hearing and remembering it. During testing, I listened for how things were being pronounced and made edits to the text, sometimes spelling things phonetically so that the VA would pronounce things correctly.
The voice bot release was pushed back on several occasions and Theralogix eventually decided not to go live with it.
Initial Results
The first week Suki web bot was live, it had an approximately 60% answer rate. I analyzed chat logs and determined where there were gaps in the knowledge base, then worked with Theralogix to produce content for them. Three months later, this chatbot was able to consistently handle 80% of user queries. Rates of users escalating to a live person also went down by 15% in that same time period.
Iterations
After Suki was stable, and consistently answering questions at a rate that Theralogix was happy with, we revisited subscription cancellations, one of most common queries that would require a person to contact a live agent. Theralogix expressed interest in having Suki be able to handle subscription management requests in general. Another employee and I looked at what the Recharge API was capable of doing and presented some potential functions to Theralogix. Theralogix requested Suki to be able to do the following: cancel subscriptions, change a refill date, pause a subscription, restart a subscription, change shipping address, and view current subscriptions and their next refill dates.
I went back to the usage data, and determined that if Suki could cancel subscriptions, pause subscriptions, change refill dates, and restart subscriptions, that would handle nearly 95% of all subscription management queries. We decided to focus on these functions for the next iteration and add the other ones at a later date.
I created flows for subscription management.
One challenge was needing the user to be logged in in order to make changes. I created a flow that would be triggered when a user wasn’t logged in if they asked for changes to their subscriptions. After the user logged in, they would be returned to the main flow where they could make edits to their subscriptions.
A Note on Natural Language
I utilized a form for subscription management due to limitations with software. I think that this is something that could be handled well conversationally. Here is a flow I created that demonstrates a more natural sounding dialogue that could be implemented in future iterations, should software allow.
Results
Suki was able to handle subscription management requests. Handling subscription cancellations became one of its top functions, reducing the need for live agents to manage these.
