---

When people think about conversational AI, they often imagine a simple back and forth exchange of dialogue with a chatbot. A human explains their inquiry to a bot, and the bot responds with relevant information and perhaps some pleasant conversation. That might be enough for a Loebner prize project, but in the case of large organizations most users aren’t arriving at a website looking for just a chat. They are trying to achieve something, and this AI experience is going to need to form a useful part of getting them to that goal.

For organizations, a user’s perception of a bot is enhanced by not only what the bot knows, but more importantly by what the bot is able to do for them. So:

• A banking bot could offer to put an international travel marker on your account right there in the conversation (because it knows you’re abroad and has authenticated you) rather than telling you how to do it yourself online
• An IT support bot could request access to a system for you (knowing that you’re eligible and populating the relevant forms behind the scenes) rather than telling you whom to email
• A customer service bot could change your address from chat rather than directing you to an online form and interrupting your experience

In all these cases, empowering a bot to perform actions provides a better experience for users and reduces costs to the business. On the other hand, designing, implementing, and maintaining these projects can present a new set of challenges. It can be hard to know how broad the scope of your project should be.

Whether you are considering your first conversational project or already have a bot in production and want to expand its capabilities, here are some of the questions I find it useful to ask.

Exactly what user requests do you want to fulfil?

With chatbots, your primary aim should be to improve users’ experience of their overall journey. After all, if chat doesn’t provide a great experience then users will simply use alternative channels, negating any cost savings from automation. Any conversation with an organization is almost always part of a longer journey, whether it involves a website, a mobile device, or social media. This means that when designing bots, it is vital to model requirements in terms of user journeys rather than in terms of traditional technical specifications. This helps focus on the key issues: what pain-point are you trying to solve for your users, and why is a conversation with them at this point better than a form, a website, or a visit to the shop?

To answer these questions, make the most of whatever data you can. Mine your existing chat conversations for the most useful activities. Identify the systems most often called using your API logs. Analyse the publish and subscribe topics in your messaging systems to get a better idea of the things that employees regularly need to do for customers.

Messaging itself as a communication medium can be a great driver of data. Messaging systems help track users through your website, and their interaction points highlight where users struggle in their journey. Individual conversations, whether with a human or a bot, provide context to the issue and can give feedback on the resolution.

Look for frequently occurring conversations where the user has a clear need to get something done but either struggled to find the self-service option, or found they needed additional help to complete it on their own.

If you’re designing a new chatbot, look to your existing channels for insight into the most common actions your employees perform on behalf of customers. Make sure that customer services employees are involved in the design process. They will be able to tell you which enquiries most often result in them taking what actions, and will often be pleased if frequent tasks can be automated away to allow them to concentrate on higher value tasks.

But don’t let the data limit your imagination entirely. Remember that great conversational experiences can differentiate your business, and that surprising users with your bot’s capabilities can be a particularly effective way to delight. Some of the best conversational journeys are the ones that users didn’t know the bot could complete. One of the great things about conversational interfaces is that a new capability doesn’t require a new webpage or a website redesign. You can try new experiences very quickly, and only present them when you have a very high confidence from the AI that the user intends to follow this journey.

Is chat the right channel for this action?

Because of the growing popularity and benefits of conversational interfaces, it can be tempting to try to fulfil every conceivable action through chat. This is a mistake. User experience should be the main consideration. Which user journeys really benefit from chat as part of the interaction?

Good use cases will often be ones that exploit the key qualities of conversational AI:

Conversational AI can respond instantly and at any time of the day, giving you 24/7 accessibility.

Your web page is there for your customers 24/7, and might be the best way to select and purchase a product. If a customer has a question about a particular product or delivery, however, they may need to come back another time. Conversational AI interfaces are ideal for questions or actions needed in the moment. For instance, a mobile phone user might ask, “What is this international call I’m just about to make going to cost?” They might not stop and delve into their contract terms and conditions on the website, but they might well quickly ask a messaging system (for free) using the device in their hands.

Conversational AI can be context-aware of web pages and help people who are uncertain or concerned about a web journey get through it, where otherwise they’d drop to another channel.

If someone is filling in a form about types and values of items for insurance and is unsure (or reluctant) to include a particular piece of information, they can ask safely about whether it does or doesn’t count without going backwards and forwards through the form to experiment with different values or declarations. You can have an automatic structured conversation to help them come to the right declaration, and ensure they understand the consequences of mis-declaring something. This is particularly good for application forms of all sorts!

Conversational AI can make decisions, transparently or hidden from the user, and respond appropriately to the situation.

Transparency is generally best: when a bot picks up a conversation, the user should know who they are talking to and how it can help. But sometimes full disclosure isn’t the right thing to do. If, for instance, a customer conversation shows signs of a fraud attempt, you might want to flag the account for review by a human while continuing the conversation and stalling for time. This is a much better experience for both parties than just giving a blunt error message or directing the user to another channel. If the conversation is later verified, the user doesn’t need to be further inconvenienced and the AI can finish it from there. If it is determined to be fraudulent, the conversation can be drawn down a safe dead end to help identify the bad actors.

They don’t require any app installation, and little to no page space.

There are clearly places where voice systems have unique advantages, e.g. in a cockpit, while driving a car, or when hands must remain sterile in an operating theatre. Messaging-based systems can also be extremely lightweight, and so can trigger conversations and leads that a user wouldn’t install an app to start.

Conversational AI can let the user decide whether they want an anonymous or identifiable conversation. With sensitive or embarrassing issues, for example regarding mental health, a user might welcome a conversation that they know is anonymous and will not be read by a human. A conversation could start that way, and then after a real issue is identified the user could choose to elevate it and pass on only certain details to ensure an efficient referral.

What’s a bad use case for Conversational UI?

Bad use cases are ones that are already better fulfilled by other visual interfaces. If you’re dealing with detailed location information, dynamic maps are a brilliant way of presenting it that provide users with options to continue their overall journey (e.g. by getting directions). If you’re making a detailed comparison of two products, a side by side table is often most useful. If you want to know what colour looks best, a beautifully rendered 3D model is hard to beat.

Regardless of whether your bot communicates via chat or voice, short messages are better in a conversation. If you have no alternative but to reply with a Churchillian speech or Tolstoy novel, maybe a conversational interface isn’t the best choice. If your use case involves presenting large amounts of information, detailed images, or locations, then it may be worth considering another channel or at least adding a non-conversational element to your chat window. If a user asks about bank charges, it makes more sense to link them to a clear table than to try to summarize it in a few lines (or worse, explain it in full!).

A great example of a common conversational UI mistake is using a chatbot to collect a large set of structured data. Chat is very rarely the best way to accomplish this. A form is already familiar to users as a way to complete this task. Away from the keyboard, we don’t dictate to people as they fill in a form for us. Instead we fill it in ourselves, at our own speed and in the order we choose, and then hand it over. It’s no different online. If you want to enable people to set up an account via chat, it will usually make more sense to provide a form to gather details rather than try to do it with a series of questions. Not only will this save the user time, but it will avoid the need to create a complex conversational dialogue for data entry.

Mixed modal interfaces can help here to bridge the visual and conversational experiences without disrupting the user journey. Need lots of structured data to be provided in one go? Present a modal form outside of the chat window, which on submission transfers all of the entered data to the bot to continue the conversation. Want to locate your nearest shop? Send a thumbnail map in the chat, which when clicked directs the user to a mapping experience.

How hard will it be?

Once you’re sure that your action use cases are well-suited for chat, you can start exploring what would be involved in building them. When performing an action from chat, there should be three parts to the interaction. First, the bot will need training to understand that it should perform an action. Many platforms provide sets of retraining on common industry tasks, and we maintain specialized sets for our trained assets. All the same, the nuances of your organization will mean that some training is necessary, just as it would be for an experienced human employee from a different company.

Second, the bot will need to perform the action. Most actions will involve the chatbot interacting with your business systems based on what the user has told it. Which of your systems will be involved in each use case? If they have APIs, then the integration is likely to be more straightforward. Most organizations have systems which don’t support yet support API connectivity, but this doesn’t mean they can’t benefit from automation.

If you have a legacy ESB or Messaging Bus you might benefit from an iPaaS solution which automatically wraps those interfaces in easy-to-consume APIs. If you are dealing with a legacy system, you may benefit from using Robotic Process Automation to add and retrieve data without needing to develop programmatic interfaces. This adds a degree of complexity to your solution, but it may well make sense if the interaction volumes are high enough. Remember that if your business systems change, your chatbot actions or automation may have to be maintained to match.

For organizational and security reasons, some systems will be very hard to connect to regardless of the integration technology. In an area as new as AI, where the initial launch needs to build business confidence, those probably aren’t the best places to start.

Finally, the bot should report back on the results of the action. It needs to be sure of the state before and the state after. How often have you heard a human agent say “Let me just check that’s gone through?” In a conversational paradigm, the bot takes responsibility for completing the task on the user’s behalf. It’s not self-service, so the bot must be able to confirm the request has been fulfilled correctly. This means that APIs to query the state of a record as well as change its state are equally important. Designing and building your actions in an error-proof and defensive way takes a little longer, but makes them much more robust and trust inspiring for users.

Where do I start?

Your aim should be to build a conversational system which fulfils requests in a useful, reliable, and delightful way. That’s going to take work, so which journeys should you focus on? Successful projects will balance the effort involved in building a use case with the frequency that users will use it. This ensures that the chatbot satisfies users, while making sure that the business benefits from the highest value automation targets.

Transactions that are easy to automate and happen all the time are the low-hanging fruit for automation. “Long-tail” requests which only come up rarely are less likely to show benefit for the business or provide the volume of conversational data required to help train the AI. The first user journeys you fulfil with conversation and automation should be ones where the conversational element genuinely enhances the experience, the back-end processes are easy to automate, and the frequency of occurrence means that both users and the business benefit maximally from day one.