Create a Synchronous Messaging Experience in Messaging for In-App and Web
While Messaging for In-App and Web is designed to provide an asynchronous messaging experience that allows the end user to start, stop, and resume the same conversation when it’s convenient, it’s also capable of supporting synchronous conversations. To create a synchronous messaging experience with a clear beginning and end, follow the steps in this guide.
What is Synchronous Messaging?
A synchronous messaging 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, there may be a period of time where the end user waits for an available agent to join the conversation. In addition, there may be times where an end user can’t start a conversation because no agents are available. A synchronous messaging experience is like a digital version of a customer service phone call
In asynchronous messaging, participants aren’t required to be present at the same time. An end user can send a message, and then perform other tasks while waiting for a response. Agents can handle several conversations at once. For business use cases where real-time interactions aren’t critical or where a high volume of simultaneous incoming messages are expected, asynchronous messaging is highly effective.
Asynchronous messaging is the same experience you get when you message your friends and family.
Compare Synchronous and Asynchronous Messaging
If you’re still deciding which type of messaging experience to create for your end users, consider the pros and cons of synchronous versus asynchronous.
| Messaging Experience | Pros | Cons |
| Synchronous | Conversations have a defined end, which helps with agent productivity metrics Best for real-time interactions | Lower number of concurrent sessions per agent End user may have to repeat their question once the conversation is over or disconnected |
| Asynchronous | Full conversation history is available to the agent for context Higher number of concurrent sessions per agent Appropriate for use cases that don’t require immediate action or resolution | Not appropriate for emergency or real-time use cases Requires additional work to ensure that message history doesn’t get exposed to unauthorized parties |
Tools to Help Set Up a Synchronous Workflow
Since synchronous messaging is all about real-time interactions, it’s important to think about the lifecycle of the conversation. Specifically,
- How to manage messaging 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, an agent is available to answer your customer’s question. However, we know that’s not always the case. Some companies have strict business hours when agents are available. Others want to prevent end users from excessive wait times by caping the number of queued chats.
If all of your agents work during a single set of business hours, adding business hours to your Embedded Service deployment configuration prevents conversations from being initiated when agents aren’t working. This creates a clean cut-off point where the entrance to the line gets closed, but those who were already waiting can remain in queue.
If your agents work in tiered support teams, each during a different set of business hours, consider a more multi-faceted setup.
For example, imagine a scenario where a specialist group of agents handle more technical questions than standard support agents. These specialized agents are only available from 9am to 5pm, while your standard support team operates from 8am to 8pm. How do you make sure you have enough information to route the conversation to the right queue, while accounting for the different support hours?
One way to solve this challenge is to configure your Embedded Service deployment to not use Business Hours, but allow the user to open the chat widget at any time. From there, serve a pre-chat form that allows the user to provide their contact information as well as a dropdown menu for them to indicate the topic of conversation.
When the user clicks the Start Conversation button, the Omni flow you associated with the Messaging Channel will 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, you can create a case using the name and email provided in Pre-Chat, and then set a variable that explains that due to the limited availability of product experts, a case has been created and an expert will reach out via email when they are available. A process like this can then allow you to collect the intent to connect form your customer and switch to an asynchronous channel without forcing the user somewhere else where they would have to start over. Other alternatives include checking estimated wait time in specific queues in your Omni Channel Flow and assigning the chat to a more general queue if wait times 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
Once your end user has entered the conversation and is waiting for an agent to join, it’s important to set expectations. Messaging for In-App and Web lets you show end users an estimated wait time, which is based on the average time that the previous ten conversations from the last ten minutes waited in queue before an agent joined. Currently, estimated wait time is only available for conversations that are routed to a queue.
If you choose not to use leverage estimated wait time, you can use a Conversation Acknowledgement auto-response component. You customize a message that’s sent to the end user as soon as the conversation starts. You might use this component to welcome them, set expectations for a general wait time, or let them know that they can start typing a message and the agent will be able to view it when they join.
Learn more links for 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.
Empowering your agents with a workflow for ending the conversation is a great way to keep service level agreements, like time-to-resolution, on track. To help agents confirm that the conversation is over, create a messaging component that asks “Have I successfully answered your question?” Configure the enhanced conversation component so that agents have a Send Messaging Component action in their toolbar. Once an agent has confirmation that no further assistance is required, they click the End Chat button in the agent console, finish off whatever after conversation work they need to do, then move on to their next assignment.
The end user can also end the conversation by clicking End Chat from the messaging conversation menu. After an end user clicks End Chat, the agent can’t send a manual message. You may choose to send a final message or a survey with an End Conversation auto-response component.
Those examples describe scenarios where the agent or the end user proactively end things. But what should you do when the user has stopped 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 yet)
- They’re multitasking and simply haven’t returned to the conversation yet
- They stepped away from their computer or phone and haven’t seen the message
- They decide to abandon the chat without ending the conversation
In these situations, the agent 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-30 minutes). From there, the end user can either respond (which sets the messaging session status will be set back to Waiting and re-routes the session based on the Omni Flow assigned to the channel) or not (which sets the messaging session status to Ended after 24-30 hours).
Learn more about manually-send messaging components and automated Inactivity.