Business Chatbots - AIML & ChatScript

Overview

By replacing call-centre staff, the deployment of business chatbots can potentially offer very substantial financial savings for many organisations. However, a chatbot that possesses neither the knowledge nor the language skills of the “wetware” that it replaces can all too easily prove a customer relations disaster, resulting in a loss of market share or in reputational damage.

So, the starting point when it comes to deciding whether a business chatbot is right for your organisation is what level of service you expect it to be able to provide? Could you realistically replace a person with a machine and still offer a level of service that would be acceptable to your clients?

In this article, we’ll examine the issues that you’ll need to consider when it comes to designing and deploying a business chatbot:

Misspellings

Semantic Equivalency

Mirroring

Nominal Gender Assignment

Short-Term Memory

Long-Term Memory and Broken Conversations

User-Friendly Obfuscation

Simulated “Think Time”

Managing Expectations

Time and Tense

Ignoring Unsolicited Information

Inferences based on Indirect Answers

Unexpected Questions – Clarifying Ambiguities

Unexpected Statements – Correcting Misinformation

Advanced Inference

Semantic Flavours, Sentiment and Emotion Analysis

Probabilistic Models and Stereotyping

Selectable and Self-Adjusting Personalities

and the broad set of multi-faceted skills that your chatbot developers will need to deploy.

Software or Wetware?

The easiest way to develop an understanding of what a business chatbot should be able to do is by way of examples. Can you distinguish a business chatbot from a person? Can you distinguish software from “wetware”? In the following sections you’ll find the transcripts of two imagined conversations between a member of the public, Joan, and a representative of a government organisation, Kelly, discussing whether Joan can claim child maintenance for her daughter, Amy.

A Pain in the Butt!

Let’s assume that Joan has navigated to a government web site, and on one of the web pages has found chat entry and response text boxes, accompanied by a message encouraging her to have a conversation with a government representative. So, either by typing in the text directly or by using the speech recognition functionality build into her computer’s operating system, Joan engages in the following conversation:

Joan: Can I claim maintenance for my child?

Kelly: Please answer the following questions. Do you live in the UK?

Joan: Sure

Kelly: I don’t understand your answer. Do you live in the UK?

Joan: I live in Taunton, in Somerset.

Kelly: I don’t understand your answer. Do you live in the UK?

Joan: Yes

Kelly: Does the paying parent live in the UK?

Joan: Who's the paying parent?

Kelly: I don’t understand your answer. Does the paying parent live in the UK?

Joan: Is the paying parent my ex?

Kelly: I don’t understand your answer. Does the paying parent live in the UK?

Joan: Ok let’s say no.

Kelly: I don’t understand your answer. Does the paying parent live in the UK?

Joan: No

Kelly: If the paying-parent works in the UK civil service, the UK armed forces, or for a UK-based company, state which one; otherwise, state “none”.

Joan: He’s in the army.

Kelly: I don’t understand your answer. If the paying-parent works in the UK civil service, the UK armed forces, or for a UK-based company, state which one; otherwise, state “none”.

Joan: Army

Kelly: I don’t understand your answer. If the paying-parent works in the UK civil service, the UK armed forces, or for a UK-based company, state which one; otherwise, state “none”.

Joan: Armd forces

Kelly: I don’t understand your answer. If the paying-parent works in the UK civil service, the UK armed forces, or for a UK-based company, state which one; otherwise, state “none”.

Joan: Armed forces

Kelly: How old is the child?

Joan: Oh I just remembered my ex said he was leaving the army and getting a job with a company in France

Kelly: I don’t understand your answer. How old is the child?

Joan: Don’t you understand what I’m saying. I don’t want to start all over again.

Kelly: I don’t understand your answer. How old is your child?

Joan: She’ll be five in July.

Kelly: I don’t understand your answer. How old is your child?

Joan: Four

Kelly: I don’t understand your answer. How old is your child?

Joan: 4

Kelly: Do you have the main day-to-day care of the child?

Joan: Yes, she spends the occasional weekend with her dad but I look after her most of the time.

Kelly: I don’t understand your answer. Do you have the main day-to-day care of the child?

Joan: Yes

Kelly: Based on the information provided you are eligible for child maintenance.

Joan: Based on the information you didn’t understand you’re a pain in the butt!

Clearly, not the sort of representation that any organisation would care to endorse! Joan still doesn’t know what a “paying parent” is, and the representative has based its answer, incorrectly, on the assumption that Joan’s ex works in the armed forces and not for a company, which, critically, may, or may not, be UK-based.

Very Helpful!

Or perhaps, instead, the conversation went like this:

Joan: Can I claim maintenance for my child?

Kelly: Okay, I need to ask you some questions. Do you live in the UK?

Joan: Sure

Kelly: So, you live in the UK. Does the paying parent live in the UK?

Joan: Who's the paying parent?

Kelly: The paying parent is the person who you expect to make payments of child maintenance to you, say your former partner. Does the paying parent live in the UK?

Joan: No, he doesn’t.

Kelly: Okay, he doesn't live in the UK. Does he work for the UK civil service, the UK armed forces, or for a UK-based company?

Joan: He’s in the army.

Kelly: So, he’s in the UK armed forces. What’s the child’s full name?

Joan: Amy Clare Wilson

Kelly: Okay. How old is she?

Joan: Oh I just remembered my ex said he was leaving the army and getting a job with a company in France.

Kelly: You might not know, but is the company registered in the UK?

Joan: I think so.

Kelly: Right, the paying parent works for a UK-based company. So, coming back to Amy. How old is she?

Joan: She’ll be 5 in July

Kelly: Okay, so she’s four. Do you have the main day-to-day care of Amy?

Joan: Yes, she spends the occasional weekend with her dad but I look after her most of the time.

Kelly: So, so you have the main day-to-day care of Amy.

Here’s a summary of the information you provided:

You live in the UK. The paying parent does not live in the UK. He works for a UK-based company. You have the main day-to-day care of Amy. Based on this information, you are entitled to claim child maintenance. Do you any other questions.

Joan: No, that’s fine. You’ll been very helpful.

If you’ve concluded that the Kelly in the first transcript is a business chatbot and that the Kelly in the second transcript is a person then you’d be wrong! Both are chatbots, written in a scripting language called ChatScript.

The first example is quite typical of the way some poorly designed business chatbots behave; the second is an example of what can be achieved using currently available natural language processing (NLP) techniques. We’ll discuss the technology options later, but first let’s focus on what makes the first business chatbot so “hair-tearingly” bad and the second business chatbot so good – so good that her responses are indistinguishable from those that might be offered by a “wetware” equivalent.

Document Reading versus Guided Questioning?

For the purpose of the chatbot examples above we selected a typical task that a business chatbot might be expected to undertake. The chatbots implement part of a summary of the criteria under which a person can claim statutory child maintenance (taken from the “www.cmoptions.org” web site):

A person can ask for a statutory child maintenance arrangement as long as:

   The person asking to receive child maintenance has the
   main day-to-day care of the child and lives in the UK, and

   The parent expected to pay child maintenance lives in the UK, or
   works in the civil service, the armed forces or for a
   UK-based company, and

   No court order is in place from before 2003, or there is a court
   order from after April 2003 but it was set up more than
   12 months before the application, and

   The child named in the application is:

      Under the age of 16, or

      Between 16 and their 20th birthday and undertaking
      full-time, non-advanced education, or

      Between 16 and their 20th birthday, registered with
      certain types of government-approved training courses, and
      child benefit is in payment.

The summary consists of a series of conditions and sub-conditions, typical of those that are encountered in almost any business. And it is only a summary. A definitive set of conditions – conditions that a human representative, and any useful chatbot, would need to be aware of – would be much more extensive; for example:

How many days a week constitute “main day-to-day care”?

How many weeks a year does one have to spend in the UK to be considering “living in the UK”?

What if someone lives in the UK but works for the diplomatic services of a foreign government – are they “living” in the UK?

What is “non-advanced education”?

Which “government training courses” are approved?

From a business perspective: is it better to provide someone with a definitive document to read, one that contains the information needed to answer a question; or is it better to ask a person about his or her personal circumstances using a set of guided questions, and on the basis of the information provided give an answer?

If we did expand on the summary to provide a definitive, legally-tight document, then we would have a problem: perhaps some 50% of the population would take one look at it and give up; about 40% might try to read it but would either come to the wrong conclusion, or be uncertain that they had come to the right conclusion; and 10% of the population might come to a conclusion, might be reasonably confident that they had got it right, but would be cursing under their breath as to the amount of time it had taken them to come up with the answer. So, for almost all purposes the “definitive document” route is not the way to go!

The core problem with such a document is that about 95% of the contents would be irrelevant to any one person who read it. Hence, by far the most efficient way to obtain an answer to questions such as “Can I claim statutory child maintenance” is to start from the specific circumstances of the person asking the question, and to request from that person only the minimum additional information needed to determine the answer, customizing the questions asked based on the responses already received to previous questions. Up until now, doing so has been the province of the human interlocutor – but not any more!

What a Chatbot should and should not do?

In order to be as effective as a human interlocutor, a business chatbot needs to exemplify two characteristics; it needs to be:

Efficient

Personable

The chatbot needs to obtain the information needed to answer the client’s question as quickly as possible. To do so, it needs not only knowledge specific to the question being asked, such as an understanding of the rules surrounding child maintenance, but it needs a more general knowledge of the human world, at least to the extent that such knowledge is relevant to the questions being asking.

A chatbot must also be personable, and have the basic conversation skills that a human possesses, such as the ability to mirror the sentence constructions used by the client. Without this ability, the chatbot will seem remote, uncaring, and, well, just robotic, and will be unable to establish a good relationship with the client. Just as with its human counterpart, establishing a good relationship is key to selling a product or to receiving a high rating for the quality of the service provided.

Let’s examine what specific behavioural characteristics make a chatbot both efficient and personable.

Misspellings

Consider the following extract from the first conversation where the chatbot is expecting the response to be “armed forces”:

Kelly: I don’t understand your answer. If the paying-parent works in the UK civil service, the UK armed forces, or for a UK-based company, state which one; otherwise, state “none”.

Joan: Armd forces

Kelly: I don’t understand your answer. If the paying-parent works in the UK civil service, the UK armed forces, or for a UK-based company, state which one; otherwise, state “none”.

Joan: Armed forces

The text input to a chatbot will contain frequent misspellings. A chatbot, like a human, must recognize and correct misspelling as and when they occur – it should not expect the client to renter misspelled text with the spelling errors corrected.

Semantic Equivalency

Consider the following extract from the second conversation where the chatbot is expecting the response to be a semantic “yes” or “no”:

Kelly: Okay, I need to ask you some questions. Do you live in the UK?

Joan: Sure

Kelly: So, you live in the UK. Does the paying parent live in the UK?

A chatbot must understand, as a human does, that different words and phrases can be semantically equivalent.

The first chatbot is expecting a response that is a syntactic “yes” or “no”; in the context of the question, it only understands these two words and nothing else. The second chatbot recognizes that the word “Sure” and the phrase “I think so” are semantically equivalent to the word “yes”.

Another issue is that of semantic equivalency in context. For example, when the second chatbot is expecting an answer of “UK armed forces” and receives, instead, the response of “He’s in the army”:

Kelly: Okay, he doesn't live in the UK. Does he work for the UK civil service, the UK armed forces, or for a UK-based company?

Joan: He’s in the army.

Kelly: So, he’s in the UK armed forces. What’s the child’s full name?

it interprets “army” as “armed forces” (as it would if Joan had said “navy” or “air force”). Now army is not semantically equivalent to armed forces in general, but is a subset that excludes the “navy” and the “air force” and various other combat units. However, in the context of the question, belonging to a subset of set “X” implies belonging to set “X” and a chatbot is expected to be able make the inference and establish semantic equivalency in the context.

Note, the chatbot, like a human, in this context does not ask specifically if the army in question is the UK army. The prefix UK appears both in the question and in the subsequent confirmation that precedes the next question, giving the client ample opportunity to recognize if a mistake has been made and to correct it. However, in other circumstances – where the qualifying term was not one readily understood by the client base – the chatbot, like its human counterpart, might ask for an explicit confirmation, and might provide a definition or example to ensure that there was no misunderstanding.

As these examples illustrate, it is a characteristic of human conversation that an answer does not always mirror the exact words of the question, but is often phrased in quite a different way. It is up to the interlocutor, human or machine, to recognise semantic equivalency in context whenever it occurs.

Mirroring

One of the key aspects of human conversation is that the participants adjust the wording of subsequent questions and answers so as to the mirror the wording of earlier ones; for example:

Joan: Who's the paying parent?

Kelly: The paying parent is the person who you expect to make payments of child maintenance to you, say your former partner. Does the paying parent live in the UK?

Joan: No, he doesn’t.

Kelly: Okay, he doesn't live in the UK. Does he work for the UK civil service, the UK armed forces, or for a UK-based company?

Note that when Joan refers to the “paying parent” in the first question, Kelly uses the words “paying parent” in the reply. Joan now changes the terms of reference, replacing “paying parent” with the pronoun “he”. Kelly recognizes the change and phrases the following question using “he” and not “paying parent”. We are not normally aware of these shifts in reference, as they are made unconsciously, but they serve as an implicit acknowledgement of what each participant in the conversation is saying, and are fundamental to establishing a good relationship; they are a form of conversational etiquette, one originated by man, one to be emulated by machine.

Nominal Gender Assignment

Human conversationalists know the genders that are associated with first names, and a chatbot must possess a similar level of knowledge:

Kelly: So, he’s in the UK armed forces. What’s the child’s full name?

Joan: Amy Clare Wilson

Kelly: Okay. How old is she?

Here, the second chatbot understands that an “Amy” is a “she” and not a “he”. Think of how formal and stilted the conversation would be if the response were:

Kelly: Okay. How old is the child?

and the chatbot were never to refer to the “child” as “she” or as “Amy”. If the answer had been:

Joan: John Paul Wilson

the response would have been:

Kelly: Okay. How old is he?

If the name had been unisex:

Joan: Chandler Wilson

or one that the chatbot was not familiar with:

Joan: Aalap Singh

the response would have been:

Kelly: Okay. A boy or a girl?

Using the correct personal pronoun when talking about a third-party is essential if the conversation is to seem natural – a business chatbot needs to come with a dictionary of “baby” names, classified into the standard “pink”, “blue”, and unisex categories.

Short-Term Memory

A human conversationalist will remember the salient points in a conversation, and will be able to repeat and draw upon information provided earlier in the conversation:

Joan: Amy Clare Wilson

Kelly: Okay. How old is she?

Joan: Oh I just remembered my ex said he was leaving the army and getting a job with a company in France.

Kelly: You might not know, but is the company registered in the UK?

Joan: I think so.

Kelly: Right, the paying parent works for a UK-based company. So, coming back to Amy. How old is she?

Here, Joan gives the name of her daughter as Amy, a discussion of another topic follows, one that has no reference to Amy, and then Kelly refers to Amy in the question that follows. A well designed chatbot will remember not just information relevant to answering the question that is being asked, but also any incidental information that is offered up along the way. Repeating this information where relevant, particularly remembering someone’s name, make the conversation seem natural and accords with good conversational etiquette.

Long-Term Memory and Broken Conversations

A chatbot also requires a long-term memory. Consider the following conversation:

Kelly: Okay. How old is she?

Joan: Oh I’ve just heard the doorbell ring. I’ll have to get it.

Kelly: Do you want me to wait, or would you prefer to call back later?

Joan: I’ll call back later

Several days later Joan calls back again and after authentication the conversation goes as follows:

Joan: Hi, I was to talking to someone a few days ago about child maintenance, and we got cut off.

Paul: Okay, I’ll do a search.

Paul: You were speaking to Kelly. I think she’s available. Do you want me to transfer you?

Joan: Yes please.

Kelly: Hello, this is Kelly. Can I help you?

Joan: Hello, my name is Joan Wilson. I was talking to you about child maintenance a few days ago and we got cut off.

Kelly: Yes, I seem to remember. Hold on a moment while I bring up my notes.

Kelly: Okay, you were asking whether you could claim child maintenance for Amy. Let’s see where we got to. Yes, I need some more information. Can you tell me how old she is?

Conversations are often interrupted, and a chatbot must be able to persistently store conversation logs and the semantic assertions parsed from conversations, to recall them when required, and to then continue the conversation where it had left off.

This is one area where a chatbot can readily outshine “wetware”. One of the most annoying aspects that a client finds when dealing with most organisations is the lack of continuity – he rarely speaks to the same person on different occasions, and even if he does, that person will have long since forgotten the previous conversation. The notes that might be available from that previous conversation may be too terse or inscrutable to provide any useful information, and so the information gathering exercise will have to begin from scratch all over again.

User-Friendly Obfuscation

Just because a chatbot can remember everything does not mean that it should let on to the client that it can do so; consider:

Joan: Hi, I was to talking to someone a few days ago about child maintenance, and we got cut off.

Kelly: This is Kelly. At 3:27 on Tuesday 24th our conversation was interrupted when you said, “Oh I’ve just heard the doorbell ring. I’ll have to get it.” I had just asked, “How old is Amy?” Please answer the question.

This level of recall conjures up “Big Brother” and will make most clients feel rather uncomfortable. A chatbot needs to give the impression of remembering just enough about the previous conversation so as to seem interested in the client, and give the impression of forgetting just enough about the previous conversation so as not to seem overbearing:

Kelly: Yes, I seem to remember. Hold on a moment while I bring up my notes.

Kelly: Okay, you were asking whether you could claim child maintenance for Amy. Let’s see where we got to. Yes, I need some more information. Can you tell me how old she is?

The “Yes, I seem to remember.” seems to be a more human response. Note that when Joan authenticated herself, she was not immediately transferred to Kelly, despite the fact that the chatbot engine had all the necessary information to reuse the same bot name as before:

While this obfuscation leads to a reduction in efficiency, it increases the degree of personalisation and avoids the “Big Brother” syndrome. And, perhaps, Joan may wish to speak to Paul on this occasion rather than Kelly – different chatbots can have different personalities!

Simulated “Think Time”

Another aspect of the conversation in the section on “Long-term Memory” is the deliberate delays that are introduced into the conversation, as in:

Paul: Okay, I’ll do a search.

Paul: You were speaking to Kelly. She’s available. Do you want me to transfer you?

and:

Kelly: Yes, I seem to remember. Hold on a moment while I bring up my notes.

Kelly: Okay, you were asking whether you could claim child maintenance for Amy. I need some more information. Can you tell me how old she is?

These delays are unnecessary, but help to avoid the “Big Brother” syndrome.

More generally, when planning a chatbot implementation you need to consider how long to wait between receiving a response and sending a reply. From a computational perspective, a chatbot will usually be able to have a response ready for dispatch within milliseconds. So, with a fast Internet connection the response might appear on the client’s screen within half a second after dispatching a question.

It’s important to appreciate the possible negative psychological implications of such a rapid response. When a person consistently replies very quickly to questions in a conversation it can suggest that he regards the questions as unimportant, that he is bored with the questioner, and that he wants to end the conversation as quickly as possible. So, the well designed chatbot will introduce an appropriate delay before sending a response, so as to create the illusion that the previous response has been carefully considered.

It is also useful if the delay is proportionate to the length of the text that is being sent to the client. When the text contains several clauses or sentences, it is better to send them one at a time, approximating the illusion of someone who is typing and considering what to say next.

The trade-off between hassling some clients by responding too quickly and frustrating others by responding too slowly needs to be considered. The dilemma can be resolved either by allowing clients to specify the type of chatbot personality they wish to engage with when initially contacting the organisation, or by designing a chatbot that uses sentiment analysis to gauge how quickly it should respond as the conversation progresses.

Managing Expectations

One characteristic of a good conversationalist when acting in a role where information needs to be obtained from an individual is to downplay expectations when a question is difficult and may be one that the client is not able to answer. For example, it would be very odd if Joan did not know the full name of the child:

Kelly: So, he’s in the UK armed forces. What’s the child’s full name?

Joan: Amy Clare Wilson

but it is quite likely that Joan does not know whether the company her ex is now working for is a company registered in the UK at Companies House:

Joan: Oh I just remembered my ex said he was leaving the army and getting a job with a company in France.

Kelly: You might not know, but is the company registered in the UK?

Joan: I think so.

Here, Kelly lowers expectations, by prefixing the question with the phrase “You might not know”, and thereby makes the respondent more comfortable if she can’t answer the question. It is this attention to detail in coding a chatbot that makes it seem personable and makes the respondent feel at ease.

Time and Tense

Consider the following extract in which Kelly asks for the child’s age:

Kelly: Right, the paying parent works for a UK-based company. So, coming back to Amy. How old is she?

Joan: She’ll be 5 in July

Kelly: Okay, so she’s four. Do you have the main day-to-day care of Amy?

Simple chatbots just scan the response for relevant keywords. In this case, a simple chatbot would simply search the text for a number and assume, incorrectly, that Amy was five years old, and not four.

A chatbot, like a human, must understand the semantics of the response as a whole, and make any computations or inferences that may be needed to derive the correct answer. The chatbot needs to understand the difference between “She’ll be 5 in July” and “She was 5 in July”.

Ignoring Unsolicited Information

Consider the following response where the chatbot is expecting the answer to be a semantic “yes” or “no”:

Kelly: Do you have the main day-to-day care of the child?

Joan: Yes, she spends the occasional weekend with her dad but I look after her most of the time.

Chatbots, like people, must understand that clients will often volunteer unsolicited information that is not strictly relevant to answering the question, but which provides some background information. Clients frequently provide this extra information when they are not confident of what the question actually means, and are worried that a straightforward “yes” or “no” answer might be incorrect. They are effectively saying to the questioner: “These are my circumstances, you decide on which answer is correct”. In this example, an answer of “yes” is sufficient. The chatbot must ignore the additional information when it comes to understanding the answer contained within the text.

However, in addition, a chatbot should extract the information contained in the unsolicited text: this information may help to answer another question, and prevent the chatbot from asking for information that was supplied as part of the answer to a previous question. If the chatbot were to subsequently ask:

Kelly: Does Amy have any contact with her father?

then it would look rather silly!

Inferences based on Indirect Answers

Consider the following extract, in which the chatbot is expecting the response to be either “yes” or “no”:

Kelly: I don’t understand your answer. Do you live in the UK?

Joan: I live in Taunton, in Somerset.

Because clients often respond to questions by providing more information than the bare minimum needed to answer the question, the answer to the question may not be directly contained in the response, but may need to be inferred from the response.

A chatbot must possess, as a human does, basic knowledge about the world to the extent that it is relevant to the task at hand and must be able to make inferences based on this information. In the present case, the chatbot needs to know that the UK consists of countries, one of which is England, and that England consists of counties, one of which is Somerset. And based on this information it must be able to infer that if the speaker lives in Somerset then the speaker also lives in any geographical entity that is a superset. The underlying logic needs to be “I’m enquiring about a geographic entity, UK. Somerset is a geographic entity. Does Somerset belong to this geographic entity; if so, the answer is ‘yes’; otherwise the answer is ‘no’”.

Unexpected Questions – Clarifying Ambiguities

Consider the following extract where the chatbot is expecting the response to be “yes” or “no”:

Kelly: Does the paying parent live in the UK?

Joan: Who's the paying parent?

Kelly: I don’t understand your answer. Does the paying parent live in the UK?

Joan: Is the paying parent my ex?

Kelly: I don’t understand your answer. Does the paying parent live in the UK?

Joan: Ok let’s say no.

Kelly: I don’t understand your answer. Does the paying parent live in the UK?

Joan: No

A chatbot, like a human, must be able to cope with the frequent occurrence in conversation of a response to a question that is not a statement offering an answer, but another question, one that usually seeks to clarify what the question just asked actually means. In this case, the chatbot has, rather unadvisedly, been programmed to use jargon, which, while being well understood within the government organisation, may be confusing to those members of the public who rely upon its services.

The chatbot must be able to answer an unexpected question and then return to the previous question that it asked, as in the following:

Kelly: So, you live in the UK. Does the paying parent live in the UK?

Joan: Who's the paying parent?

Kelly: The paying parent is the person who you expect to make payments of child maintenance to you, say your former partner. Does the paying parent live in the UK?

Joan: No, he doesn’t.

In gathering the information needed to answer one expected question, yet another unexpected question may be raised, and so forth; a chabot needs to keep a stack that records the hierarchy of where in the normal process flow these interruptions have occurred, so that it can gracefully unwind the discussion and answer the master question that is driving the conversation.

Unexpected Statements – Correcting Misinformation

Consider the following extract where the chatbot is expecting the response to be the age of the child, but where Joan suddenly realises that she has made an error in answering a previous question:

Kelly: How old is the child?

Joan: Oh I just remembered my ex said he was leaving the army and getting a job with a company in France

Kelly: I don’t understand your answer. How old is the child?

Joan: Don’t you understand what I’m saying. I don’t want to start all over again.

People often misspeak or misremember and then correct what they have said either immediately or at some later stage during a conversation. A chatbot, like a person, must recognize when a statement is not an answer to the question just asked, but a revised answer to a question previously asked.

In the second conversation, the chatbot remembers the point at which the conversation took a detour, returns to it, and reminds the speaker of the previous question:

Kelly: Okay. How old is she?

Joan: Oh I just remembered my ex said he was leaving the army and getting a job with a company in France.

Kelly: You might not know, but is the company registered in the UK?

Joan: I think so.

Kelly: Right, the paying parent works for a UK-based company. So, coming back to Amy. How old is she?

A chatbot, like a person, must memorize the key assertions made in a conversation, and interpret a statement not just in the context of the question just asked, but in the context of the conversation as a whole.

As with expected questions, unexpected statements, either alone or combined with unexpected questions, may also occur in a hierarchy that needs to be carefully tracked and managed. For example, in dealing with the unexpected statement in the example above, a further unexpected question might be raised:

Kelly: You might not know, but is the company registered in the UK?

Joan: I think so. How would I find out?

Advanced Inference

Consider the following extract in which Joan corrects her misstatement regarding her ex’s job:

Getting this level of inference correct is very challenging for a chatbot. Firstly, the chatbot needs to determine that there is no reference to age in the response and so the response is not a response to the previous question. Secondly, the chatbot needs to determine that this is a statement and not a question. Thirdly, the chatbot needs to analyse its memory of the conversation to determine if the statement refers to any of the questions previously asked, and if so whether the statement contains new relevant information that would alter the answer to a previous question. In this case, the chatbot needs to record that “ex” was previously used as a synonym for “paying parent”, that “army” was used as a synonym for “armed forces”, which points towards the question:

Kelly: Okay, he doesn't live in the UK. Does he work for the UK civil service, the UK armed forces, or for a UK-based company?

where the pronoun “he” stands in for paying-parent in this context. The chatbot then needs to figure out that “leaving the army” means “not being in the armed forces”, and that “getting a job with a company in France” means “working for a company”. It then needs to understand that it has narrowed the range of answers to the question, but still needs to ask another question to pin down the answer:

Kelly: You might not know, but is the company registered in the UK?

This level of understanding will not be possible unless the chatbot can extract assertions from responses and store them in a canonical form, and has an inference engine that can manipulate the collections of assertions and then draw conclusions.

Semantic Flavours, Sentiment and Emotion Analysis

While different words and phrases may have the same meaning they often convey slightly different “verbal flavours”: suggesting different emotional states (sentiment analysis), levels of certainty, degrees of formally, levels of education, and client attitudes. For example, in the exchange:

Kelly: Okay, I need to ask you some questions. Do you live in the UK?

Joan: Sure

Joan seemed more “laid back” than if the response had been a “yes”. In the response:

Joan: Oh I just remembered my ex said he was leaving the army and getting a job with a company in France.

the “Oh I just remembered” suggests mild agitation. In the exchange:

Kelly: You might not know, but is the company registered in the UK?

Joan: I think so.

the “I think so” suggests a lack of certainty – the chatbot might wish to flag every assertion made by a client based on the level of perceived confidence, and perhaps return to those issues where there is uncertainty later in the conversation or during the summary.

A chatbot needs to parse semantic flavours, as they provide a good indicator of how well the conversation is progressing, and whether the chatbot needs to adjust its verbal tone, to ask more concise questions if the client is getting bored, or to explain the topic at greater length if the client is having difficulty in replying to the questions.

When clients are typing responses to a chatbot, the responses tend to be very short and extracting semantic flavours can be very difficult. However, with the growing move towards voice recognition for chatbot input, clients will revert to their normal conversational styles. The use of speech will also make sentiment analysis much easier as the vocal tone can be analysed in addition to the words being spoken. While still largely the preserve of research labs, voice recognition can use speech emotion analysis software (such as PRAAT) to mark-up the generated text with emotional state information.

Probabilistic Models and Stereotyping

Stereotyping lies at the heart of all human interactions. While on occasion people fail to adjust their views when subsequent evidence belies a stereotype, stereotyping has evolved to provide good guidance when dealing with a new situation that bears a similarity to one encountered in the past: that tiger you see prowling through your garden might be someone’s harmless pet, but it might also be a man-eater that has just escaped from the local safari park; you, rather wisely, don’t give the tiger the benefit of the doubt!

The same principle holds true for a well designed chatbot: based on the purpose served by the chatbot, based on a client’s question, and on the initial responses, the chatbot will make an assessment of what sort of person it is dealing with, and will adjust what it says and how it says it accordingly.

This approach to chatbot design implies a probabilistic model. The assertions made by a client are not assumed to be facts, but are simply assigned probabilities, probabilities that may be adjusted as the conversation progresses. Rather than being deterministic, the inference engine is probabilistic (based, perhaps, on Bayesian statistics): different assertions are given different weights and are combined together based on these weightings.

A good example of where stereotyping and probabilistic models become important occurs when sentiment analysis is dealing with sarcasm and cynicism. Now, a poorly constructed chatbot would see in Joan’s response:

Kelly: Do you have a good relationship with your ex?

Joan: I couldn’t say that I get on very well with him.

the words, “I get on very well with him”, and draw the wrong conclusion, but this failure is simply down to inadequate semantic analysis. However, in the following exchange:

Kelly: Do you have a good relationship with your ex?

Joan: Oh, he’s such a wonderful, noble human being! What’s not to like!

a thorough semantic analysis would conclude that Joan admires her ex – we “wetware”, however, know that this is very unlikely to be the case! A well designed chatbot would rate this response as fulsome praise for the person concerned, but would then conclude that this level of praise, and in particular the use of the word “noble”, is unlikely to occur during a normal conversation other than by way of sarcasm. In particular, the chatbot would start the conversation with a stereotype that attached different sarcasm weightings based on the subject under discussion – the sarcasm weighting for Joan’s ex would be substantially higher than for Joan’s child!

With emotional mark-up to hand, it will becomes much easier for a chatbot to determine whether a phrase such as, “wonderful, noble human being” is stated in a standard vocal tone, or whether the mark-up indicates that the speech rate has slowed down, with the characteristic uniform precise enunciation that indicates sarcasm.

Selectable and Self-Adjusting Personalities

It’s worth bearing in mind that “personality” is an option that a client may wish to select when initiating a conversation with a chatbot. Just as at present a user of speech synthesis software can choose from among a collection of voices the one that he finds most agreeable, so too clients will expect a similar choice to be available when selecting the appearance and the personality of the chatbot avatar used to represent an organisation.

As an alternative, a chatbot may be designed to alter its personality and word register based on its interactions with its clients. Clients are more likely to buy a product or follow advice given by a person they approve of than one they do not. The crafting of avatars and their personalities can be expected to become a major factor in the marketing of products and services during the next decade.

While in the medium-term clients will converse with an organisation’s chatbot, in the longer-term, a personal chatbot resident on the client’s own computer / mobile device will converse with the chatbot provided by an organisation. This change will make the organisation’s task much easier. Communication can now be rapid, terse, and performed in a semantic-based pseudo-language, or the organisation may simply forward to the client’s chatbot a voluminous, legal-style document which describes precisely “When Joan can claim child maintenance”. The chatbot will then digest the contents within a few seconds, give Joan the answer to her question, and then, if required, talk her through the reasoning behind the answer. However, while this agent-to-agent conversation will become the norm in the longer-term, there is always likely to be a legacy requirement for organisations – and not just personal computer vendors – to provide the type of natural language chatbot that we’ve described above.

Chatbot Developer Skillsets

If you’ve read through all the sections above, it will have become readily apparent that chatbot development is a complicated task, requiring multi-faceted skills. In the following sections we’ll have a look at these skills in more detail.

Programming Skills

Writing a useful chatbot requires all the programming skills found in conventional procedural languages, such as Java, JavaScript, or C++. However, trying to write a credible business chatbot using one of these languages from the ground up would be well beyond the capabilities, the development timescales, and the budgets of most organisations.

AIML and ChatScript

So, a programming language specifically designed for writing chatbots will almost certainly be required. On the lowest rung of the ladder – in the “light-weight” division – is AIML, a very basic pattern-matching framework that has been widely used for writing conversational chatbots. However, AIML is far too simple to be usefully used to write a business chatbot: it has very poor pattern matching capabilities; it requires a vast number of patterns to be created (many of which are semantically equivalent – it requires 10-20 times more patterns than would be required by a more sophisticated scripting language, such as ChatScript); and it’s redirection functionality makes the code very difficult to maintain – it is not possible to effectively encapsulate topics, so that different developers cannot easily develop and maintain code independently of one another.

AIML has generally been used to construct chatbots competing for the Loebner prize, which compares chatbots based on how human-like their conversations appear to be. These chatbots principally require two skills: a query skill to answer a wide range of knowledge questions, “What is the tallest building in the world”, and a quibble skill to change the subject of conversation when they don’t understand the question that is being asked. To consider how ill-suited chatbots in this category are for business purposes consider the simple level of inference required to answer a question along the lines of:

John is taller than Jill, who, in turn, is taller than Andy. Who is intermediate in height?

Most Loebner prize finalists quibble when faced with a simple question like this. A business chatbot on the other hand, must typically guide a client through a complex maze of questions to get to an answer; it cannot afford to quibble – if it doesn’t understand a client’s response it must pass the conversation over to the supporting “wetware” that can.

Alternatives to AIML – in the “heavy-weight” division – are specialist chatbot scripting languages, such as ChatScript. This type of language is much more difficult to learn than a conventional procedural language. Moving from say Java to C++ is not too difficult for a programmer as the concepts are essentially identical, and the coding conventions are sufficiently similar so that the programmer can often guess at what they mean, with only a modest level of instruction in the new language being required. However, with a language like ChatScript, there are many additional concepts that are specific to chatbot design, and the programming constructs are terse and far from obvious; for example, an expression, such as:

( @_0+ *~3 _^word ^eval( _0 = _1 ) )

would have most programmers scratching their heads!

AIML skills are not easy to come by, and ChatScript skills are as rare as “hen’s teeth”, so an organisation wanting to write a business chatbot may well have to cross-train its existing developers in the selected chatbot scripting language.

Natural Language Skills

Writing a business chatbot requires both programming skills and natural language skills. And, as any manager knows only too well, it’s uncommon to find both in the same individual. The chatbot author has to have a grasp of the language being used by the chatbot that is well above that of the average native speaker in order to be able to anticipate the variety of constructs that will occur during a conversation, and to determine how best to perform the semantic parses needed to gain an understanding of the content – writing a chatbot is certainly not a task for developers for whom the chatbot language is a second language.

Grammar Skills

And finally, there is grammar. Several generations ago grammar was routinely taught at the high school level, but this practice has now fallen out of favour. So, developers who can distinguish a “gerund” from a “present participle” are few and far between. Unfortunately, extracting the semantics from text frequently involves a syntactic parse of the text, and a sophisticated chatbot scripting language will often employ part-of-speech (POS) tagging as an aid to pattern matching. So, an understanding of grammatical constructs is yet another skill that a would-be chatbot author has to master before being able to fully exploit the functionality contained within a sophisticated scripting language.

Summary

So, acquiring the skills needed to write a business chatbot can be challenging. There is likely to be a very long learning curve. However, set against the initial development effort might be the considerable cost involved in staffing a call-centre with hundreds of individuals, individuals who are tasked with repeatedly answering a relatively narrow set of questions originating from a large customer base. If a business chatbot can handle 90% of the workload, with the 10% of difficult, out-of-band issues being handled by “wetware”, then the annual savings might well merit a substantial development effort.

At this point in time, the technology to write effective business chatbots is available, and the financial incentive to create them certainly exists. All that is lacking is the expertise. Now is the time for large organisations to consider developing a prototype chatbot, so that, when the time is right, the technology can be deployed quickly, and the competitive advantage offered by business chatbots can be realised rapidly.

Everything Open-Source

Home

Everything Open-Source