Building a conversational AI for health & life insurance Part 1
This post was written by Anthony Attwood, Senior Software Engineer.
This is the first of a two-part series that looks at the assistant we’ve developed at Boundlss. The first part covers what we’re trying to achieve with our conversation & messaging engine and why it’s important to our business. The second part will cover some of the technical details.
Sorry, I didn't understand that
One of the essential parts we’re developing is the conversation & messaging engine that makes up our assistant and blends multiple chatbot agents and real human coaches into a seamless chat experience for our users. By combining humans and multiple chatbot agents, we can gradually improve the experience over time, without annoying our users with "Sorry I didn't understand that" responses when the assistant comes across a message it can't handle
What design goals are we trying to hit?
- We want our chat system to be able to start with 100% human responses, and gradually ramp up the automated responses as our agents get better.
- Automated responses should be delivered within 5 seconds, and human responses delivered within 45 seconds.
- Flexibility to support other domains besides health and wellness. We want our chat experience to have the ability to accommodate our clients’ business domains in the future.
- Centralise the content that our chatbot agents respond with into our own systems. Leaning heavily (as you’ll see) on third party chat solutions runs the risk of spreading our content over multiple systems, making it hard to administer and maintain.
Currently, we have two major types of chat interaction. The first is a pre-scripted conversation developed by our health content team that we call Structured Conversations. In these, possible answers are presented to users for the user to click on as they work their way through the script. If you think of the old choose-your-own-adventure books, you wouldn't be too far wrong. It's basically a simple conversation tree (or graph if you prefer, the conversation path doesn't need to be acyclic) where each node is a message the assistant can send, and each branch is an option the user can take. We present the options available to the user as simple buttons in place of the chat text area, making it a series of single-click actions to progress through the script – users can still enter free text, but then it drops out of the conversation script. As you can imagine, this is not a very sophisticated system, but we've found it doesn't really need to be very smart to provide an effective and engaging experience.
The other key conversation type for us is freeform conversational chat, the kind of thing lots of researchers and companies are trying to build effective chatbots for, and which, if you've ever tried to talk to one, can be a pretty hit and miss experience. Since we're trying to improve the health of our users, making our messages engaging and relevant to each individual user is important.
Come back for part two next week to see how we do it.