Create a Synchronous Chat Experience in Enhanced Chat

What Is Synchronous Chat?

A synchronous chat experience is a real-time conversation with a beginning and end. Each participant is present when the conversation starts, and both remain engaged for real-time interaction. In a customer support scenario, a time period can occur during which the end user waits for an available service rep to join the conversation. In addition, a scenario can occur in which an end user can’t start a conversation because no reps are available. A synchronous chat experience is like a digital version of a customer service phone call.

In asynchronous chat, participants aren’t required to be present at the same time. An end user can send a chat and then perform other tasks while waiting for a response. Service reps can handle several conversations simultaneously. For business use cases where real-time interactions aren’t critical or where a high volume of simultaneous incoming chats are expected, asynchronous chat is highly effective.

Compare Synchronous and Asynchronous Chat

If you’re still deciding which type of chat experience to create for your end users, consider the pros and cons of synchronous versus asynchronous.

Tools to Help Set Up a Synchronous Workflow

Because synchronous chat is all about real-time interactions, it's important to think about the lifecycle of the conversation. Specifically:

• How to manage chat requests outside of business hours.
• How to set wait time expectations during business hours.
• How the conversation ends.

Manage Requests Outside of Your Business Hours

In an ideal situation, a service rep is available to answer your customer’s question. However, it’s not always the case. Some companies have strict business hours when reps are available. Others want to prevent end users from excessive wait times by capping the number of queued chats.

If all your service reps work during one set of business hours, adding business hours to your Embedded Service deployment configuration prevents conversations from being initiated when reps aren’t working. Business hours create a clean cut-off point where the entrance to the line gets closed, but end users who were already waiting can remain in the queue.

If your service reps work in tiered support teams, each during a different set of business hours, consider a more multifaceted setup.

For example, imagine a scenario where a specialist group of reps handle more technical questions than standard service reps. These specialized reps are only available from 9 AM to 5 PM, while your standard support team operates from 8 AM to 8 PM. How do you make sure that you have enough information to route the conversation to the right queue, while accounting for the different support hours?

First, allow the user to open the chat conversation window at any time. Present a pre-chat form that asks the end user to provide their contact information and indicate the topic of conversation.

When the end user clicks Start Conversation, the Omni flow that’s associated with your chat channel begins to execute. In that flow, you can check for business hour records that are specific for the Issue Type (Technical Support) and then choose not to route the messaging session. Instead of routing the session, create a case with the name and email address provided in the pre-chat form. Set a variable to explain that a case was created and an expert will respond via email when service reps are available. A process like this makes sure that your end user is able to ask their question one time instead of being forced to try again during business hours.

Alternatively, you can assign the chat to a more general queue if wait times (based on Estimated Wait Time) are too high or no one is available.

Learn more about setting business hours, advanced routing with Omni-Channel flows and the reasonForNotRouting flow variable.

Manage Wait Times During Your Business Hours

After your end user enters the conversation and is waiting for a service rep to join, it’s important to set expectations. To show the end user how long they must wait to hear from a service rep, add Estimated Wait Time to your chat conversation window. Estimated Wait Time is based on the average time that the previous 10 conversations from the last 10 minutes waited in queue before a service rep joined. Currently, estimated wait time is available only for conversations that are routed to a queue.

If you choose not to use Estimated Wait Time, you can use a Conversation Acknowledgment auto-response component. You customize a chat that’s sent to the end user as soon as the conversation starts. You can use this component to welcome them, set expectations for a general wait time, or let them know that they can start typing a chat.

Learn more about Estimated Wait Time and Auto-Response Components.

Decide How a Conversation Ends

The last stage of the synchronous conversation experience is deciding how it ends.

Uphold service level agreements, such as time to resolution, by giving your support team a workflow for ending a conversation. To help service reps confirm that the conversation is over, create a chat component that asks “Have I successfully answered your question?” Configure the enhanced conversation component so that reps have a Send Messaging Component action in their toolbar. When a service rep has confirmation that no further assistance is required, they can click the End Chat button in the service console, finish after-conversation work, and then move on to their next assignment.

The end user can also end the conversation by clicking End Chat from the chat conversation menu. After an end user clicks End Chat, the service rep can’t send a manual message. You can choose to send a final message or a survey with an End Conversation auto-response component.

Those examples describe scenarios where the service rep or the end user proactively ends things. But what about a scenario where the end user stops responding? The reasons why an end user stops responding vary.

• They temporarily lose internet connectivity. (Don’t worry, users can rejoin conversations as long as their authorization token hasn’t expired.)
• They’re multitasking and haven’t returned to the conversation.
• They stepped away from their computer or phone and haven’t seen the chat.
• They decide to abandon the chat without ending the conversation.

In these situations, the service rep can manually set the conversation to Inactive. Alternatively, you can set up automatic inactivation, which sets a messaging session to Inactive status if the user hasn’t responded in a set amount of time (between 5 and 30 minutes). From there, if the end user responds, the messaging session status is set back to Waiting and the session reroutes based on the Omni Flow assigned to the channel. If the end user doesn’t respond, the messaging session status returns to Ended after 24 to 30 hours.

Learn more about manually-send messaging components and automated inactivity.

Track Messaging KPIs

You can use custom report types and Data 360 reports to monitor KPIs such as response time and handle time.