Westpac – 2018
Our team was researching into conversational AI this year and observed that they were being used to great effect internally in other companies like Accenture. These would have small scopes and allow us to experiment compared to creating chatbots for banking customers, a much more sensitive area.
Internal workplace chatbots can save time by answering quick and simple questions that usually members of a team might have to answer repeatedly. They can act as a representative of a team. In a massive corporate environment, where people need to work with many teams do get the job done and there are a lot of existing processes to be on boarded with, a virtual assistant on top of these can help save time for everyone. Another problem with such a workplace like ours is that we have an extensive amount of platforms for employees, eLearning, people express, IT desk and more, and navigating these through the intranet is very difficult. Bots can allow a natural way of searching for something through intents, and also act as a layer of interaction on top of these platforms. Why go into a employee system to make a request if you can just ask your assistant to do it for you? I think there are many exciting ways that we can take advantage of these conversational engines and that we should start experimenting.
After implementing our first use case, I developed a framework for building further chatbots. This includes:
- Defining the process and problem
- Mapping a conversation
- How to implement this conversation using Google Dialogflow
- Best practices for chat
- Ongoing service
- Ecosystem of connected bots
This is key to assessing later on if the chatbot has helped the process Assess whether adding this to the knowledge of the bot ecosystem is worthwhile by looking at:
- Is a chatbot a natural fit? Are people usually answering questions to a team about a certain process? Can the bot fit around the existing process?
- Must the underlying process stay complex, is there another way to solve this problem
- The size of the user-base, amount of time saved is it worth the effort
- Does this deal with any sensitive information, maybe customer details?
Conversation mapping can usually be done as a co-creation exercise with the relevant stakeholders to establish everything relevant to the context of the problem. Questions people would ask, the timeline of the business process and who are the stakeholders involved. There may be a logic decision tree to determine a result for the user and a set of other questions that are related. In this session start by collecting everything, and then prioritise parts of the conversation that will make the biggest impact to the problem statement. That becomes the MVP. You can start with a mindmap to cover everything, and then add a workflow to show possible longer conversations. Start with just topics and general areas of questions, then later on you can map the journey in more detail and add actual user input and response language.
Using google dialogflow to create these bots
I wrote a guide for google dialogflow on medium, to cover the different concepts and how to put them together to create chatbots
For the usability of the bot, it is always good to include a few standard responses.
- Introduction or Welcome – which answers to hello or any other greeting, it should give an overview of what the bot does and maybe some example questions. This can also be triggered on an event, like when you open a chat.
- Default fallback intent or Don’t understand – this intent is matched when no other intent is, and should give the user some guidance as to what to ask next.
- Talk to a human – Some users may get frustrated with the bots answers and may ask to speak to a real person. It’s always good to have this option. You may not be able to connect them through to a person in the chat right away, but even some sort of contact details would be worthwhile.
- Wrong answer – If the user is saying that the bot has given the wrong answer to them, then it’s good to pick this up for feedback and also give other contact options to the user.
It is also good to include a set of common options after a certain intent or part of the conversation, so as to guide the user into a direction that the bot can assist with. For example, after booking a restaurant, possible next steps for a user would be to work out how to get there or to add the booking into your calendar.
Our first use case
The purpose of our first bot, Cai, was to help staff get their digital content signed-off and live. The current approval process for creating and publishing digital content was complex and involved a heavy amount of time between the content managers and risk teams just assessing the risk to work out other stakeholders that were needed for approval. Cai could help determine the right risk rating for content changes, advise on relevant next steps, and assist with any documentation required.
Ongoing operation – service blueprint
For the bot to survive, improve and stay relevant to the users, people need to be checking what is going on and making updates. For instance if the risk framework changed, then our connected bot would have to reflect that. Below is a basic service blueprint for Cai. It was very helpful to
Further use cases and ecosystem
Following implementation of our first use case, when we were looking at other internal use cases, we realised that a central assistant entry point would be needed. This would mean that instead of having 10 different singular bots for internal onboarding and processes, you would have one alexa or google assistant type interface that would hold all the company wide FAQs and then call upon separate unique bots when triggered.