Response patterns

Automations

An automation, sometimes called a Do-It-for-Me (DIFM), is a response where the bot does most of the work for the customer.

Automations should:

• Save the customer time or cognitive load
• Not ask for info the bot already knows
• Explicitly confirm anything sent on behalf of the customer, like requesting a payment from the customer’s client
• Personalize suggestions. For example, “Your minimum payment is $39. Would you like me to schedule that payment for three days before the due date, like usual? That would be June 27.” 
• Answer off-topic responses from the customer, then continue the conversation.

Data collection

If collecting data from the customer for the automation, the bot should:

• Have a response when the customer answers with a word when asked for a number, and vice versa
• Have a response when the customer answers with an impossible response, like requesting to pay more than the total of a bill

You also need to consider what happens if 1, 2, 3…, or all slots are given at once, and make sure the bot can adapt to all scenarios.

For example, if the bot is sending a payment request in QuickBooks, the data points needed include:

• amount
• due date
• date the request will be sent
• who the request should be sent to, and
• what the request is for

So if someone says they want to send a payment request to Nancy Drew on June 27 that needs to be paid by July 15 for clue analysis, the bot should follow up with the missing data point: What’s the amount of the request?

Disambiguation

Front door and disambiguation responses are used to discover more about the customer’s intent, especially when they use just a string of nouns for their request (for example, taxes or address). 

A front door response asks an open-ended question about what the customer wants to do.

A disambiguation response gives the customer 2–3 action options. These are used when the bot is confident the customer will choose one.

How-to instructions

How-to instructions provide steps to achieve a goal. They should:

• Be brief enough to cover the key info (additional info should be a follow-up or a link) 
• Consider the real estate available for that platform (mobile vs. desktop)
• Be specific to the product the customer is using
• Be a multi-answer workflow when steps are lengthy
• Set expectations as to how long the instructions will take if it’s a multi-response flow
• Provide a way for customers to track progress or come back later to finish if it takes longer than a few minutes
• Provide warnings that help the customer be successful, like “Once you start a transfer, it can't be canceled.”

Insights for AI

Insights answer the “so what?” of raw data.

Be clear about what we do and don’t know

If we don’t know something for certain, it’s OK to soften language rather than being definitive, which can have legal ramifications.

Be transparent about why the insight is being shown and how it was developed

Try to get ahead of questions or concerns a customer might have (such as “What is this based on?” or “How certain is it?”)

See also: insight

Don’t use language that might have legal consequences

Watch out for definitive statements, “guarantee” words, and superlatives that can’t be backed up by data. If you’re unsure, ask your legal partner.

Small talk

Small talk is where a lot of the bot’s persona shines through. Your bot should be able to give responses to Hello, Goodbye, Thank you, Who are you?, Are you a bot?, and even Do you watch Westworld?

Small talk answers should respond in kind but get the customer back on track with what they need. Never ask a customer a question at the end of small talk that you don’t have an answer for. 

Unhappy paths

Unhappy paths are unavoidable. But when the bot doesn't understand the customer or can't handle a request, we don't abandon or frustrate our customers. See also: Delivering bad news

Fallbacks

It's not possible to predict every potential request a customer might have for the bot. We use fallback responses to get customers back on track when the bot hasn’t been trained on a good answer.

Fallbacks use other technologies, like search, to:

1. Help customers rephrase their question
2. Present FAQ search results
3. Connect the customer to other help, including human support

Good fallbacks should:

• Be transparent and tell customers what happened, such as, “I couldn’t find anything about that.” 
• Be empathetic. The customer is going to be disappointed that there is no answer.
• Offer a way to self-serve or get help another way, like community topics, elevating relevant articles, or talking to an agent.
• Keep small talk to a minimum. The customer still needs help. 
• "Fall upwards" and suggest other intents and articles that might be close to the customer's query. You can help them rephrase their question or offer pills of similar queries to get them to a matched intent.
• Set appropriate expectations to prepare customers for what they're seeing. For example, "I found this answer."
• Always provide options for customers to indicate whether their question has been answered.

Errors

Something is bound to go wrong. An API fails to get data or the system fails to commit changes for an automation. The generative model is down. A plug-in is down. The model timed out. All of these situations should be handled with transparency and empathy.

Responses should:

• Be transparent that something went wrong
• Protect the Intuit brand
• Offer a path to another solution, such as self-service with an article or escalation 

Escalation

Escalation means connecting the customer to one of our human agents or experts. Be sure to address the customer's question and why the bot can’t answer, then offer the path to the escalation plug-in.

Good escalation paths: 

• Show up as an option when something is wrong, when the situation is complex and difficult to navigate (such as reconciliation), or when the customer asks for it. 
• Consider the stakes and urgency of the situation. If the risk is really high and there's a direct path to the right agent group, provide that routing path instead of the general one. 
• Are paired with an offer for self-service unless the risk is high to the customer and/or the company. Example: “I don’t have an answer for that, but I found this article. Or I can connect you with a human.”
• Consider if the situation calls for creating a ticket instead of providing a contact option. Example: Someone tried to update something in the system, but it’s not working. It’s not crucial that it be done right away—just in a reasonable amount of time.

Welcome

A welcome message should break the ice and explain how customers can use the digital assistant. It not only greets the customer, but sets the friendly, conversational tone for their entire interaction.

A well-designed welcome should:

• Have different first-time and return welcome messages to build trust
• Be personalized to the customer
• Be transparent that the customer is talking to a bot 
• Contain a brief statement about what the bot can do
• Offer basic response options to promote engagement (Like Ask a question, See answers to FAQs, and Contact us)
• Provide proactive support for the most common questions or issues

List a Contact us option so customers know human support is available

Workflows

A workflow is a set of responses that guide the customer through several steps. They can be used for onboarding, set up, contact us, automations (like paying a bill), and anything that requires more than one turn from the bot

Workflows should: 

• Set expectations as to how long this instructions will take 
• Consider the real estate available for that platform (mobile vs. desktop)
• Be specific to the product the customer is using
• Start where the customer left off if the customer exits early
• Support the seven answer paths with pre-set choices, if asking a question