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.

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,

1. How to manage messaging requests outside of business hours.
2. How to set wait time expectations during business hours. 
3. 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. 

Below are experiences of the authors, and referencing features in pilot and actively updating every month

One of the most exciting innovations for me in the last 12 months has been Salesforce Unified Knowledge, because of the power it has to truly revolutionise AI automation in Customer Service.

I figured since I’m writing some blogs about Agentforce, this was an obvious candidate. Just a hunch, but I imagine we’ll see hundreds of companies going live and seeing value just from this one action alone, so it’s worth checking out!

What is it?

Knowledge content that agents use to get answers can be spread all over the place. Online help docs, a Google drive of pdf manuals, Articles in Salesforce or another tool, and much more. The Unified Knowledge connectors allow a company to merge all of that into a single searchable repository for Service Cloud users.

Why do we care?

Don’t get me wrong, it’s great to have good knowledge articles, but the impact this will have on Agentforce is what’s really exciting. Public API’s like ChatGPT are trained on google, and could be using data from anywhere in their answers, including a competitor, but an Agentforce Service agent will be trained off of a Companies knowledge base, allowing it to speak to the products, policies, brand, and tone of the company. So the more data we can get it, the better. Coupled with Einstein Knowledge Creation, which documents an article every time an agent has to answer a new question, we can get pretty fast to a world with an Ask-Me-Anything Service Agent.

What is a good Example?

I recently built a unified knowledge repository off of all the content on help.salesforce.com and unofficialsf.com. I spent an hour asking every setup question I could think of, on web chat and sms, and barely got a bad answer. Though I think I need to add an instruction to shorten the responses 😀

c

But how is this different from the Knowledge action on Bots?

Really key question, we shipped a Knowledge Action for Einstein Bots a couple of months ago, what’s different about Agentforce?

Both of the above examples are now possible by adding the Gen AI Knowledge action to an Einstein Bot, so it’s pretty powerful, but what makes an Agentforce Agent different is the ability to be conversational.

I’ll flag two examples:

1. I can ask back and forth questions, get clarification, dig into certain sections, or ask a follow up but with some different data.
2. It can use the context of the entire conversation, and data pulled back from actions, to inform the response that’s generated from the Knowledge base

Let’s say I have a knowledge base for a Travel Agency, with articles on every airline, and where every policy has a different answer based on whether I’m a Platinum, Gold, or Silver member. With Agentforce, if I ask about the cancellation policy for me, and it knows I’m a platinum member from my contact record, or earlier in the conversation, it’ll give me a personalised answer. What’s more, I can ask follow-up questions, and it’ll know the context of the previous answer and respond in kind.

See an example of a conversation I had below, and the Knowledge base it searched against to do it, separating out info about the airline, the Loyalty level, and the time of the flight.

Have a try yourself and see what fun conversations you can have???

And then maybe have a try yourself and see what fun conversations you can have? 🚀

————

By now I suspect many of you might have seen the tweets (posts?) from Marc B about Agentforce, or some of the great company announcements that have been shared.

The next generation of Customer service, moving away from traditional Bot experiences, towards a tool that can have a full conversation with a customer, should be up there as a major game-shifter in the industry.

I’ve been involved in a lot of projects at Salesforce, but this is by quite a distance the one that’s gotten me most excited as I play with it.

What’s exciting now is that Salesforce is opening up the pilot to many hundreds more customers!

I thought I’d start writing a blog series about the new tech to share what I’m learning. How to get started, different use-cases to build, some reusable assets, what it is, what it isn’t, and everything in between. Target audience being admins who are setting it up. Would love to hear some feedback in the comments on what you’d like to learn more about as well.

How to get into the Pilot

• Come along to Dreamforce and give it a try – we’re running a lot of hands on workshops and sessions
• Reach out to the Account Executive to ask if it’s possible to be included in the pilot

….more to come in the next few days/weeks. See the Service Cloud page for more posts