Enhance your call centre with chatbots

In this 4 part series, we explore some of the challenges faced within call / contact centres and how chatbot technology can help alleviate some of these challenges and provide you with additional customer insight and increased customer satisfaction.

• Part 1: What's wrong with calling us?
• Part 2: How to begin
• Part 3: Channels
• Part 4: Integration and self service (coming soon)

Introduction

When considering the implementation of a chatbot there are a plethora of platforms, approaches, and service providers who claim to have the right solution for you.

Our approach is to be as agnostic as possible, and focus on bringing the right approach, and the right technology together to achieve your goals within desired level of investment.

We focus on what we will broadly call "call centre deflection" whereby we are aim to:

Reduce the number of inbound phone calls to your contact centre, by offering enriched / instant self service options, and extending these with live chat, in order to enable your customers to reach you faster on a communication channel of their choosing, to enable you to provide a richer customer experience with less overhead requirements on your contact centre agents.

Where is the low hanging fruit

We find the best point to start with is looking at your current contact centre drivers and mapping these against average call volumes. Although as we mentioned in the first part of this series that this is often just a subset of what customers are engaging about (ref: softer queries not always necessitating a phone call), it does provide a tangible mechanism to align content, and calculate a likely return on investment from the implementation of a chatbot.

The overall goal is to identify ~10 core themes of why your customers are calling you and break these down further into sub intents to give us an initial framework of what types of questions are likely to match a reasonable percentage of your inbound customer queries.

The key goal here is to focus on quick wins, or common queries in order to give enough value for launching the chatbot (without frustrating your customers with its initial limitations), whilst recognising that real world usage will be required to improve your overall chatbot.

If we take one example contact driver where someone wants more information around Covid-19 as they have an upcoming trip booked with you, we may break that down further into some high level sub instants such as:

They want to cancel
They are concerned and want to know if you intend to cancel their trip
They have restrictions in their local area and are no longer able to travel
They want to know what restrictions might be in place at their destination
What (if any) tests are required in order to be able to travel

And so on....

The point of the activity is brainstorming for all of the actual endpoints that your customers may arrive at, and ensuring that the repertoire of your chatbot includes as many of these as possible.

From here, you have your high level roadmap of what intents we are going to attempt to actively reduce from your contact centre.

To button or not to button

One topic that can often instigate polarising viewpoints is how should users interface with your chatbot? Many solutions focus on offering a curated, yet funnelled end user experience which is mostly comprised of menu items and very specific dialogs that are shown to a customer.

Whilst this can be very effective for a narrow set of capabilities (e.g. The infamous example of "I want to order a pizza"), it often does not align well to a multi-faceted organisation who requires a chatbot to help support customers vs. utilise a chatbot for very prescribed activities.

The solution is often to support a menu based approach as a fall-back or optional layer for those customers who feel more comfortable with navigating through various options however with a deeper natural language processing model in place to accept and interpret any text based query that the user may have.

This covers both bases, and more importantly enables you to curate the menu to target key topics or contact drivers whilst allowing for significant expansion in your chatbots capabilities through adding numerous additional intents post launch to cover new queries without the need to constantly rework your base structure.

How to launch

Unlike many other types of projects, a chatbot engagement should launch early and iterate on an ongoing basis.

There are a number of good reasons for this - primarily that you may think you know what your customers are going to ask your chatbot, however it's almost certain you do not.

Remember that most planning and design that has fed into the chatbot up to this point is based on data / insight / experience from dealing with customers on a different channel such as voice or email.

If we have lowered the point of entry for customers to ask a questions (i.e. Instant, no waiting) we are much more likely to get unexpected queries from our customers.

To clarify, our key contact drivers for launch should be as curated as possible and contain numerous training terms and undergo a "reasonable" amount of testing to capture as many valid queries as we can.

The reality though is that as soon as a chatbot launches, it will be out of date within a matter of hours as it's sample data from real world usage will increase dramatically.

We refer to this as a long adoption tail for the project where ~80% of the effort of implementing a chatbot actually comes post launch.

Telemetry

Considering the anticipated challenges of refining a chatbot post launch, how do we ensure that we can undertake this ongoing improvement?

For our clients, we implement a custom logging solution which logs every query ever made against the chatbot, the date/time that it took place, a unique identifier of the session (anonymous but groups an individual conversation together), and critically the previous / referrer intent or match that we had from the previous answer.

We also optionally pass this through a DLP filter to ensure that no personally identifiable information is stored within the logs.

This telemetry is curated into live visual reports which provide the critical insight into how the chatbot is performing which includes tracking the percentage of "unmatched" intents and also which intents most often lead to an unmatched outcome.

An unmatched intent is quite simply a state where the chatbot was unable to determine a "match" to a predefined answer. This is almost certainly due to the customer asking something in a slightly different way than you expected.

What about post launch

While a significant proportion of queries can be successfully matched at launch (approx. 70% is realistic), we need to constantly train the chatbot to improve it's awareness of similar queries in the future which would help towards the remaining 30%.

Take an example of an intent (answer) we have setup that will tell our customers who to contact if they have left an item on one of our planes.

During the development phase we added numerous combinations of training terms such as

I left something on the plane
I left an item on the plane
Left an item
And so on

This will do a reasonable job of matching a high percentage of customer queries, but consider a query such as

I flew with you yesterday from Edinburg and think I may have left my wallet on the plane, I was sitting somewhere towards the middle

From a human perspective, the query makes sense. However for the chatbot and natural language processing there is a lot of superfluous data to unpick where the additional noise in the query may have a better chance of matching an intent to help you select your own seats:

I am flying to Edinburg and want to sit somewhere towards the middle

Herein lies the challenge, based on the customer query which a human could easily see was related to an item left on a plane - it would be perfectly reasonable for our chatbot to think they wanted to select their seat and therefore provide a completely irrelevant response, thus frustrating your customer.

It is at this point that many chatbot solutions would stop, a bad experience ensues, and chatbots get the blame.

The good news is, we don't implement to stop at this point as by our count we are only 20% of the way through the project.

Through leveraging the unmatched query metrics we are recording in our telemetry, we manually review all exceptions on a daily basis and make a determination as to which answer is the best match.

The unmatched query is then added as a new training phrase to the intended intent, therefore ensuring that any similar queries in future have a better chance of being recognised correctly.

If there is no appropriate intent to add the training phrase to, that phrase is then flagged for consideration as a new answer / intent to include within the overall chatbot vocabulary in the future.

This continuous improvement is key, and through a number of months will converge a chatbot solution towards 98/99% accuracy for understanding the intent of your customers.

Of course this does not translate to fulfilment statistics as there will always be a percentage of customer queries that do require the specialist skills from your agents (~15%) however a well tweaked chatbot can significantly reduce the inbound load for those queries which can be answered directly or redirected to self service options.

Is it all about the exceptions?

Not at all, whilst exception management is critical to your chatbot solution being seen as relevant and useful - we have during the process captured a significant amount of data.

Through the basic metrics of a query, the matched in intent, and the referring intent - we have all of the ingredients required to recommend some proactive changes.

For example if we have a contact us intent which we provide to customers where we believe they need to talk to an agent, from the aforementioned data we can look at detailed graphs which show us exactly what intents people visited (by way of it being a matched answer) before we recommended they contact us.

From here we can revisit the largest referring intents to contact us and look at these in more detail with a view to either improving the answers, or identifying candidate topics for additional self service.

Recap

In order to reach the widest possible set of customers, chatbots should offer both menu based and natural language based navigation.

Chatbots need to be launched "early" with a long adoption tail that sees the chatbot updated on a daily basis to reflect real-world unmatched query terms.

Through this analysis, you are not only improving the accuracy of responses you are providing to your customers - you are also identifying additional opportunities for automation and experience improvement.