In the previous article on the same topic, I shared a few lessons learned while developing a simple chatbot for client on-boarding and came to the conclusion that technology was not the main challenge, but finding the right dialogue and make it appealing and as natural as possible. Now the question is what is natural while talking or chatting to a banking virtual assistant. Let us discuss how to approach the design of such a dialogue.

Designing the dialogue

Pretty much like discovering user journeys while designing a digital experience based on standard user interface, we need to discover the potential interactions between the customer and the assistant. The challenge is that it is rather difficult to model a interaction between a user using only a start point and an end point, a natural dialogue does not follow just a given route or conversation flow. It might go in multiple directions and must be flexible.  It must be able to jump from topics to topics keeping the context available. The more flexible the chatbot will be the more likely it is that users will start engaging with it.

While a customer might know what kind of product he is looking for in a banking digital assistant, e.g. an investment fund or a mortgage, others might want to save money or buy a house. These would be totally different entry points so the assistant must be intelligent enough to understand the user intent and drive the customer through a different journey. But before that you need to define what the objective of the assistant will be and define KPIs to measure the success of the bot.

The process

Let us take a concrete example to illustrate the step by step approach to designing a baking digital assistant. This is just an illustrative example not based on a real life case. Let us say we want to develop a chatbot to attract customers and non customers to open an account with our digital only bank. Our bank provides investment products, mortgages and also saving accounts for example.

Defining the objective of the bot and the KPIs

The objective of the bot is to have the bank’s prospect registered with us in order to start the product on-boarding process at the end of the dialogue. For existing clients, the objective is to get the client subscribe to a new product directly with the bot. The KPIs for the bot could be the conversation rate for both the prospective clients as well as for existing clients. Keeping track of conversations to understand why the user did go to the end for example will help refining the dialogue until reaching the desired conversion ratio for example.

Defining story lines and understanding customer’s objectives

Since we have different target customers and quite a large set of objectives, we will need multiple story lines to cover multiple dialogue flows, based on what the chatbot user wants:

  1. some information on the bank’s products
  2. save money at the highest interest rate possible
  3. understand how he can invest some money
  4. buy a house
  5. open an account
  6. an account for his kids

The possibilities are quite large and if we want our bot to be attractive, we need to cover as many conversation flows a possible. If a user does not find the requested answers, there is a big probability he will not try again.

Conversation maps

Conversation maps will show the full flow of each possible conversation and the points where conversation might merge or cross. For example let us look at the story 1 and 4 from above, both dialogues will merge if the user is interested by a mortgage, then the remaining of the dialogue will be the same for the 2 dialogues and merge into one branch. So for each story line, the flow of the conversation can be designed graphically. That will give a very detailed view of the desired dialogue and show the intersections between various flows, pretty much like a traffic map. There are tools around that can be used for this. They are similar to tools used to design games story lines.

For our example we will have as many maps as story lines mentioned above and each will show the full path from beginning of the dialogue to the end objective.

Detailed scripting: finite state machine at the rescue

Once you have your conversation maps, for each flow, we will define each interaction and possible question and answer with possible branches. This can start to be complicated. One way of designing the process is to use finite state machines ( a well known concept in software engineering), so for example we could have following states reacting to various inputs and displaying an output every time an event is triggered. In the below table we have mixed 2 different objectives, i.e. the customer does not know what he is looking for, so we try to guess and one customer is looking for a mortgage, both flows will merge in state S3.  The stat 99 is the end state and can also be used as a catch all state.

Input Next State Output
S1 Hello S2 Hello, nice to see you, how can I help today ?
S1 Bye S99 Hope to see you again soon
S2 I do not know S4 What kind of objective do you have ? ( Saving, buy a house, invest )
S2 I would like to buy a house S3 Sure, where do you live?
S3 Switzerland S5 How much can you pay down ?
S4 Saving S3 Where do you live ?
Understanding the intents and identifying slots

Once the dialogue design is complete, the chatbot must be able to understand the user intent automatically and identify the variables ( called slots). This is where Natural Language Understanding and Processing comes into play. There are a number of tools and open source libraries that can help, for example Amazon Lex or Microsoft Luis that can be used to implement the dialogue itself and can be trained to understand the specific domain the chatbot is used for. Some tools also allow to train them online and adding additional sentences that the assistant has not been able to train. Choosing one or the other tool depends on various criteria and we won’t go into much details in this article


(Visited 52 times, 1 visits today)
%d bloggers like this: