As text chat becomes more common, the task of correctly calculating the number of seated agents you need is becoming more pressing -- and in many ways, more challenging. Overestimate requirements, and you'll have capable staff sitting idle, with commensurate negative impact on your budget. Underestimate, and you'll disappoint customers with poor service and potentially damage your brand and long term customer loyalty.
The mandate: if you're going to roll out text chat as a contact channel, do what it takes to get staffing levels right.
At a basic level, text-chat is a service level-oriented contact, and the essential planning steps apply. 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 computer simulation to calculate staff requirements based on the usual input -- number of contacts, average session transaction time (average handling time), and your service level objective.
However, this can overestimate actual requirements in many cases; between workflow-routing options and technology possibilities, there really is no "one-size-fits-all" approach. You will need to make some key decisions to deliver acceptable levels of service efficiently in your environment.
Let's begin by looking at some important terms. The following are definitions that we use and recommend. (Note: Depending on the application, the roles may be reversed -- e.g., the agent may make an initial request to a customer browsing the organization's Web site.)
SESSION: The whole of the text-chat 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 the close-out.
CLOSE-OUT: The moment in time when the session is considered to be complete.
While some organizations use text-chat extensively, it makes up a relatively small portion of the contact workload in many others. If you're just starting out, you'll need to answer a fundamental question at some point: 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 text-chat, advanced mathematical approaches won't yield any more accuracy than common sense. We believe that a sensible threshold is five -- when you need five or more agents handling text-chat at any one time, a more disciplined approach will begin to pay off.
Another important decision is around the number of simultaneous sessions you allow agents to handle. Some systems can be configured to enable 16 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, employee morale and even reporting.
Our advice to those just starting out: Go with one 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 concurrent session you can move, some basic math comes in handy. Let's assume that you set the maximum number of concurrent sessions at five. It's simple and valuable to develop worst-case estimates. The formula: 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.
In short, these are issues you'll need to review with your supplier. How does the system make these calculations and what do the reports produced really mean?
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' Web sites. (Text-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 text-chat revolves as much around questions of workflow and technology application as it does on mathematical calculations. As volumes rise, we expect to see common practices emerge. Even then, you'll need to make decisions in each of these areas that are right for your organization and customers.
Service Level In the World of Text-Chat
Call center professionals often liken the time it takes to receive a reply to an email or text-chat to what service level means to phone contacts. But there is an important difference: Speed-of-answer statistics associated with phone calls are based on when the call reaches the agent. But speed-of-response for email and text-chat is based on when the customer receives a reply, which can only happen after the agent actually handles the inquiry.
Is this distinction important? In the world of email -- where response time is typically measured in hours or days -- not usually. But text-chat is different. Response time is measured in seconds or minutes, and the time required for the agent to craft the reply must be taken into account.
We've seen cases where well-intentioned executives set a response time target for exchanges of one minute or less when it takes longer than that to create the right reply! That's a recipe for disaster (or, at the least, for missed targets). It is up to the management team to establish workable objectives supported by the right level of resources.
The Reporting Challenge
Although multiple concurrent sessions can improve productivity, they can also make reporting more difficult. Consider again the example of five concurrent sessions, where all five customers initiate an exchange at the same time. The last customer served will have to wait 6.25 minutes for a response -- but most of that time was spent on other exchanges with other customers. The reporting challenge is accounting for these variables.
For example, when a customer initiates an exchange, the reporting system must note how many concurrent exchanges are already in queue for that agent in order to determine the exchange handle time. The customer who is fourth in line will wait a total of five minutes for a response. Divide that wait time by the number of exchanges in queue, and you'll come up with the exchange handle time of 1.25 minutes (5/4) -- but you can see that reporting must account for many variables.
--Brad Cleveland is the president of the International Customer Management Institute (ICMI). He can be reached at bradc@icmi.com.
http://www.callcentermagazine.com
Copyright 2006 CMP Media LLC. All rights reserved.
12/1/06, Issue # 1912, page 20.
