The transition from human to virtual support agents promises many advantages: maximum availability, increased efficiency, elimination of waiting time for customers and cost savings. While the first two blog contributions in this series dealt with the significance of Knowledge Management, the final contribution focuses on the functionality of the chatbot and the requirements that accompany its introduction.
Today, when we talk about the use of chatbots in a classical[i] IT support context or as part of a DevOps construct, the most distinctive feature lies in the use of artificial intelligence (A.I.). However, it is not about placing the chatbot in a production environment where it then develops its own efficient and self-learned analytical logic, independently creates or predicts solutions, or identifies the steps required to eliminate faults. These skills, which are provided by the 2nd and 3rd Level Support teams, are still beyond the capacity of today’s chatbots.
Prohibitive factors to realisation include not only the current status of economic feasibility compared to traditional 2nd & 3rd Level Support and the critical nature of application-regulated business processes. The inherent complexity of creating artificial intelligence and training it using deep learning to analyse and solve unknown problems in an unknown environment still poses an enormous challenge.
These limitations aside, the chatbot is capable of providing outstanding service in the role of 1st Level Support. This includes accepting user questions and complaints, providing answers or forwarding them on to 2nd or 3rd Level Support. The chatbot receives a query from a user and attempts to interpret it through the application of artificial intelligence, or more precisely using (automated, machine-made) Natural Language Processing (NLP). At this point, the fault diagnosis structure (the decision-making or solution trees developed by Knowledge Management) comes into play. This provides the correct answer to the interpreted query or asks further diagnostic questions if the interpreted user’s text does not contain all needed information for a precise qualification of the user’s enquiry.
Through the technology of Natural Language Processing and continual training and testing of the A.I., the chatbot develops the ability to answer not only fixed questions and commands, but also to respond to individual questions placed by the user.
The interaction between the user and the chatbot is illustrated in the following example:
The chatbot receives the incoming request “I need the installation manual”. Assisted by artificial intelligence, the chatbot is capable of understanding that it should forward the user a document and that the document is a user manual. The user’s request is not sufficiently explicit (which product is involved); however, the chatbot is capable of placing further clarifying questions using the decision-making trees created by the Knowledge Management team until the request or issue is unambiguous.
Whether the user is looking for a website or user manual, has a question or a problem with an application, the chatbot first attempts to understand what the user needs, analyses the situation using the decision-making trees and checks whether there is a “match”.
If a match is found, the solution is provided to the customer either as text in a chat window, as a link that can be opened or as a document. If the chatbot is integrated into a website, the solution can also be displayed within the website or in the application.
The following diagram provides an overview of the processes and information flow in a chatbot-serviced support environment:
Requirements for Implementation
The successful introduction of a chatbot in IT support requires consideration of the following factors:
- Identification of the complexity level taking into account the number of products involved, the complexity of the knowledge database and the number of available knowledge objects.
- Choice of technology and solution platform – this can range from an in-house development of the solution to the use of open source or proprietary solutions, e.g. Google DialogFlow, Microsoft LUIS + Bot Framework or Amazon Lex. The decision should include consideration of criteria such as cost & licence models, required languages, available communication channels, and an assessment of technological maturity and user friendliness.
- Definition of the support bot personality, which determines the communication style and describes the tonality of the bot’s responses. This factor is often underestimated although the chatbot is part of the company’s image to the outside world.
- Choice of communication channels, via which the chatbot will be available to the user. This can include online channels, apps or social networks.
And most important of all is reliable knowledge management.
If the framework conditions are in place and the introduction of the chatbot is successful, the ongoing task is to continually train and test the virtual agent. Reporting and data analysis are extremely important here. The advantages offered by a virtual support agent can only be fully realised, if these are in place.
A chatbot solution is not only branch independent, multilingual and available around the clock. If implemented correctly, it can lead to faster solution identification and consequently to greater user satisfaction. And if the number of tickets to be processed by IT support can be reduced, the result is a clear increase in efficiency and a reduction of costs.
As an advocate of knowledge management, I see in virtual support agents the opportunity to fully realise the potential and benefits of a high quality knowledge database. The benefits are branch-independent and, above all, offer added value for customers and their end users.
[i] In this context a classical IT support construct means:
- Direct contact to the user is through a “1st Level Support”, i.e. via a hotline, which is responsible for accepting user queries and complaints. Simple questions that are documented in the knowledge database are answered by the L1 agents. “Trial & error” and deeper analysis (log files, etc.) are not carried out by L1.
- More complex and unknown faults analysed and solved by 2nd
- Extremely complex faults and bugs are passed on via L2 to the third and highest support level. (3rd Level Support, Product Owners, i.e. Developers).
Latest posts by Nejib Kchouk (see all)
- Chatbots: When the Bot becomes a Virtual Support Agent - 8. August 2018
- Chatbots: The Key to Success lies in Knowledge Management - 21. June 2018