Plan your bot
On this page we will introduce some core concepts to consider when building your bot with Teneo. In contrast to previous pages in our Build Your Bot section, we take a step back from implementation details here and focus on the big picture of your final bot instead. Typically, a bot implementation consists of the following stages:
Before starting to build, let's take a step back. Within any business there is a wide range of possible uses for conversational applications. Try to consider all possible options and evaluate them regarding:
- business objectives and priorities
- volumes of possible interactions
- applicable communication channels
- support within the business to adopt the new technology
Once you have identified the area and goals you are looking to achieve, you can start narrowing down the use case.
When you start building a bot, develop a clear understanding about the tasks the bot is suppposed to solve. Start by identifying an appropriate business case. Focus on the business problem, not the technology. Ensure there are sufficient volumes of interactions to deliver the expected returns. There can be various business drivers, here are some frequent ones:
- cost reduction / optimization
- increased sales conversion rate
- increased customer satisfaction
- increased employee efficiency
- technology differentiation (the conversational platform becomes a part of the company product offering).
Don't forget to establish key performance indicators that allow you to measure the success of the conversational application and to understand the value that it is providing for your business.
So by now, you know where you're heading, but before you proceed with building the bot, you first have to determine its scope. Where should you start? Which questions or tasks should your very first bot be able to handle?
The analysis of data, talking to subject matter experts and finding natural use cases that benefit your business will help you narrow down the scope:
Based on this analysis you can then decide on the core functions or conversations that you intend to build. It's a good idea to select specific areas of the business to cover, and to make the scope clear to the end-user.
With a combination of some core flows to satisfy requests in your chosen area and some flows that belong to the extended scope of your bot, your bot is well equipped to answer any questions related to this area, albeit some of them in a very general way.
Sometimes, natural language data from previous customer interactions is available. Examples include:
- live chat interactions
- call center transcriptions
- customer emails
Such data is a great starting point to get a feeling for what kinds of requests your bot will face. If possible, you should do some kind of quantitative analysis of the existing data to identify the most common questions. Once identified, you can then let your bot deal with higher frequent subjects first, as they are more likely to pay off quickly. Moreover, you can use some of the pre-existing data as example inputs to train class triggers.
During the development of your bot, you should always spend time with subject matter experts. They are:
- likely to know or at least have a good estimate for what users are most likely to ask your bot about a given domain.
- familiar with the processes of how an agent/bot should reply. Many use cases cannot be built without knowing these processes beforehand, as those will be closely related to company policies.
- aware of company or domain-specific vocabulary that may need to be added to the general language understanding part of your bot.
Try to select processes that allow the customers to get something specific done and make sure that these processes can be fully automated from beginning to end. This will delight the customer and also achieve the most benefit to the company.
When screening previous customer interactions (for example call center interactions) you will rarely find FAQ-like conversations that consist of a single customer question getting a single answer from the agent. Rather, the conversations are likely to involve several points of clarification from the user to get the exact answer or action required. The customers are pleased if we can help them with their exact request. This is true for call centers but also for conversational AI platforms. Instead of creating FAQ-flows, we will thus create some more advanced multi-step flows that understand exactly what the customer requests.
At this point, you have set the goals and the scope for your bot. Now it is time to actually start building it! We recommend for you to start with a rapid prototype of some dialogues and conversations that you expect your bot to be able to handle. Just get going by implementing the rough outlines of the dialogues together with subject matter experts. Once your prototype is up and running you can then go ahead expand it with more special features and requirements.
For many scenarios, you can have a first draft of a flow in Teneo ready in just a few hours. This will allow you to test if the dialogue you have designed is natural and, most importantly, if it provides a good user experience. You can roughly follow these steps, that will help you to rapidly create a prototype.
Before modeling flows, you should first collect some example questions that you expect users to ask your bot:
- start with the "happy paths", i.e. default scenarios in which everything goes as expected..
- consult suitable data collections (if available).
- guess with your team what users may ask (if not data available).
- produce some sample inputs and variants thereof.
Drawing out the flow logic graphically to represent the dialogues is a great place to start your design. These can then easily be translated into the same flow design graphically in Teneo.
- sketch the logic of the dialogues you are intending to build graphically.
- verify with subject matter experts whether what you sketched is an adequate representation of the business process.
- check whether the dialogue collects all required information.
- identify if backend integrations will be needed.
- minimize the number of steps, be as efficient as possible. For example, if you are booking a meeting room and the user says 11 o'clock you can reasonably assume that that denotes 11am without asking the user for a clarification.
Once the core ‘Happy Path’ for the dialogue design is established we recommend creating the flow in Teneo.
- start creating flows with class triggers, add approximately 15 examples for each. You can use the ones you collected in the first step!
- focus on user experience before robustness.
- check if user experience is appropriate for audience and channel.
- identify appropriate usage of buttons, cards, clickable lits and the like. They may make the implementation easier, but don't overdo it!
- try out some dialogues with colleagues and check if the user experience is good enough and in line with company's tone of voice.
Once you have built a few primary flows for your prototype bot, you should expand it a little bit before then going on to thoroughly test it. Let's look at the following 3 concepts for expansion:
In human to human interactions, each sentence is considered in relation to earlier parts of the conversation - we understand that inherently. In order to build a smart bot, we need to do the same. All of this is easily implemented in Teneo and will give a great user experience!
- follow-up questions depend on the dialogue context. For example, the answer to "How about tomorrow" differs depending on the context, e.g. weather or the availability of someone or something.
- context dependent triggers can be used to model the dialogue context.
- logical links may have to be established in order to be able to pass the subject of the conversation: "Do you stock the iPhone 7" followed by "How much does it cost?".
- appropriate memory length should be maintained. It is nice to remember what the user said, but can get strange if the bot remembers it for too long. We recommend maintaining it for 3 turns.
- interruptible flows can be interupted and can then later be re-visited and continued. For example, consider being part way through ordering a product when the user asks something about the warranty. You may want to answer the warranty question but then continue with the ordering process.
From the very beginning, make sure that you setup your implementation in way that it allows for future growth of your bot. Users will not want to switch from one bot to another to perform different tasks. Be aware that your bot can end up consisting of hundreds or even thousands of flows run from the same solution, and consider ongoing maintenance. This will pay of when your bot grows. We recommend you to:
- name your flows logically and consistently.
- organize your flows in an appropriate folder structure that allows for scalablility.
- group repeated steps in subflows. This way, you can re-use them without having to repeat the steps in each flow you need them.
Once you are happy with the behaviour of the various flows you have built you can add robustness, ensuring that different intents don’t overlap.
- add more training data.
- refine existing training data.
- add syntax triggers where the intents are close and more precision is required.
- add hybrid triggers to benefit from the coverage that the class triggers provide and the precision of a syntax trigger.
- add some flows for the less happy paths, i.e. flows dealing with requests that are slightly out of scope.
- run automatic tests to highlight and then resolve any issues.
Once the first iteration of your bot has been produced, you need to preliminary publish the solution, and give it to a group of test users to see how they get on.
- test scope: give your test users a high level scope and scenarios to test rather than being too specific with testing instructions. The responses will turn out to be more representative this way.
- expectations: the test users should help you train the model more than testing the exact result of your initial build.
- feedback: you should collect both qualitative and quantitative feedback of the overall user experience.
- class trigger coverage: you can add some of the inputs of this test phase as positive training examples to class triggers which will improve their coverage.
- necessity for syntax triggers: in case of overlaps in coverage between similar class trigger intents, you should add syntax triggers or hybrid triggers.
- refinement: after each round of testing, there will be a step of refinements based on the test feedback.
Your bot is now ready to be released to the outside world! However, before you publish, think of a publishing procedure that includes testing and deployment of:
- the conversational solution itself
- its integrations to backend systems
- any middleware such as channel connectors
- any front end applications
These workflows and procedures shall be applied to environments of all stages: Development, Quality Assurance and Production.
Now that your bot has been fully built and published, the implementation process does not stop! The real customer dialogues that are being run through the bot will create a rich data source that we can use for many purposes. For example, having access to this data may help to improve the performance of your bot, and it may deliver valuable business insights.
Naturally, looking at the log data from user chats with your bot gives you a good insight into what works well and what doesn't and thus the potential to improve your bot based on this data. From within its bot building platform, Teneo will proactively highlight where to:
- improve the coverage of your class triggers by adding more training data.
- disambiguate the machine learning model by either confirming or re-assigning inputs that have ended up in certain class triggers.
- enhance precision by either refining existing or adding new syntax triggers.
Moreover, analyzing user chat data can help you to identify out-of-scope yet related topics that the uses are requesting. This can be useful to prioritize additional coverage in coming releases and thereby further increase the success of your bot.
Chat data can also be used to derive usage statistics. These can be fed into existing Business Intelligence systems and, together with additional data, can be used to gain an understanding of how the bot is performing - both in terms of technical functionality but also in terms of whether key performance indicators are delivered and still in line with the business expectations.
We have already seen how the stored user data can be used to improve and measure the performance of your bot. But there is even more value to it than that. Performing a deeper and more structured analysis of the chat data can give you valuable business insights from the customer's point of view. Unlike web-driven UIs, where users can mainly select from pre-defined options to assess your product, querying freeform user data allows you to discover what the users really wanted, e.g. products or product combinations that are not yet offered.
Dialogues are basically a structured collection of unstructured data. They are structured into user inputs and bot responses, which are ordered sequentially. And while the bot's responses are pre-defined, the user inputs are freeform and unstructured. The same content may potentially appear in a multitude of different ways and variants. To access the key content, a rich query language is required that has been designed from the ground to understand human language. Even more so, to resolve relational user inputs like "That's fantastic" your query needs access to previous turns in the dialogue to find the subject that the user denoted as being fantastic. Teneo's Query Language is available to build such queries on chat data from within the bot-building platform. It has been optimized to make this complex task much simpler.