How can your Enterprise Software Company give 24/7 Customer Support using Chatbots?

Context: This is an overview of how I would go about implementing “chat as a support” for the client (an Enterprise SEO Company). To keep the discussion in some boundary, let’s say we want to reduce the volume of support tickets in various channels, especially Phone calls. Instead, we want to increase the chat requests for support.

Appmakery Bot Development, Machine Learning
Appmakery’s new bot for local businesses and consumer

8.1 Overall Approach

  1. Define Business Goals related to this initiative (to transform the support system into primarily a conversational chat based system). For e.g. one of the goals can be ‘to reduce overall cost of operating support system for customers/end users’. This along with other considerations will be part of “mini support strategy”.
  1. Based on the business goals, we can come up with a product strategy. Based on what is existing currently, and the timelines provided, we will develop a comprehensive product strategy for various channels of support.  
  • The product strategy must take various things into consideration, for e.g. which technologies will we use for each of the support channels, how those technologies will fit into our overall goal (and technical roadmap) of providing conversational chat, the success rate expected, and many such factors. The product strategy will also outline what kind of new products/solutions we are going to build to achieve our goals.
  • Based on a given timeline, it’s possible to incrementally achieve our goals, iterate our product and processes. For e.g. if we have quartlerly or yearly goals, then we need to make sure we plan accordingly. For quarterly (immediate goals), we can pick the solution that is fast and can have a fast impact on the end users. This in turn motivates stakeholders, developers and the client to further development in the right direction.
  1. Based on the product strategy, we can define specific KPIs we will measure in order to measure the success of what we are doing (ongoing), as well as overall effectiveness of the new system being deployed. For e.g. current ticketing numbers show that Voice based support calls are 200 times more than chat based support. So one of the KPIs we can track is the ratio of Voice/Support tickets or  Average Time-to-Resolve (which measure which channel is faster in solving customers issues).

8.2 Identifying Target Audience Needs

  1. We will create various customer personas which will list user behaviours, needs as well as recommend solutions to meet each of those customer needs. Here since we know the average age of Client’s employees is 27, it will be safe to assume that end users are used to modern web 2.0 consumer applications (even business applications now are very consumerized for e.g. Slack).
  2. To validate problem statement and user expectations, we can first look at competitors and see whether they are thinking about the problem the same way, and why not if not. Looking at competitors solutions and approach sometimes makes things very clear. Apart from that, in-person interviews, surveys are good ways to understand how end users feel about the current system and what might be needed in the new system. In some cases, building low cost “pilot” solutions to test our hypothesis is also recommended (depending on the time and resources provided of course)
  3. Some examples of End user needs: Chat should be easy to find anywhere (omnichannel), Fast response to basic queries/issues, Stateful Chats which take into account support issues from previous chats, and more….Solutions to some of the above needs can be straightforward to very complex. For e.g. fast response to basic queries can be designed using a knowledge graph (that our system can talk to). For designing stateful chats, we will have to design a solution that stores the intent of customers when they leave chat. It’s possible for a chat system to start a conversation next time, in a meaningful way, next time the customer joins back the chat system.

8.3 Technology fit and Market Presence

Chatbot / Conversational bot way of supporting customers is definitely a good way to reduce support volume/ phone call volume. Some technologies we need to develop are:

  1. Develop context aware chatbots/conversational interfaces that users advanced AI to understand the context of the end user.
  2. Write technology to allow complex transactions in the chatbot, for e.g. paying bills, etc
  3. Deploy technology in a way that all incoming support requests are first allocated a weight (such as probability of ticket being solved using chatbot conversation) and to develop a machine learning model that improves way tickets are routed to various channels.
  4. Develop Natural language capabilities such as string matches, common expressions and patterns to identify variables and entities in a chat request.
  5. The escalation from Chatbot to Human and Human back to chatbot has to be seamless so that user experience is great
  6. We can also develop a knowledge graph, which connects to all sources of information from various sources, to deliver precise links to the end users that can lead to more self-service
  7. Deploy the Chatbot in consumer applications such as messenger? Although I understand this is not for real consumers I assume.
  8. Develop solutions to get voice conversations data from phone support system.

8.4 How will new products / solutions integrate with existing system:

  1. We can define an endpoint in ServiceNow and GSD where our AI based chatbot Engine will accept any incoming support requests (from all channels). The requests are then escalated/routed to various channels based on the type of request. The Intelligent routing will automatically assign cases based on skills, availability, location, and more.
  2. Agent workspace will need various tools, optimized layout, integrated solutions that will let him/her move in and out of the chat based support for a user (this includes on-site support specialists and other agents during the lifecycle of support )
  3. The new products we will build (such as AI solutions) can seamlessly interact with the existing system using web based API’s (if needed). Also any third party vendors or AI products (such as AWS ML, API AI) can easily integrate into our products/solutions using webhooks.
  4. Similarly, ServiceNow also allows for thirdparty to plug into any workflow, so that should be straightforward.

8.5 Project plan, Technology Roadmap

  1. The project plan will outline all the various key milestones, individual owners, budgets, impact on business with each milestone (revenue, volume etc). For e.g. let’s say we have 2 years to achieve our goal of making 50% of chat volume to come through the chat platform, and $2M allocated to achieve this goal.
  2. The project plan will assume that we have the necessary technical talent to carry out individual projects.
  3. Since most of the chatbots are based in English, it will be good to first get the solution right for English country users first (Americas and Europe) and then to other regions of the company.
  4. The technology has to seamlessly evolve and achieve the goals for the users (i.e. making sure people who are using chat system are happy with the support that they are getting).

Some of the key milestones in evolution of our system will be:

  1. Getting the basic chat platform right that understands the basic/everyday support requests from the users and the intent behind them.
  2. Getting the system perfectly right for 1 country/Area.
  3. Forwarding incoming support requests after understanding their meaning and context. During this period, the team will constantly learn from the outputs to train our ML algorithm to get better at understanding incoming requests.
  4. The system will slowly evolve as we achieve various KPI thresholds set by us are achieved. For e.g. if certain no of requests are successfully processed by the chat clients, then we can move the platform live to other regions.
  5. We will incrementally test the features that we are launching, pause or speed their execution, depending on what is working and what is not working and based on timeline and goals to be met.

8.6 Change management plan

  1. Change has to be properly communicated across the organization so that everyone is aware of the change taking place. It’s even better to make sure employees are aware of changes that might come during planning phases.
  2. By creating suitable marketing campaigns, it is possible to create awareness about the new product/solution. A good marketing message will tap into the real needs of employees/users and highlight how the new solution will help them fulfill those needs. To do this, we can also use Customer Jobs theory to market to employees and show them how new solution can save them a lot of time and get the job done much faster for them!

          We can include a feature in the solution that makes it easy for one employee to share the solution with another employee. For e.g. Ajay saved 30 minutes today by using the new chat platform, and this needs to be communicated to a new potential user (employee) who might adopt the new system based on the results achieved by Ajay.  

It’s also possible to reward employees in some manner for using the system, but this can’t be at the cost of our end goal 🙂 We will have to make the reward system in a manner that it encourages employees to use it, at the same time doesn’t lead to bad actors.

3) The new chatbot should be easily accessible, findable, usable from anywhere in the organization. Using deep linking it’s possible to embed a link to the exact point in a chat system (which can be accessed by employees). The specifics of this will depend on where we are implementing this.

8.7 Country onboarding

  1. One of the easiest way to ensure countries adopt this solution is by showing them current usecases that are performing well for a certain country. The more exact match the usecase is, the more likely the other country will adopt it.
  2. Another way to ensure countries participate and adopt this solution is by having a overall Corporate strategy to reduce support costs, call volume and other important related metrics. Such an initiative can force others to look for solutions like our chat solution.
  3. The onboarding itself will consist of various tools, processes, knowledgebase and technical teams who will help various countries to pick the solutions, implement them, solve issues, evaluate and reimplement again.

Designing for various countries:

  1. We need to design a chat platform that understands the meaning of the incoming support requests. This leads to a very consistent experience for everyone. Although this is not easy.
  2. It is important to design the conversation in a way that leads to unique experience for individual countries. For e.g. greetings, idioms, current news, etc are some of the ways to personalize and connect with individual country users.
  3. Lead by asking questions, and clear consistent FAQ’s that are designed for the target country.

8.8 Pricing Approach

Pricing strategy is usually picked based on the goals of the organization in a given timeline. For e.g. a service can be free to use, but only specific transactions or features will be charged for.

Since adoption is a big goal (based on the document) in this project, we would give out the pervasive chat support  for free and determine individual features for which we can charge individual countries. Depending on the need vs cost analysis, we can decide which features should be charged in which countries. With this approach, we can price in a way that the solution is affordable by all countries.

There are also many other approaches to pricing, but for the sake of this document (and time), I will finish this section here.

8.8 Success Factors and Risks

Success prerequisites:

  1. Maturity of the solution
  2. Technical team to implement the solution
  3. Communication to ensure engagement, awareness of the solution
  4. Support of Top management

Measuring Success: We measure success by looking at certain KPI’s such as:

  1. Overall Customer happiness
  2. NPS score
  3. % increase in adoption month to month
  4. % drop in phone support (quarterly, yearly, monthly)
  5. Time to market ( has to be fast and reasonable, within the given timelines)

8.9 Risks:

  1. One of the main risks of deploying a chat platform is that chat platform doesn’t behave the way it should in the beginning. This can be supervised to make sure any critical problems are urgently addressed and fixed and rolled out to production.
  2. A chat platform can increase time for end users and add to frustrations instead of solving user problems. It’s really important that we have a check on the number of times user has to type/present his/her problem before routing to a real human support.
  3. Important to have a roll back procedure ready whenever needed so that we can seamlessly remove parts of chat support without affecting the end users.
  4. Chat support might not understand how people from various countries are interacting with it.

8.10 Recommendations:

  1. The user experience has to be seamless, from AI-chat to real human and human to AI-chat
  2. The user experience must delight users in a way that they keep coming back to the system.
  3. User experience must go beyond answering basic FAQ’s and solve real problems for the end users that can otherwise take a lot of time and effort on the part of users.
  4. Very important to design a Text=>Understanding of Text algorithm ( continuous effort) to understand user queries as most chatbot system fail because of lack of understanding of what humans say in various contexts.
  5. Might be a good idea to gather all the support data from all sources and clean it and arrange it in a way that give us some insights as to how to go about building our chat platform.

Leave a Reply

Your email address will not be published. Required fields are marked *