Click to Visit

Click to Visit


Staffing for Direct to Support Representative Responsive Support
By Jim Hendrickson, Founder, Technical Support Management


Many Technical Support organizations avoid implementing the Direct to Support Representative model for a variety of reasons. Most common is the belief that it is easier to manage a call back model in terms of staff planning, and support representative comfort. There is also a mistaken belief that in an environment where cost is always a major concern, it is the lower cost solution. While on the surface it may be easier to manage staffing, once the techniques of real time staffing models are understood, it is not that much more complex. More importantly, the Direct to Support Representative model is what the person contacting you wants to experience. The counterintuitive reality is that it is actually the lower cost model. Issues get resolved quicker, with fewer total interactions, and less total time spent per case for resolution. Once you accept that premise, it works across all sources of contact – Telephone, Email and Web Submissions. For purposes of this discussion, we will start with Telephone Support.

The Basics – One Product

In order to describe the concepts we are going to start with the simple case of a single product, or single product family, which then assumes that all of the Tier 1 support representatives are trained to handle in-bound Calls. In order to develop a daily staffing plan for calls, there is a set of metrics we want to use to measure performance, and a set of data we need in order to develop the plan.


These are defined in detail in in the In Bound Call Center Metrics section. For discussion purposes, we will summarize each here in the context of developing the Staffing Plan Process.

Time to Answer – Key to good customer responsiveness, we need to establish a goal of how fast we expect the call to be answered by a support representative, and measure actual vs that goal. For example it is very possible to achieve the goal of answering the phone in less than 1 Minute at least 90% of the time.

Average Hold Time – the ACD/IVR can provide data for average time for holding, and if you are achieving your time to answer goal, it will likely be only slightly higher than one minute.

Abandon Rate – abandons (caller dropping off the call) are typically because they don’t want to wait beyond what they already have and will take some other action.

Average Talk Time – in technical support of moderate to complex problems, the time taken on the initial call can vary widely depending on the skill level of the caller, and the complexity of the specific issue that caused the call to come in. It is important to know what the average is so that you can take corrective actions when you get calls that vary from the average. We will discuss this in more detail later.

Percent First Call Resolution – In a customer service environment, contract questions, access ids, licensing questions, most calls can be handled on the first call. In technical support some additional research is likely to be needed on some of the issues and will require additional contact via phone or email.

Percent First Day Resolution – similar comment to above, but it is important to measure and monitor both.

Average Resolve Time – this is the actual time the issue will require a support representative(s) to spend resolving issues. Again in a technical support environment, there will be wide variations, but by monitoring the Average, you will be able to spot issues that are taking too long and are candidates for escalation.

Average Case Open Days – is an effective way of monitoring the backlog, and is useful in determining the amount of research time you need to schedule in order to bring the time down.


In addition to the data from your Metrics tracking system above, you will need additional information in order to develop a staffing plan.

Call Arrival Rates by ½ hour increments by Day of the Week – can be reported out of your ACD/IVR. This allows you to see the patterns of when your calls come in. Calls don’t come in on a regular basis throughout the day or the week. If you are operating in a single time zone, you will likely see peaks first thing in the morning, in the hour before lunch, and the hour before quitting time. Look at graphical representations of the data – it will give you some real insight into how people behave when they are contacting you. Best Practices indicate that you should use the same inbound queuing approach for issues submitted via eMail or the Web, so you will need to get that data as well from you email routing software, and your web submission software.

Developing the Staffing Plan

Since you are likely already using a call back approach, you have available staff to take the inbound volume. It then becomes an exercise in how to schedule them to respond to inbound queues throughout the day. As we pointed out earlier you will have more staff on queue during the peak times during the day, and less during the quieter periods. Also you will want to target a limit on the number of hours doing queue handling, to allow for research time, breaks, training, meetings, vacations, etc.

Erlang Tables – there is a very powerful tool that has been developed that uses the above metric data and staffing data to develop a detailed daily staffing plan showing number of support representative required by hour by day. It then becomes your job to do the actual individual support representative assignments. To learn more Dave Brown has written an excellent white paper, “Headcount Forecasting” on the subject, and three other papers available on his website – For other options check “Support Center Tools” for Staffing and Scheduling developed by Kristin Robertson – – under Free Resources. She also describes how to use Erlang in her book “Spectacular Support Centers”.


Erlang Variations – the resulting staffing plan is based on the theory of probability and statistics. It takes historical data patterns and predicts a likely outcome for the future. The larger your support team is, and the larger your inbound call volumes, the more accurate it will be. However, we all know there is no way of accurately predicting the future. So it becomes important to monitor actual activity in real time mode, so that you can take corrective actions.

Your ACD/IVR can provide real time displays of critical information, such as Number of Calls per time period, Calls answered in less than one minute, number of callers on hold, abandon rate. These allow you to spot potential problems and take corrective actions. The two most common variations, are more or fewer calls than predicted, and one or more calls taking much longer than the average. This gives you the ability to take corrective actions – add more staff to queue, get help for the really long call, etc.

Tracking over time

You will also want to show the Metrics over time – by day, by week, by month. As you and your staff become more comfortable with this approach you are going to find your metrics improving – faster response time, shorter resolve times, higher first call resolution, and first day resolution. You want to make sure all of this information is displayed in a public way, so that your staff sees the benefit of the change.

Skill Based Routing

Now that your responsive support has helped grow the business for your product, you are ready to implement Skill Based Routing (you may have been big enough to do this at the time you went to direct routing). Dave Brown describes 3 levels – Basic, Intermediate, Advanced – in his white paper on the subject. The purpose is to use the understanding you have of the skills of your support representatives to direct the inbound calls the person most skilled to deal with the issue.

Basic SBR

You want to organize your support representatives into groups that have common skills to handle the patterns of issues you are seeing in the calls you get. The most extreme example would be to handle Priority 1 – down systems – which places your most skilled engineers into one group. The remaining support reps are grouped by their skill sets to match the patterns of the issues you see on a daily basis. Once you have the groups set, you can set up your ACD with queuing questions in order to route specific types of calls to the appropriate group. You will find this also improves your first call resolution rate, and lowers your resolve time.

Multiple Products – Intermediate SBR

With these principles understood, you apply all of the above concepts to the more complex environment of multiple products. For two products – Product A and Product B – in the simple case you would start with two queues, and two skill groups, and refine it for higher volumes based again on specific skills within product that apply to groupings of issues within products.

Cross Training

A core requirement of making SBR work effectively is to cross train your support engineers to broaden the types of issues they can handle within a product, or to handle cross products. The efficiency you will get from direct to support rep and SBR will free time for your people to increase the amount of time they can spend in technical training. With a solid cross training process in place you improve your flexibility in handling all of the exceptions you will see – call spikes, long calls, new product (with defects), etc.

eSupport SBR

Once you have been through process of establishing the infrastructure, training, process documentation for Direct to Support Rep and SBR for the telephone, you should integrate you inbound eMail and Web based support issue submission into the same process. It is feasible with multiple vendors to route the eMail and Web queues through the same ACD type process to route the issues directly to the on duty support team with the right skill set to handle them.


Direct to Support Representative and Skill Based Routing are the best foundational techniques for driving fast resolution of customer issues and driving high customer satisfaction.

About the Author
Jim Hendrickson is the founder of Technical Support Management ( where he is building a collaborative repository of Technical Support Best Practices. Much of the content is based on his 20 plus years as a Customer Services Executive for IBM, Informix, BEA and several small start ups. He also served as the VP, Advisory Services for the SSPA (Service and Support Professional Association for a year.

2009, All Rights Reserved

Advertising | Privacy Policy | E-mail | About Us | Our Newsletter