The Atura Process

At Atura we follow a simple yet thorough process to design each bot and ensure it meets requirements and exceeds expectations. Appropriate documentation is generated along the way - keeping it lightweight and visual as much as possible. We try to avoid lengthy specification documents, preferring to rather provide only essential documentation and diagrams for understanding the business need, the proposed solution and the conversational interactions.

The process can be summarised as:

1. Understand the context
2. Determine core intents
3. Generate utterances and map to intents
4. Create the bot persona
5. Design dialogue and conversation flows
6. Build, test, improve

Understand the Context

The first step is to analyse the current state of a client's system – what processes are in place, what processes would an AI assistant handle, where and how would an assistant fit into their existing structure? Working with the client's business analyst (or directly with key business stakeholders on the client side if they do not have a BA), we highlight pain points and describe the key business need an AI assistant will address. It is sometimes the case that a client has already done this groundwork and has a good idea of what sort of bot is desired. If this is so, we move on to going more in depth into the core factors that will influence the bot solution.

The initial concept and solution will have previously been detailed in a project proposal. But whereas the proposal is created with a high level of understanding, the first stages of bot building involve a much more in depth analysis of requirements, need and context. We look to understand the culture of the client's business as well as their clients, so we can design the bot in context to fit the client's brand. We seek to understand who the end users will be - and we create personas for typical users to inform us throughout the design phase. This sets the context for the rest of the process.

Determine Core Intents

Once we have a good understanding of who will be using the AI assistant and why, the next step is to examine the journey a user may follow to achieve their aim. Keeping in mind the key personas, we consider how users would interact with the assistant. What are they trying to achieve through this interaction? The aim of the user is called the intent. For example, when interacting with a financial AI assistant, a user might want to make an addition of funds to an existing investment, or perhaps open a new investment account. So "adding funds" and "open account"' would be their intents.

We determine core intents by analysing a combination of:

• Focus group studies
• Internal workshops with business stakeholders
• Role playing sessions
• Frequently Answered Questions sets

If the client has a call centre or customer service desk, we also study and process the call centre scripts and interaction data logs.

Generate Utterances and Map to Intents

Now that we know what users will want to do, we can generate possible utterances. Utterances are what the user says to the assistant - the free text they type when conversing with the assistant. Utterances consists of key words called entities. As an alternative to NLP, Atura can also create a guided solution that allows a user to achieve their intents purely through mechanisms such as guided conversation, structured query and decision tree logic and visual controls. Components such as the Atura Form Engine are used when building this style of assistant.

Utterance generation is informed by key customer personas - who will be interacting with the bot and how do THEY speak. There are multiple ways different people might phrase the same intent, so it is important to anticipate this and eliminate design bias whenever possible. For example, the intent 'invest' might be expressed as "I want to invest" / "invest my money" / "start investing" OR by someone less familiar with investment banking simply as "I want to save".

We extrapolate out the different permutations of utterances using the appropriate domain language. Utterances are then mapped to intents and are used to train the NLP engine. The more utterances we provide to the NLP engine; the greater accuracy the bot will have when interpreting a user's comments. This process is ongoing - when an AI assistant first goes live it will be trained with a specific set of utterances. Once it has been running for some time, we can interrogate the conversation data to see where and how the assistant's training can be augmented. This means the longer our bots run, the better they get at performing their core purpose and the more tailored they can become to their users.

The ultimate aim is to create a relatable bot that users will want to interact with. But we must remember that the bot interface is via text (not voice just yet) - so we need to take in to account how people speak AS WELL AS type. At a base level this means our bots can handle spelling errors and poor grammar. It also means that in addition to core NLP training, we apply an extra level of "fuzzy text matching" to refine the intent-matching results obtained from the NLP engine. For example, the user types the utterance "Give me the Core Balance fund fact sheet", LUIS recognises the entity "fund" and maps to the intent "fundfactsheetrequest". The intent here is that a user wants a fund fact sheet for a specific fund type. But it is not enough to recognise that they want a fact sheet, we also need to know which fund the user wants to know about. In this instance we further process the utterance, applying the Levenshtein distance to extract the fund type "Core Balance" and then map it to the actual name of fund - "Core Balanced" - to return the correct information.

Create the Bot Persona

Before we can dive in to designing the dialogue and conversation flows, we need to create a personality for the bot. Who is this AI assistant? What is its gender? What is its name? We breathe life in to the assistant by giving it a personality. The assistant persona is used to inform how the it speaks. What tone will it use? Is the Ai assistant friendly and chatty or more formal and informative? This personality is created by the team in close consultation with the client.

While this seems like a small part of the process, it is essential as the AI assistant becomes a spokesperson for the client's brand. By facilitating core business processes, it will become the point of contact for interaction between the end user and the client's company. This is where an AI assistant really comes to the fore to create a rich user experience. It has to make the interaction, and therefore the client's brand, memorable. And in doing so, it fulfils an additional purpose - by being an essential marketing tool. A carefully crafted personality is not just embellishing - it is vital.

Design Dialogue and Conversation Flows

We know what users can be expected to say to the bot, now we decide what the bot says back to them. How do we marry this with the business objectives and requirements? For example, how do we build an AI assistant for our fictional client "BankX" that will be aimed at younger users? It should use language the users will relate to, but must still provide a financial service, which may require more formal diction. Keeping the assistant's persona in mind when designing for dialogue means we can respond appropriately "in character" with the suitable tone and turn of phrase, while still addressing the requirements of each core intent.

The starting point for dialogue and conversation design is the main flows and processes that were previously defined. We map out the major customer journeys and visualise these as logical pathways. By visualising the flows, we can avoid loops and add any validation steps the system may require in an appropriate conversational fashion. For example, when the assistant asks for a user's email address, we validate that it is in fact an email address they entered. If not, we could ask them to enter it again "That doesn't seem right. Would you like to try that again?" but we also need to provide a "Cancel" or "Back" option so they are not stuck here.

Visualising the user's journey also highlights another essential aspect of conversation design - always keep the user moving forward and avoid dead ends. Being faced with the chat version of the proverbial "blinking cursor" is a sure fire way to have the user exit immediately (and in all likelihood not come back).

Building on this outline you will quickly see that only the simplest flows are linear. Linear conversations are often boring. More usually a user will follow a multi-dimensional path touching on several elements of an assistant's functionality. For example, a user transacting on an investment may want to update their bank account details at the same time. This is two different linear flows 1) perform a transaction and 2) update account details. Both can be combined into a single intent, or each can be an intent on its own. Essentially, different users may follow different paths to achieve the same end goal. For example, a user wants to obtain an insurance quote on a vehicle. We need to capture more details in order to generate a quote to insure a car than to insure a caravan, but for both we need to capture the address for overnight storage. The user with the car will go through a different interaction to the caravan owner, but the flows will converge to capture location details and finalise the quote.

An intelligent AI assistant also needs the ability to switch between flows, or respond appropriately when a user decides to change their main intent or do something other than what they started on. Getting stuck in a particular line of conversation is not a good experience and often leads to the user simply exiting. To account for this, language needs to be carefully chosen so that you can arrive at individual pieces of bot dialogue from multiple directions. The conversation logic must be designed so that if the user is directed to a part of another core journey or flow, the language is not jarring. There should be no obvious non-sequiturs or conversation fragments that seem out of place.

Dialogues are based on our CUI (conversational user interface) principles. This gold standard ensures best practice for conversational design. Keep language consistent via constantly referring to the assistant persona.

Once the core journeys and logic skeleton is in place, we refine the language to compliance and regulatory requirements. Finally, we add elements to the conversation ensure it flows naturally. We:

• add an intro and personalised greeting where possible.
• add conversational elements such as 'small talk'.
• create an exit experience where the user is left with a positive feeling so that they will want to return. We can also put any marketing hooks in to the exit experience.
• vary the way questions are asked and confirmation messages are presented.
• give directional cues to the user. If the user does not know what to say, the AI assistant must come up with suggested tasks that he can perform for the user. Sometimes this is simply having a few buttons to click on, sometimes it is by making suggestions via small talk or helper text.
• add linker text to make transitions smoother.

In order to see how the flows work together, and to present to the client for sign off, we mock up the dialogue using Botsociety (https://app.botsociety.io/login#/conversations/new) or ChatDown for Bot Framework (https://www.npmjs.com/package/chatdown). These mock ups can also be used for focus groups, if we need to test specific aspects with real users.

Build, Test, Improve

The bot is now ready to be built.

• Build - build using an agile approach to the development cycle.
• Test - test in UAT, and often with focus groups on early development. Get user input as soon as possible to validate the design decisions. Tweak language, flows and design along the way.
• Improve - the process can be repeated once the assistant is live to tweak the logic and improve the AI assistant's ability to respond appropriately and recognise the core intention of a user's utterance.