How to design a chatbot that customers actually like

Fast, friendly, and personal, or missing the mark entirely?
25 August 2020

The pandemic has dramatically changed how businesses support their customers. Customer support now needs to be online, and it needs to be fast. 

Many businesses are using messengers to support their customers in a conversational way that is fast, friendly, and personal. To make these support experiences work at scale, they are turning to chatbots and automation.

Well-designed chatbots are the key to scaling conversational support, but there’s a lot of debate around what makes a good chatbot. Many guides advise starting by designing a ‘persona’ for your bot — find a cute avatar that’s on brand, choose a name, maybe teach it some witty banter. This can be a big time investment, and should actually be bottom of the list. The customer isn’t looking for a chatbot to be their friend. It’s much more important whether the bot can actually give them the information they need — and it should stay out of the way if it can’t.

Great bots start with a set of principles. Good principles serve as an enduring foundation for decisions, allowing focus to stay on the customer experience. Here are three big principles for building support chatbots that we believe can benefit every business. 

# 1 | Don’t over promise the user

Chatbots have shown huge promise for resolving support issues from the beginning: customers save time, and businesses save money — a clear win-win. But the sticky spot is designing bots that truly help customers. There are many bots that lead to bait-and-switch experiences: introducing themselves with great fanfare, but failing to actually help after the user spends time typing out their problem. This is a disappointing experience.

There are a few ways to avoid this. First, set expectations with customers. It’s a bad start when a bot says something as general as “Hi, what can I help you with today?”, as very few bots can help all customer queries. 

Instead, the bot should give hints as to what it can help with. A good bot might briefly describe some common things it can do, or use user context to suggest relevant queries it can help with.

If your platform supports it, the bot should quickly assess how likely it is that the user’s query can be resolved by an automated system. Bots are most helpful when it comes to common, simple queries that don’t require the bot to develop an understanding of complex issues. A good bot will proactively funnel complex, long-tail issues over to your human support team. 

If the bot can’t help, it should let the customer know early, and explicitly excuse itself. If customer support isn’t available, redirecting a customer to a help center is preferable to getting stuck going round-and-round with a bot that knows it can’t actually help you.

# 2 | Don’t trap the user

Nothing leads to a worse customer experience than someone feeling like they’re trapped in support jail. A well-designed bot will let customers exit at any time, even if there isn’t a human to talk to. Don’t be tempted to keep customers in the bot flow because you don’t have enough human support resources. 

Trapping the customer without a place to go, or building a navigation flow without a clear exit, is not good for the customer experience. Bad experiences lead to frustration, negative word-of-mouth, and an unwillingness to later engage with self-serve content that can help.

The best way to allow customers to exit the bot depends on context. The most obvious solution is to have an always-present button that lets the customer exit. But some less obvious features will work just as well. 

Consider designing your bot to say one thing and then stop unless spoken to again, or to bow out if a user ignores its prompts. This lets customers exit by default. You can also design your bot to recognize exit syntax — words like “exit” or “quit” or “go away” — that a customer may say. The end goal is to make it easy for a customer to leave the conversation if they need to — the responsibility lies with the business to facilitate this.

# 3 | Respect the users’ time

Customer relationships are the cornerstone of business success, and you can’t build great customer relationships without great experiences and personal communication. The “personal” generally means communication that feels friendly, easy and quick. Quick is the key word, because time is precious and one of the most important parts of customer support. We all know how it goes — when a customer feels their time is wasted, they’ll let others know about their frustration. 

From a technical standpoint, this means bots should have no artificial loading delays and no walls of text. Customers also shouldn’t have to hunt for answers through an endless tree, or be encouraged to stay in a support interaction that can’t help them. 

If your bot has certain flows that some customers must follow to progress their request — for example, if the customer must answer questions about their company before talking to sales, or enter their product make and model before accessing technical support—these flows shouldn’t be triggered until they are needed. Don’t front load them automatically to customers they aren’t relevant for. Similarly, if customers are sometimes required to grant privacy permissions, or authenticate, the bot should prompt for these only as needed.

The impact of each individual delay is small, but taken together will add up to a support experience that feels either fast and respectful, or frustrating and uncaring. Customers will notice when this principle is followed: they’ve been jaded by waiting on hold while a voice tells them how much ‘their time is respected,’ so businesses that actually do follow this principle stand out.

If you’re looking to design or use chatbots to improve your customer support, the best place to start is with customer-centric design principles. While the technology is advancing rapidly, the foundations of good experiences will remain.

This article was contributed by Fergal Reid (PhD), Principal Machine Learning Engineer at Intercom.