Best practices
Teneo enables you to create great conversational experiences that can help you realize business goals and improve the customer experience. However, the way to get from an idea to a successful bot is a relatively new journey for many.
We will present you some bot design principles that will help you on this journey. We will give you some insights in best practices we have collected over the years and show you how small changes can make a big difference in how your bot will be experienced by its users.
The key to a successful bot is a positive user experience. No matter how smart the underlying technology is, if your bot is not helpful and pleasant to talk to, no one will want to use it.
With Teneo, you can aim higher. You can build a bot that is not only helpful, but also efficient, and not only pleasant, but also easy to use and available via multiple channels. Depending on your application domain, you can also think of giving your bot some personality traits that make the conversation a memorable experience that the user would wish to repeat.
So, when creating your bot, always bear in mind how you want your bot to be experienced by its users.
| What users expect a bot to be: | What users do not want a bot to be: |
|---|---|
| - efficient: helps users to achieve something, without too many deviations. | - forgetful: forgets important information, remembers irrrelevant facts. |
| - intuitive: can communicate (almost) like a human does. | - stubborn: keeps asking the same questions, seems to be stuck. |
| - available: is available on different channels and devices. | - scattered: has no clear purpose, leaves user puzzled what they can ask about. |
| - easy: has a clean, straightforward interface that is easy to use. | - FAQ only: is restricted to answer a certain set of questions and nothing else. |
Let's have a closer look at some key concepts that bring you closer to the positive user experience that you want to achieve.
Set user expectations
First you have to make sure to set the right expectations for the users:
- communicate the scope to the user: It should be clear to the users which tasks the bot is designed to help you with.
- don't pretend to be a human: It is nice if your bot can speak like a human, but it should never pretend to be one. Make sure that the users know that they are talking to a bot.
You can summarize both of these points in a well designed greeting message.
Anticipate the unexpected
Naturally, you design your bot to deal with requests within a certain domain. At this point, you may not have thought about what happens if your bot is confronted with requests that do not fit into this domain and the scope that you have designed it for. However, for a good user experience, it is important that your bot has a suitable answer for out-of-scope requests. That does not mean that your bot should be able to answer each possible question. It's more about pushing the limits of your bot by letting it listen to a bit to the left and right of what it has been designed for and thereby trying to lead the user back to a path where your bot has more knowledge and can offer help.
Partial input
Sometimes the user enters a very short or partial input which is insufficient to understand what the user wants. For example the input "current account" could mean the user wishes to find a balance, open a new account, has a problem with an account, etc. There are two ways to handle the situation. In both cases, you build some lower ranking flows that trigger on certain keywords, showing that your bot understood the request was about a certain keyword and then let your bot:
- Guess: The bot simply assumes the most probable meaning and goes on with processing this request.
- Ask for Clarification: The bot may suggest some options it could think of and/or asks the user to be more specific.
Unless there is an obvious interpretation of the keywords recognized, we recommend letting your bot ask for clarification. This will ensure that the bot fully understands the request before proceeding with its processing.
Adjacent to scope
User requests falling into this category are close to the scope of your bot, for example, they may concern a different product of your company for which the bot has not been implemented (yet). Whenever you can anticipate such questions that are outside of what the bot has been designed to do, you should consider building some low-ranking flows that recognize these.
- show understanding: Let your bot show that it understood what has been said, but that it is out of scope and thus no answer can be given.
- indicate scope: Lead the user to what the bot knows: _“Im afraid I can’t currently help with changing a policy, but I can help with selecting new insurance products and processing claims”. _
Out of scope
Some requests may even be completely outside the domain that your bot has been designed for, but the bot will still have to provide an answer. Teneo comes with a prebuilt safetynet flow which is ranked lowest of all flows and provides answers to requests that have not matched any other trigger of any other flow. However, there is more you can do to catch such requests before they end up in this safetynet:
- external systems: The request may be handed over to a forum query, company web search or similar. If a sensible answer is found, the bot returns it to the user. If no proper answer was found, the request is forwarded to the safety net.
- enhance results: Pre-processing the request before passing it to an external system can improve the relevance of the results. For example, you may use part of speech tagging to extract the salient points in a request or use synonym lists to replace local terms for British and American English.
Answers matter
Well written responses have a significant impact on how end users experience their conversation with a bot. Here are a few tips to take into account when writing the answer texts for your bot:
- length: Write complete sentences, but don't make them too long.
- channel: The length of the answer may depend on the channel, for example mobile, web, voice.
- language: Use easy language. Avoid passive constructions like 'the function will be switched on when the button is pressed'. Instead, write 'to activate the function, press the button'.
- independence: Try to write answers that make sense even without looking at the question.
- confirmation: Confirm what is understood by repeating the topic in the beginning of answers. For example: 'How do I cancel my order?' - 'You can cancel your order by...'.
- flexibility: Don't start answers with 'yes' or 'no'. In many cases, the same answer will be given to different variation of a question. Try to write answers that fit all the possible variants of question.
- variations: You may want to write several answers for one (important) question, to add dynamism to your bot and make it sound less repetitive.
- directing: Open questions, like 'What would you like to do?', have a higher risk for misunderstanding than closed questions like 'Would you like to know more about X?'.
- multimedia: Your bot's answer can include more than just answer texts - for example, a link to be opened or buttons that can be clicked. Keep in mind that the possibilities may differ per channel.
Select a tone of voice
Ideally, your bot should have a tone of voice that fits the company or product and keeps this same tone of voice throughout all parts of all conversations. Here are a few tips on how to proceed:
- fit your target audience: You should make it fit the company image, target audience and channel. A bot for sales of fun products to a young audience may be less formal than a bot for a financial company.
- be consistent: Review the small talk answers that come with Dialogue Resources and align them with the tone of voice of your bot. This ensures consistency throughout the conversation.
Handover to a human
Using a bot instead of human agents will naturally reduce costs. It also means means that since the bot handles the more mundane questions, skilled live agents can focus on higher-value activities. Nevertheless, there may be situations in which handing over from the bot to a human agent can be a positive action to take. Here are some examples of when a hand-over may be appropriate:
- explicit user request: Whenever a user wants to speak to a human agent, your bot should obey and hand-over.
- user profile: We may want to give users who are 'Gold' members easier access to a live agent.
- critical topic: An example is a user wanting to cancel a contract. Handing over to an agent shows that we take the user seriously and the live agent may win back the user as a customer.
- dialogue progress: Say we notice that the dialogue got stuck and the user shows signs of getting frustrated with the conversation. In such cases, we can pass the full transcription of the previous dialogue to the live agent. This makes it easier for the agent to help and may turn out to be a positive overall user experience in the end.
