Chatbots – can they really enhance the customer experience?

Chatbots can be a material barrier to providing good service, resulting in increased traffic to the Service Desk and disgruntled users. They can also be a game changer, both to improving the user experience, and reducing the cost of providing support.

In this article we explore the steps involved in launching and optimising an effective Chatbot. We use the context of an internal Service Desk (IT, HR, Finance, Facilities, etc), but this can equally be applied to customer-facing Contact Centres.

Imagine the scenario… you require support for a service you are using, you do not have the time (maybe the need or even the inclination) to speak to someone over the phone (assuming you can find the number), so you try and multi-task by using the support team’s online chat solution. After you launch the chat tool and enter your first words (known as an “utterance”) you realise that the person you are chatting to isn’t a person at all… it’s a dreaded bot! You spend the next 10 minutes being presented with unrelated guidance and going around in a loop trying to work out how to speak to a real person.

It doesn’t need to be like this, and it shouldn’t be like this. Most reputable Chatbots on the market offer perfectly adequate base functionality. It’s the way the bot is configured that makes the real difference. So how can you avoid this scenario and provide a Chatbot service that genuinely enhances the user experience? We recommend a three-step approach:

Step 1: Get the foundations ‘right’

For day 1, you do not need perfection, but quality does need to be sufficient to not put users off (otherwise they may never return).

There are three key foundational aspects:

1. Content – without content, the Bot could look beautiful and be functionally rich, but add zero value. Content is critical. Content is broken down into two data pools:

a) Domain Specific – Content that’s specific to your organisation. This is broken down into three content types:

ai) Catalogue Items – the products and services that your users can request from you. Each should have a defined name, description (including meta data to support effective search), form, fulfilment workflow, fulfilment service level and cost. 95%+ of all end user raised Service Requests should be raised via self-service (Chatbot or Service Portal), and the majority can be fulfilled via automation. See our related articles for more information.

aii) Knowledge Articles – guidance information that enables end users to self-resolve their issue or query. Following a Knowledge Centred Support (KCS) approach to Knowledge Management will increase the prospect of a well-structured and continually maintained Knowledge Base.

aiii) Topics – these are content items that are built directly into your Chatbot. They can be arrival topics (welcome messages and initial options), conversation flows (transforming a Knowledge Article into a step by step ‘decision tree’ guide to provide a more immersive user experience compared to reading a static Knowledge Article page), fallback topics (what you present to your user when the user is not getting the information they are looking for), or anything in-between. They need to be carefully planned for, and will evolve over time as the maturity of your bot improves and user feedback grows. At this stage, focus on those Topics that users will be searching for the most.

b) Global Content – heard of ChatGPT (or perhaps other Generative AI solutions)? Most Chatbots can integrate with Gen AI solutions (and some Service Management tools will soon have their own) providing your users with access to global content instead of creating local versions in the form of Knowledge Articles (e.g. solutions to common Outlook problems). Including global content will require security, data protection and license reviews.

2. Analysis Tools – Supporting the above, you’ll require visibility of the user journeys: What are users entering into the bot; where are they dropping off; which journeys seem to predominantly end with the user still needing to speak to a human agent? Most Chatbots come with effective analysis tools, for example, some form of NLU Workbench or Expert Feedback Loop. Most will require some degree of configuration. Set targets on what good looks like for you, and monitor accordingly.

3. BotOps Team – Chatbots require regular investment to keep up with the user’s support needs. The BotOps team are responsible for analysing the data (using the above tools), identifying areas for improvement, and executing those improvements, either directly into the Chatbot (more on this in Step 3) or liaising with the Catalogue Management and Knowledge Management Practice Owners to drive improved content. A Chatbot BotOps team typically consists of:

• Data Analysts
• User Experience (UX) Specialists
• Project Managers – for any more material improvements to the Chatbot such as new APIs and user journey flows
• Scrum Masters, Developers & Testers
• Knowledge Managers – be that dedicated to the BotOps team or a natural extension of your existing Knowledge Management team.

Depending on the size of your organisation, these could be shared, consolidated part-time or full-time roles.

Step 2: Start small

If you utilise a reputable Service Management tool, you may already have a Chatbot included within your license. But you may not have turned the Bot on yet, perhaps through user experience concerns or questions around value. The best way to start, is by starting small.

A ‘doorman’ solution is a quick and easy way to introduce a chatbot to your user community, while still adding value by providing users with improved self service capability and reducing contacts to your human Service Desk Agents.

A ‘doorman’ welcomes the user and signposts them to common solutions through selection ‘blocks’ / options. For example, the user is trying to:

• Request something – clicking this option will take the user to your Request Catalogue in the Service Portal.
• Self-resolve an issue - takes the user to your Knowledge Base in the Service Portal.
• Report an issue – takes the user to the Incident Logging form in the Service Portal (noting that this approach will unlikely be as responsive)
• Something Else – takes the user to your Live Chat solution.

When this is established, this could quickly be followed by switching on Natural Language Understanding (NLU). This enables the user to enter their own utterance and allow the Bot to search your content (Catalogue Items, Knowledge Articles and Topics), presenting users with results directly in the Chatbot instead of taking them to your Service Portal. This is where key decisions need to be made, for example, search preference… do you want the Bot to search Topics first, or Catalogue Items/Knowledge Articles? If in doubt, seek guidance from your vendor or a specialist.

Step 3: Evolve

Remember that BotOps team? This is their time to shine.

BotOps primary responsibility is utterance to intent matching – what is the user typing, has the Bot understood the intent correctly, and have we matched that intent to the appropriate content? For larger/complex organisations, this could be a multi-day activity, for smaller/less complex organisations, perhaps once a week or once a month. The aforementioned data analysis tools are crucial here to not just support the analysis, but execute these ‘simple’ low risk changes with a few clicks directly into Production (yes, we did just say Production, and appropriate change control principles will need to be defined, agreed and governed).

When you have utterance to intent matching in a good rhythm, you can look at more advanced capabilities. These include (but are not limited to):

• Advanced Topics – taking those immersive conversations flows even further.
• Self Service Automations – either utilising tools within the same platform, or integrations with other products such as a Digital Employee Experience Management tool, the Chatbot can interpret a user’s utterance, provide the user with the option to run a diagnostic tool and perform fixes (deferring to a Service Desk Agent if that does not solve the user’s issue).
• Modality Reach – Integrate your Chatbot into applications where users spend most of their time thereby providing improved support at the Point of Need (PoN). Messaging tools such as MS Teams are common out of the box integrations for most reputable Chatbots.
• Support Scheduling – if the Chatbot cannot provide the self service information (or automation) that the user requires, and they need to speak to an Agent, provide them with an option to schedule a convenient time to receive a callback/chatback, or, if hands on support is required, an appointment at a local office tech-bar.
• Know Your User – your Chatbot should already know who the user is (without the need for additional user log in credentials). Enhance this further by utilising user data you already have available in your Service Management tool. For example, Mac or Windows user, office or remote based, new joiner, etc. You can then automatically tailor your Chatbot’s responses based on these known data points.

You should now have a Chatbot that end users want to use as they see value in the service it provides. You should also experience a material reduction in contacts to the Service Desk, and those that do still require human Agent support will have improved context as to the support required thereby reducing contact time.

?

Other considerations:

• As your Chatbot becomes more useful, your Service Portal will become less important. That doesn’t mean to say not to invest in your Service Portal (for example, expanding your portal to be a one-stop-shop for end user support covering all your global business services (HR, Finance, IT, Facilities) etc is another game changing service. And it definitely doesn’t mean you can stop investing in the Request Catalogue and Knowledge Base… content is key!
• As you’ll be making ‘simple’ changes directly into Production, you’ll need to refresh your non-production environments regularly, otherwise your more complex changes will be tested in an environment that does not reflect the actual user experience.
• Make use of the platform upgrades that your vendor provides – these are in two parts:

1. New functionality – UX improvements, Generative AI, etc.

2. New search algorithms – these should improve your search results, but they could conflict with search improvement rules you may have created in the past. Ensure to perform plenty of post-Production deployment testing.

• Consider language translation needs. This can be a minefield and will require full analysis of the translation capabilities available within your tool. For example, will you require a third party machine translation solution, and does your tool dynamically translate utterances to match the content, or the other way around.

It’s worth noting that most of the principles above also apply to Voicebots. However, due to the user experience variation between the two bots (for example, a voice bot talking a user through an immersive conversation flow would take a long time and cause user frustration), other considerations need to be applied, which we’ll cover in a later article.

If you require support with your Bots, we’d be happy to help. Please message more, or send your enquiry to [email protected]. To find out about our services click here.

Chris Good