By
Brad Cleveland
|
Date Published: January 27, 2014 - Last Updated August 22, 2018
|
Comments
Chat is growing quickly, and for good reason. It’s an interactive, context-oriented channel that enables customers to quickly tap the expertise of agents. It can boost customer satisfaction, sales, and first contact resolution. As chat has grown in use and impact, effective resource planning has become increasingly important.
So, how do you staff for chat? Let's begin by reviewing some important terms. (Note that depending on the application, the roles may be reversed — the agent may make an initial request to a customer browsing the organization's website.)
SESSION: The whole of the interaction, from hello to goodbye.
EXCHANGE: A part of a session that begins with an inquiry from the customer and concludes with a response from the agent.
SESSION RESPONSE TIME: The time it takes the organization to respond to the initial request for a session from the customer.
EXCHANGE RESPONSE TIME: The time that elapses between the customer sending a question or comment and the delivery of the agent's response.
CUSTOMER RESPONSE TIME: The time it takes the customer to read an agent's reply and send a response.
EXCHANGE HANDLE TIME: The time it takes for the agent to prepare and deliver a response during an exchange.
SESSION HANDLE TIME: The cumulative total of the exchange handle times for the session.
SESSION TRANSACTION TIME: The time elapsed from the beginning of the initial exchange to close-out.
CLOSE-OUT: The moment in time when the session is considered to be complete.
While some organizations use chat extensively, it makes up a relatively small portion of the contact workload for many others. If you're just starting out, you'll need to answer a fundamental question: When do you move from "educated guessing" to staffing approaches that are more scientific? After all, if you only need one or two agents handling chat, advanced mathematical approaches won't yield any more accuracy than common sense.
ICMI recommends that a sensible threshold is five — when you need five or more agents handling chat at any one time, a more disciplined approach will begin to pay off. (This is also a sensible threshold for social and other types of interactions.) At that point, and as with all channels, a methodical approach to resource planning is recommended—you’ll need to establish an appropriate service levels, workload forecasts, and so forth (see figure, ICMI’s recommended planning process.)
Chat is a service-level-oriented contact (meaning these interactions need to be handled as they come in, versus deferred to a later time). You can determine the most conservative (highest) estimate of agents you'll need by assuming that each agent can interact with only one customer at a time, then using Erlang C or simulation to calculate staff requirements based on the usual input — number of contacts, average session transaction time (the equivalent of AHT), and your service level objective.
Assuming one customer at a time, as with phone, will overestimate actual requirements in many cases. Agents can handle more than one session at a time. But how many? Some systems can be configured to enable 16 or more simultaneous sessions per agent, which, of course, is impractical from a human standpoint in most cases. The number of maximum concurrent sessions you allow will impact response times, customer satisfaction, accuracy, and employee morale. Between workflow-routing options and technology possibilities, there really is no "one-size-fits-all" approach. Our advice to those just starting out: Go with no more than two or maybe three, until you get a better read on what's possible and get the kinks worked out of the system.
To determine how far beyond one session at a time you can move, basic math can come in handy. Let's assume that you set the maximum number of concurrent sessions at five. Consider worst-case estimates: Multiply the maximum number of concurrent sessions you expect by the average exchange handle time. The result will give you an idea of what could happen (worst case) to customer wait times. For example, if five customers initiate an exchange at the same time, and the average exchange handle time is 1.25 minutes, the last customer in line will have to wait 6.25 minutes for a response (5 x 1.25). This scenario won't happen often. But if and when it does, the delay would be well beyond the expectations of most customers. So, five concurrent sessions would be too high for an organization focused on delivering high levels of service.
Another decision you must make is when an agent will receive a session. If a customer's initial request is immediately delivered to an agent, you can send an automated, personalized greeting from that agent to the customer. If you decide to wait on routing, you will need to deliver either a blank text-chat box or one with a generic greeting. Here's the staffing tradeoff: If you provide the more personalized approach, you will need to live with the chance that you may be tying up an agent too early — some customers will request a chat session but then never initiate the exchange, and the agent will be left waiting for a question that never comes. Given this possibility, you will probably want to allow relatively more concurrent sessions per agent than in a scenario where an agent is selected only after an exchange is initiated.
You will also need to define when a session ends. Often, the point of close-out is clear, but sometimes it's not. For example, customers may get what they need and ignore further attempts at communication; they may step away from their computers; or they might head off to competitors' websites. (Chat is often perceived to be less personal than phone calls, and customers may apply different rules of courtesy.) While your agent waits for a response, the session is considered active. So you'll need to decide on procedures to try to re-engage the customer, and when the agent can, in effect, "give up" and close the session. Staffing implication: The longer the threshold until close-out, the more time the agent will spend waiting for an exchange that may never occur; accordingly, a long threshold would suggest you can allow a relatively higher number of concurrent sessions per agent.
In short, staffing for chat revolves as much around questions of workflow and technology application as on mathematical calculations. As volumes rise, you'll need to make decisions in each of these areas that are right for your organization and customers.
More Resources