Designing your messaging customer experience

Articles in the series

• Messaging deployment guide: Introduction
• Part 1: About messaging
• Part 2: Designing your messaging customer experience
• Part 3: Planning your staffing and operational requirements for messaging
• Part 4: Planning your messaging rollout

At its core, messaging is a way for your customers to have direct communications with your agents. As your support needs grow, you may want to automate some of these journeys. You might start by offering a simple greeting before handing a customer over to a live agent. Later, you can incorporate self-service options such as deflection using knowledge base articles, capturing information from the customer to aid in triaging to ensure their request is routed to the correct set of agents, and integrating third party systems to offer a completely personalized experience.

This article discusses some of the basics you should understand before designing your customer experience.

This article covers the following topics:

• Choosing a conversation style
• Designing basic conversation bot elements
• Considering offline scenarios

Choosing a conversation style

Depending on your organizational needs, you can build a messaging bot that is as simple or as complex as you like.

Short and simple

If a streamlined, live chat-like approach works best for your agents and customers, you can implement a bot that offers a simple, automated greeting before handing the conversation over to an agent. With minimal configuration, you can add a simple form to collect essential information from the customer to give agents a better idea of who they’re serving, or suggest articles from your Guide help center that allow customers to self-solve their support issues without requiring agent intervention.

Intricate and comprehensive

You can also address complex customer service scenarios, and provide some equally complex messaging solutions. Build a bot that includes preconfigured options for your customers to choose from, pull information from external sources into a conversation using API calls, offer choices based on customer location or the time of day they send a message, and more.

Meet in the middle

You’ll probably want to design a conversational bot that falls somewhere between the styles listed above. You can do that too. Messaging is easily scalable and infinitely customizable, so your automated customer interactions can be almost anything you want them to be.

We recommend adopting this one golden rule: Don’t get lost trying to over engineer your conversational workflows. It becomes really difficult to undo once you’ve done it. Be pragmatic, design workflows for simplicity while you’re learning about messaging. You’ll always be able to iterate and improve that “ideal experience” as your service delivery experience grows.

Designing basic conversation bot elements

Before mapping out your entire customer experience plan, we recommend familiarizing yourself with the basics of a messaging conversation:

• Greetings, the customer’s first interaction with your conversation bot.
• Self-service options, ticket deflection tools so agents can address more complex support requests.
• Conversation and ticket workflows, which includes how and when the bot passes the conversation to a live agent, the path a messaging support ticket might take after that happens, and how agents and customers can interact both synchronously and asynchronously.

Greetings

The greeting sets the tone for a messaging conversation. Imagine a customer opening a conversation bot for the first time, and consider these questions:

• What do you want your first impression to be? Casual and friendly, or all business? Decide what kind of voice you want to give your bot.
• What information do you want to immediately convey to your customers? You can (and should) use the greeting to set customer expectations for services you’ll provide, agent availability, and possible wait times.

Self-service options

Your bot can save time for both your agents and customers by with options for the customer to self-solve their support issues. There are a number of ways you can incorporate these into your conversation bot:

• Suggesting help center articles can direct customers to Guide content that can provide information they are looking for, such as product instructions or company policies.
• Presenting predefined messages can give customers immediate answers to commonly asked questions.
• Pulling data from external sources into a conversation, using API calls, is especially useful when a customer requests information that may be updated regularly or is particular to them, such as system status or current wait time for assistance.
• Asking if a question is resolved lets your end users tell you whether one of the bot answers above resolves their support issue, and gives them the opportunity to close out a support ticket before it gets to an agent.

Conversation and ticket workflows

No matter how thoroughly you design your conversation bot, you’ll receive a customer support request that needs to be transferred to a live agent, and have a ticket assigned to it. You’ll need to consider when and how the transfer occurs, establish rules for how the conversation is managed after transfer, and the path the ticket takes

Think about under which conditions you transfer issues from your bot to your agents using the information it gathers during the initial conversation. Like the other elements discussed in this article, transferring a conversation to an agent can be as straightforward or elaborate as you like.

The handoff to an agent can be a simple message that lets the customer know they’re being transferred, then adding the conversation to an agent’s queue. If needed, you can incorporate any of the following to the handoff interaction:

• Forms to gather customer data.
• Estimated wait times to set customer expectations.
• Notification options that allow the customer to be contacted when an agent is available.

You’ll need to consider how a conversation is managed after it’s handed off:

• Conversation assignment. Are conversations assigned to agents or agent groups, or can agents manually pick them up?
• Conversation routing. Will you triage and escalate conversations to a particular group or skill?
• Customer notification. How will you let customers know when an agent enters the conversation?

  You will also need to determine how you manage the ticket that’s generated from the messaging conversation. The following tools are available to help guide a ticket from Open to Solved.

• Agent Workspace. This is the hub for agents’ ticket and conversation management.
• Views: You can create views to manage and organize ticket workflow.

Considering offline scenarios

Because of the persistent and often asynchronous nature of messaging, you should plan for situations where either an agent or customer is not available to respond immediately to a message.

Messaging tickets, like all other channels, are managed in views. Some of these offline scenarios will require you to set up some new views to filter between active and idle conversations that go active again and might need reassignment after an agent’s end of shift, for example.

The scenarios below are among the more common ones you should take into account when designing your flows.

Customer is no longer responsive

If the end user stops responding mid-conversation, an agent can:

• Ask if additional help is needed. After 10 idle minutes, agent should tell end user that they are updating the ticket to “pending” or “solved” and that the end user can re-engage (ticket is pending) asynchronously or start over with Flow Builder (ticket is solved)
• Leverage automation to change the ticket status to pending, or to solved/closed. Keep in mind that a solved ticket could trigger the bot to display a customer satisfaction (CSAT) query. In this case, best practice is for the CSAT trigger to be updated to exclude any auto-solved tickets

Agent is offline/customer responds after business hours

• Agents should reassign tickets before their shifts end to prevent communication bottlenecks from forming while they are offline. A view to display unassigned messaging tickets can be created.
• If a customer responds to an unsolved ticket while the agent is offline, the agent will see the customer message in the Notification List when they log back into Zendesk.
• For longer periods of agent unavailability, consider utilizing the Out of Office app.

Customer responds after the ticket was closed or solved

• If the ticket is Solved, the conversation will go back to the original agent in the Open state.
• If the ticket is Closed, the end user will return to the Answer Bot flow and a new ticket would be created during the Transfer to Agent step.