Tracking and Using Sentiment in Teneo
The Teneo platform is delivered with a collection of agile, customizable tools that build on the usual intent recognition that natural language systems offer. Combined with Teneo’s unique infrastructure, these tools allow you to cumulatively monitor various aspects of user behavior during a conversation:
|Characteristics of user input||Categories||Examples|
|not happy about this
that was a nice answer
multiple one word sentences
|what DAY is this
i know, i know
what?? what!! what!?!
very good, extremely well
You. are. great.
|Abusive language||hate speech
|(clearly racist statements)
(threats of violence)
(explicit sexual references)
|I need an abortion.
How do I rob a bank.
My best friend died.
Let’s have sex.
I want to end it all.
What happened 9/11?
Think about these categories for a moment. Knowing what happens at the meta-level of a conversation opens numerous powerful possibilities. During the session you have an opportunity to identify and react to various situations that arise, tailoring the conversation towards a better user experience. After the session you are able to analyze user sentiment towards company products and services as well as towards acceptance of the system’s handling of the users’ issues. In this article we focus on use cases for sentiment tracking during the session.
Definitions of Teneo Constructs
To understand how user inputs are analyzed in real time during a conversation, it is necessary to know about some basic concepts in Teneo.
Language objects: Language objects are collections of language rules that represent a certain meaning. They are primarily used in Teneo as the building blocks needed to detect user intents. Language objects can also return information about what they’ve detected. For our system to be cognizant of sentiment, intensity, abusive and controversial language in a user input we use language objects that not only register the presence of one of these aspects, but also return which categories were found.
Listeners: A listener is a component of a Teneo solution that is evaluated various stages during a transaction, depending on their defined scope. Listeners in Teneo contain two parts: a language rule and an associated script (groovy or java). In this case we are using listeners that run on the arrival of a new user input,evaluating it for the specialized aspect they are looking for. After the listeners collect the information they are designed to collect, the user input goes on to be evaluated to find a response. The subsequent processing to find a response can be influenced by the listeners, but doesn’t have to be.
Variables: During a user’s conversation (session) with a bot, it is often necessary to record pieces of information such as the user’s name, the immediate context, or even data retrieved externally depending on the bot’s function, to name a few examples. This is done using global variables that are available at all times during the session. The variables have the usual types found in java or groovy: integers, Boolean, string, lists, maps, etc. The session variables and their state are tracked in a session log for later analysis.
Setting up the Infrastructure
Each of our concepts (sentiment, intensity, abusive language and controversial themes) is represented by a language object, along with sub-objects for each of the specialized categories.
We prepare four listeners which in turn use the corresponding main language object, and if a detection is made, record the information found.
This allows us to keep a running count of transactions containing positive or negative sentiment, as well as abusive language. For the current transaction we save lists containing the categories found, and for ease of use, Booleans to indicate the presence of abusive language and each of the two sentiments. The number of intensity cues found for a transaction amount to an intensity score, which can be used to home in on especially emphatic sentiments.
The sentiment library offers four “back doors” that allow you to customize sentiment detection to your particular business case. You can
- add items that are missed by positive or negative sentiment detection
- exclude particular items from receiving a negative or positive sentiment tag
The “back doors” are language objects that you customize with your project-specific adjustments:
For example, if your company is called “Mean Burgers” and “Mean” is tagged as negative sentiment you can prevent it by adding a rule for the company name in the language object SENTIMENT_NEGATIVE_EXCLUDE.PROJ. At that point, “Mean Solutions” will no longer be identified as a negative sentiment.
This also allows you to immediately react to new language developments, sudden viral catch phrases, hashtags or memes that represent a particular sentiment but which the sentiment library would not be able to know about. You probably know the phrase “I got nothing” from Seinfeld. We may decide this indicates a negative sentiment (having no idea what to do / say) and include it in the language object SENTIMENT_NEGATIVE_INCLUDE.PROJ.
Use Cases within a Session
Now that we know what is happening sentiment-wise during the conversation, we can start to take intelligent actions based on the knowledge. The underlying idea is to improve the user experience, by taking constructive action if something is going wrong, as well as rewarding the user for positive interactions with the system.
Direct responses to sentiment
The first priority in a conversation is to answer the user’s question. Solution content that specializes on the relevant issues is therefore prioritized quite high. Suppose we have a special response for complaints about service: “Your service is rotten” – we want to register it as a negative sentiment, but we also want to respond to it with the intended response. Other content may be focussed on the occurrence of a single word or synonym, and try to draw the user out by diagnosing the user’s intention. At the very bottom of the hierarchy is what we call a safetynet, which contains fallback responses.
A nice use case is to set up sentiment responses just before the safetynet, where it’s quite all right to respond to something as vague as the user’s sentiment. If a positive sentiment was expressed, the bot reply accordingly:
On the other hand, if the user is unhappy, the bot can try to restore goodwill, by showing it takes the sentiment seriously:
Since we are counting occurrences of sentiment, we might want to take a certain constructive course of action if we notice repeated negative reactions from a user. In this example we’ve defined a threshold of 3 negative sentiment detection’s. If the threshold is exceeded, the bot initiates a chat handover. Our logic would also consider the case that a user was negative and abusive and block the handover. We don’t want to pass on an abusive user to a live agent. Rather, we want to assure that the user is serious about the issue they want solved.
A chat handover is only one course of action. Another might be to initiate a feedback survey, in which users explain what they expected of the bot, and why they are dissatisfied.
You may also want to reward users who are especially positive by offering a special discount code, etc:
Dealing with Abusive Language
Unfortunately not all users of your bot will be constructive. Some will just want to play around by using the bot as a sounding board for inappropriate language, profanity and other offensive statements. As sessions do cost money, however small the amount, we want to make sure the user is not wasting our time. An abusive conversation could block a slot that would be put to better use helping someone with a legitimate problem.
The Teneo Dialogue Resource already contains responses that try to discourage specific inappropriate inputs, e.g. a sexual proposition or calling the bot bad names. Some users are just curious and want to test the boundaries of what they can say. Once warned they will return to questions the bot is designed to help with.
Difficult users however may need to be handled differently. Some of our systems took a three strike approach. The user is warned twice at the occurrence of unacceptable language. After the third strike, the user gets a “time out”. The bot refuses to respond to any questions until the user apologizes. If an apology is given, users are given a chance to continue constructively. If they do, everything is fine, and hopefully they will achieve a resolution of their actual issue. If the user reverts to abusive language, the bot ends the conversation immediately.
The logic to make this happen is created within a flow, which is another construct in Teneo. A flow is where we define conversations. Our flow is the type that jumps in after a response was given to attach an additional text to the response that was found for the input.
The first time we enter, we traverse the transition numbered 1. The output there gives the first warning. The next time we’ll follow transition 2 and the third time, we wind up in a position where the user cannot continue until apologizing. If the flow becomes active a 4th time, system scripts cause the conversation to end.
The sensitive themes mentioned at the beginning of the article are usually off-topic for most bots. But they are also topics where we don’t want to the bot to give an inappropriate response. For example, if a bot is trained to respond to a phrase “I’m going to….” with “go ahead, do it”, it would look especially bad if the user said “I’m going to kill myself”. To avoid situations like this, the bot can give a response that acknowledges the sensitivities of the theme, but also make it clear that it’s not equipped to discuss the matter.
The personal assistant built with Teneo, called Lyra, shows the importance of answering appropriately when confronted sensitive subject matter.
We hope this article has convinced you of the importance of the meta-level of your bot’s conversations, knowing not only what your users are saying, but how they say it. Are they upset? Are they irritated with the customer service experience? Are they being consistently abusive? Or are they in a particularly good mood? The tools available in Teneo make it possible for you to know the exact situation throughout the conversation and to take appropriate actions based on that knowledge.
Obviously we did not have room in this article to show all the possibilities open to you with Teneo’s various detection tools. They are designed to be used in many different, creative ways. Each of the use cases here can be tweaked and modified to obtain a result that matches your business needs.
In a continuation of this article we’ll show you how to use the sentiment library to perform post-session analyses to find conversational hotspots and also to improve your system.
Try Before You Buy.
Build. Deploy. Analyze.
Sign up to get your own developer sandbox of Teneo containing all the tools needed to build and manage advanced conversational solutions.