Designing your virtual assistant to target common user needs

Photo by Alvaro Reyes on Unsplash

This article covers how to organize a set of user needs according to complexity and frequency and prioritize them into a milestone plan for designing a virtual assistant.

Before you start building your virtual assistant in Watson Assistant, you should allocate time to carefully plan how that assistant can best serve your users.

A virtual assistant is more than just a classifier and some orchestration logic, in the same way that a graphical user interface is more than just lines and styling. A virtual assistant is a complete user experience channel. It requires a careful and thoughtful design to satisfy end users. The quality of your design sets an upper limit on how successful your virtual assistant can be.

A virtual assistant should be optimized for the channel it is delivered on. Assistants built with Watson Assistant are commonly deployed in voice channels (i.e. telephone) and web channels (i.e. websites). Voice and web have different strengths and weaknesses and your design should account for these. A good response for voice may not be a good response for web chat and vice versa.

Regardless of channel, it is important to design a virtual assistant that can be useful without requiring a “boil the ocean”[1] approach. You should brainstorm on all the things that your assistant could do and then build an iterative plan to implement them. High-frequency and low-complexity requests are the first things an assistant should cover (e.g. “What time do you close?” is a high-frequency, low-complexity question in retail). As the frequency of a request decreases or its complexity increases you need to decide on an appropriate strategy: is there a simple strategy for the request, or should it be escalated out of the assistant?

What processes will the assistant handle?

In order to build a virtual assistant that delights your users, you must have a solid understanding of what your users want from the assistant and how you can provide it. You need to have business processes that your assistant should follow, and if these don’t exist you will be creating them! For example, if you don’t have a repeatable business process for resetting a user’s password, how can you automate it in a virtual assistant?

As you design business processes and adapt them for a virtual assistant you may find challenges that require you to use a phased approach in delivering functionality. Processes often have a “shortcut” version (for example, tell the user where they can go to reset their password) and a fully automated version (ask a series of questions verifying the user and then resetting their password for them).

When you work out a plan for which processes to implement in your assistant first, make sure you keep the user in mind.

Designing for the most common user needs

When building a virtual assistant you should not try to address every possible issue, rather you should first focus on high-volume and high-value activities. This is particularly true for your first venture into virtual assistants. You should do an assessment of what information and processes you already expose to your users through other channels.

You can review call logs, search queries, interview subject matter experts, or more. If you have a call center, shadow them for a day and see what kinds of calls they receive. Your business may already keep track of the top customer demands, and if so you can use that information repository to guide this exercise. Many companies do not keep detailed records of what types of customer interactions they have and how frequently, and for them a major benefit of virtual assistants is to start collecting that information. Note that the closer you are to real user data, and the farther away you are from opinions, the better you will do in this exercise.

Now, we’ll develop an implementation plan for a customer service virtual assistant for an imaginary retail company called FICTITIOUS INC. We’ll reference the Watson Assistant Customer Care Content Catalog[2] which contains a list of intents covering frequent customer service request types. These are shown in Table 1. These intents are fairly generic for a retail customer service use case and help quickly bootstrap the assistant.

Table 1: Customer Care intents, covering frequent customer service request types

Schedule/Manage Appointments     Get Contact Information
Change Security Questions        Reset Password
Get List of Products             Get List of Programs
Add/Remove Authorized Users      Check loyalty status
Open Account                     Cancel Account
Adjust Notification Preferences   Apply for a job
Redeem Points                    Transfer Points
Store Hours                      Store Location
Update User Profile               Report Fraud

Before coding a bunch of dialog flows in Watson Assistant, we need to develop a plan for FICTITIOUS INC. We have the list of their most common request types above. Now we must approximate the complexity behind satisfying each type of request. One can use a simple low-medium-high scoring, or a t-shirt sizing (small-medium-large) complexity scale. The goal is to quickly sort the types of requests into a 2x2 grid where the dimensions are formed by complexity and frequency. An empty grid is supplied in Figure 2. Try placing each of the request types from Table 1 into the grid for FICTITIOUS INC.

Figure 2: Empty prioritization grid. Try placing the intents from Table 1 into this grid!

Gauge complexity by what it would take completely and automatically satisfy the request according to your business processes. Many request types can be satisfied with either a simple question and answer response or a complete process flow. Consider different possible versions of the “open account” flow.

Simple (Redirection) flow for “Open Account”

Question: “I’d like to open an account”
Answer: “Please call our service line at 1–800–555–5555 and press 2 to open an account, or go to our account creation site at [link]”

Fully automated flow for “Open Account”

Question: “I’d like to open an account”
Answer: (A process flow with these steps)
   1. Gather identifying information
   2. Determine account type
   3. Use account query API to see if an account already exists
   4. Use account creation API

You can always start by addressing a request via redirection or giving a purely informational response, then later automate more of the response in future versions of your assistant. A virtual assistant that always redirects may not provide the best user experience, but it can still be helpful to users. For the sake of this planning exercise, let’s focus on the fully automated response first.

“Open account” requests are one of the most common request types for most retailers. This request type definitely belongs on the top half of the grid. As shown above, creating an account requires several follow-up questions and several API calls. That’s enough complexity to earn a spot in the upper-left quadrant (high volume, high complexity).

Requests for your contact information, such as for a phone number, mailing address or email address, are also high-volume requests. These requests are simple to address: just return a static answer and the request is satisfied. We can place “Get Contact Information” in the upper-right quadrant (high volume, low complexity). Try placing all of the FICTITIOUS INC requests from Table 1 into a grid. When you’re done, review Figure 3 which contains my analysis of the FICTITIOUS INC intents.

Figure 3: Volume and complexity analysis of customer care request types from Table 1. An implementation plan must be based on cost-benefit analysis. Focus first on high-volume, low complexity tasks.

Based on the plot of frequency and complexity you can perform a cost-benefit analysis. That analysis shows you what to implement first in your virtual assistant. The highest return on investment comes from the high-frequency, low-complexity requests, and you should handle as many of these as you can.

Next are the high-frequency, high-complexity request types. For these, you need to determine if there is a useful quick win to satisfy the requests (can you provide a link or general answer?) or do you need to escalate these types of requests to an alternate channel like a human-staffed call center. You will need to train your assistant to recognize these requests even if the assistant does not service them.

As time permits you can address the easiest requests in the low-frequency, low-complexity segment. Take care not to spend too much time and introduce too much virtual assistant development work for these.

The low-frequency, high-complexity requests may never be appropriate for an automated solution and you can use a generic escalation strategy on these. A generalized plan is shown in Figure 4.

Figure 4: A generalized plan for requests based on volume and complexity

There’s much more on virtual assistant design in the Creating Virtual Assistants book. For more help in designing your virtual assistant solution, reach out to IBM Data and AI Expert Labs and Learning.

[1]“Boiling the ocean” refers to an impossibly large scope. Consider how much energy it would take to boil the ocean versus to boil a gallon of water.

[2]https://cloud.ibm.com/docs/assistant?topic=assistant-catalog