When Things Get Out of Scope

[BEKOBCN]

When Things Get Out of Scope

You might know this situation. You agree at the beginning of your project on a certain scope. Your bot shall be able to automatize this and that task at launch day and be able to answer a certain range of questions. In many cases we are talking here about a reduced scope which will be expanded bit by bit (or we could also say Sprint by Sprint ). Now, the end user who will be talking to your bot on launch day will probably not know about this internally agreed scope and expects a coherent understanding of (reasonable) questions.

In order to make your bot appear as intelligent as possible from Day 1, it is a good idea to create a so called Out of Scope flow in your project. This flow can then help with:

• a simple coverage and handling of topics which will be handled in a later phase of the project, and not directly project-related topics (e.g. the marathon your company is sponsoring and which pops up on your webpage but which is not related in any way to the topics of your bot)
• a more intelligent appearance to the end user when an intent is not recognized yet as it should

Let’s Build an Out of Scope Flow

The general idea behind this flow is to recognize topics the user mentions via keywords, let the user know that the bot has understood him/her correctly, and answer to the intent as good as possible. Many times this will just be a standard redirection to your webpage, or even just apologizing that currently you cannot help the user with this topic. But doing so sheds a much better light on your bot then having the user input fall through into the Safety Net, and answering something like “I don’t know what you mean.”

So, let´s have a look at how we create an Out of Scope flow:

1. We create an Entity which holds all the keywords we want to recognize, and normally also variable values which give us more information on the recognized keyword. In this example, we will use a variable of String type with the name Normalized which holds the name of the topic as we want to display it back to the end user. As you see in the below screenshot, we use several synonym language objects in this example to have a higher coverage of keywords we want to cover, and by means of the Normalized variable we always give the same topic name back inside our answer.

Entity Example:

2. Now we create the Out of Scope flow itself , and add to it a flow variable called sTopic , with an empty String as value.
   

3. We create a trigger which uses our new Entity as Match Requirement, and use Data Actions to set the value of our topic variable to the normalized value of our Entity keyword. Please make also sure to set an adequate Order Group under Triggering. Since this is a keyword-based out of scope trigger, it should sit quite low in your Intent Trigger Ordering.
   

   

4. Then we set our answer and include the value of our topic variable by ${sTopic} to the response text.
   

   

5. Finally, we test our answer inside the Tryout, and voilà, our Out of Scope flow is ready to be used.

Tryout:

in Teneo Web Chat:

Now we can cover many project-related topics in a meaningful way, even if they are currently not part of the bot’s knowledge scope. Your end users will appreciate to not see the Safety Net answer that often anymore!

Please note that you can obviously also implement a much more fine-grained intent recognition for your Out of Scope flows than making only usage of keywords, but this will probably lay outside of the scope of this flow here then.