Asynchronous chat is becoming an important communication channel for many contact centers. If you want to make the best use of it, read on to learn more about the challenges and potential benefits for your center.
First a quick definition: Asynchronous chat is a text-based conversation that normally takes place over a longer period of time via your website. It could be over the course of minutes, hours or even days. Instead of a “chat window” on your computer where both parties are actively typing back and forth, each person sends messages on their own schedule.
Example
Let me give you an example.
A customer sends a WhatsApp message to a company they purchased an item from:
“I received the dresser I ordered, but it was damaged as the delivery people assembled it. It isn’t major, but I expected to receive it with no damage. I’d like to exchange it.”
The business receives the message and one of its agents responds back:
“I’m so sorry to hear that. Would you mind sending me a picture of the damage so we can determine next steps?”
The customer is at work and sees the message a half-hour later and responds:
“I’m at work now, but I can send pictures when I get home”
The business responds:
“OK Thank you”
That night, the customer takes the pictures and sends them to the business.
At the business, the chat with the pictures comes to a new agent, because it’s a new shift. The agent receives the pictures, reviews the history and responds:
“Thank you for sending the pictures. Based on the small amount of damage, we can either exchange the item at no cost, or refund you 10% of the purchase price and you can keep the item”.
Key elements of Asynchronous Chat
This is one of the many applications of asynchronous chat. This scenario unfolded across the day. But if the customer was at home when the interaction started, it may have only taken 5 minutes. This channel will have a lot of variability based on the conditions. As of now, there’s not really a WFM technology that you can use for planning chat to this level of variability and complexity.
Here are the key elements we need to figure out:
- Turnaround time/SLA - How long should it take for you to respond to each customer message?
- Workload
- Volume of work - Weekly and intraday volumes
- Handle Time - Talk, wrap, hold and before call work
>> Also interesting: Our blogpost on Forecasting for Live Chat
Turnaround times for Asynchronous Chat
Let’s take SLA (Service Level Agreement) first. At this stage of the maturity of this channel, there is no standard turnaround time to respond to each initial contact and subsequent interactions. And, considering there will be multiple interactions across multiple hours or days, customer expectations here are likely to vary wildly. Because of this, it’s better to develop your own standard vs. adopting an “industry standard” as so many do with phone SLAs.
A great starting point for SLA development is to look at how your customer satisfaction (CSAT) scores correlate to various response times. If you’ve already established this for your phone channel, then that is a good point of reference here until you get enough data to establish your asynchronous chat CSAT correlation to speed of answer. So you can start by matching your phone, but only until you can develop one for the new channel.
Don’t fall into the trap of staying with that based on momentum. The use cases for asynchronous chat can be very different than the phone channel, and it will likely diverge even more in the future as this new channel gets more adoption and companies find new use-cases for it.
Because this is also a new channel for customers, they’ll need to figure out their own expectations. Depending on how you’re using the channel, this can vary. In the use case above, it’s not extremely time-sensitive. A customer would likely expect a quick response to their initial contact (because this is the first acknowledgement). But subsequent interactions would likely not require as quick of responses because once the customer sends the pictures, the agent needs to do some work to figure out what action to take.
An automated response acknowledging receipt of the pictures and setting expectations that the customer will hear back in X minutes may give the customer what she needs. At that point, the customer needs to know that the communication was received and when they’ll hear back. While establishing a formal turnaround time for customers, it’s best to constantly set expectations so they’re not left guessing.
Workload calculations
Contact volume will work similarly to models you build for other channels when you’re looking at the weekly or monthly levels. The extra work in planning chat is on the intraday and daily models. At this level of granularity, you need to understand the relationship between the first contact, and the rate and frequency of the subsequent interactions related to that contact.
In the earlier example, there were a few back to back interactions at the start while the issue was identified and expectations for next steps were set. So one contact turned into several interactions within the same interval. It also resulted in an interaction in an interval much later in the day. It’s possible that could have been the next day. Had the customer not been happy with the resolution, there could have been several more back to back interactions working through resolution.
To develop a model for planning chat, first understand the different types of initial contacts or use cases you’re using for asynchronous chat. Each of these will have a different pattern of subsequent interactions. Use this to establish the contact model for each contact type.
Then, create a forecast for each contact type based on the historical volume of initial contacts and subsequent interactions. So ultimately, just like with any other contact type, you’re building a contact forecast. You just have to go in and add another layer to that with the additional interactions and expected timing of those interactions.
Example: Contact Type 1
- The base forecast is 100 initial contacts per day
- There are generally 4 subsequent interactions for each contact the same-day
- The total daily forecast is 100 initial contacts and 400 subsequent interactions, so 500 interactions in total
The way this is laid out probably gets you thinking about handling time, because you’re either going to plan for 100 contacts with the total handle time, or 500 interactions with much smaller handle times for each interaction. How you do this depends on how scattered the volume comes in across the day(s). Let’s take a closer look at handle time now.
>> Maybe you are also interested in Forecasting for Social Media?
Planning for handle time
Ultimately, you need to determine whether you’re going to plan at the individual interaction level or the contact level which would already include the subsequent interactions. There may be a need to do a bit of both depending on how granular you’re able to plan. Once you determine the total handle time per contact type, you can divide that by the number of interactions to get the average handle time per interaction.
However, there may be different handle times for the subsequent interactions throughout the day. Going back to the example above, the handle times for the first few interactions would be relatively quick. But in the second wave later that day, if they were working through resolution options, the interaction time may increase significantly as the agent researches options, checks their policies, etc… The customer may also take longer to respond as they consider the various options.
Again, because this channel is relatively new, there’s not an industry standard on the approach here. As you look at the patterns in your data, it may become more clear if it's better for your business to plan at the interaction or the contact level. It may also vary by contact type or line of business.
Handle time for asynchronous chat consists of three components: writing time (which also includes the time for researching information), wrap up time (work that has to be performed at the end of the contact or in between interactions) and something we can call before chat work.
Here’s what the latter means: When a new agent takes over a chat (generally because time has passed since the last interaction), that person needs to get oriented to the situation. So when the customer sends a chat continuing a previous conversation, the chat needs to be acknowledged (I recommend automating this), and then the new agent needs to check the notes/history to understand the situation and be ready to provide a seamless response to the customer.
You do not want to ask a question or revisit content that was covered with the last agent. Otherwise, this is a huge customer dissatisfier. You’ll likely need to have agents use a particular state to track the “before chat work” time. But you don’t want to just have them use “after call work”. These are distinct processes, driven by different actions and if they are lumped together, you’ll lose important data as you plan.
In summary:
As I mentioned, there isn’t really a lot of technology designed to track and plan for asynchronous chat volume or handle time. Getting handle time data may be manual, or you may be at the mercy of the way your contact system tracks chats in general. As you determine whether you want to plan for contacts or individual interactions, leverage the data available to start to build out the model for each contact type.
As you get more advanced, you can build (or buy) the tools you need for tracking. But to get started, it may be manual and that’s OK. Nobody has this down to an exact science. It’s better to be “directionally correct” and start building models if your business is going to use asynchronous chat. Be open about the high margin for error as you get started. It’ll get more accurate as you get better at planning chat.
Also, be sure to build the technology requirements you need to be successful long-term. While being directionally correct is OK at this stage of maturity, in the near future it won’t be. This will be a more common channel and a higher percentage of your work, and labor costs will go through it. We’ll come back and write more about this channel in the future as it matures.
Did you find the article interesting and would like to share it with your colleagues? Download the article as a PDF.
