One of the most common questions I hear from IT support managers is “How many techs should I have in desktop support?” It’s a great question, but one that is rarely answered adequately. The result is that many desktop support organizations are not staffed properly because they do not follow any sort of proven methodology when making headcount decisions. Instead, they rely on “gut feel” or “instinct” when it comes to staffing desktop support. Compounding this situation is the fact that many desktop support groups do not follow a strict SPOC (Single Point of Contact) support model, and end up handling large numbers of incidents that could and should be resolved by the service desk. It’s no wonder then that many desktop support groups are overstaffed, and hence very costly.
In this blog, MetricNet defines a rigorous methodology for determining the appropriate technician headcount for desktop support. Following the approach outlined in this article, desktop support organizations can be assured that they will be staffed to meet the needs and expectations of their customers, while simultaneously delivering services in an efficient, fiscally responsible manner.
The Staffing Fallacy in Desktop Support
A common misperception in desktop support is that the user population alone will define the number of technicians needed. This approach wrongly assumes that the ratio of desktop support technicians to the number of users supported is fixed. For example, 12.5 desktop support technicians are needed for every 1,000 users. The error in this approach is that no two user populations have the same needs, and therefore no two user populations generate the same workload. As such, staffing decisions in desktop support should be based upon workload, not user population.
Consider the example of a financial services company with a corporate staff of 2,500. The device count for this user population is as follows:
• 2,100 desktop computers
• 950 laptop computers
• 140 printers and copy machines
• 1,100 smart phones
• 240 servers
The number of desktop support techs required to support this workload turns out to be about 24. (The derivation of this number will be shown later in this blog.)
Now take the example of an electric utility with the same number of users: 2,500. The device count for this population is as follows:
• 2200 desktop computers
• 550 laptop computers
• 80 printers and copy machines
• 300 smart phones
• 70 servers
The number of desktop technicians required to support this workload turns out to be about 8. (The derivation of this number will also be shown later in this blog.)
Despite the fact that the user populations in our examples are exactly the same, the two user groups generate very different workloads, and hence require different staffing levels in desktop support. The workload for desktop support is driven not only by the number of users or “seats supported”, but also by the number and mix of devices, the age of devices, the service level targets of the organization, the population density of the users, the level of standardization and virtualization in the IT environment, and a myriad of other factors. The key point here is this: the technician staffing requirements of a desktop support organization should be based upon the workload generated by the user population – incident and service request volume – not the number of users being supported. With this in mind, it is easy to understand why two organizations with exactly the same headcount may require very different staffing levels in desktop support.
Tickets, Incidents, and Service Requests
Before we go any further, it is worth defining a few terms. Specifically, we need to define the terms Ticket, Incident, and Service Request as they relate to Desktop Support.
An Incident is typically unplanned work that requires the assistance of an on-site technician to resolve. Common examples include a desktop or laptop computer break/fix, a printer or server failure, connectivity problems, or any other issue that cannot be resolved remotely by the Level 1 Service Desk. By contrast, most Service Requests represent planned work. Among the most common Service Requests are Move’s/Add’s/Change’s, hardware refresh/replacement, and device upgrades. Tickets represent the sum of all Incidents and Service Requests.
Desktop Staffing Fundamentals
Since staffing is based on workload, it makes sense to first define what we mean by workload. Workload is the sum of all incidents and service requests multiplied by their respective handle times:
Monthly Workload = (Incident Volume per Month X Incident Handle Time) + (Service Request Volume per Month X Service Request Handle Time)
Handle time includes both work time and travel time, where travel time is the average round-trip time it takes the technician to get to and from the site of an incident or service request (more on this later).
Let’s do the Workload calculation for the financial services example from above. The 2,500 employees at the corporate headquarters generate an average of 1,750 incidents, and 800 service requests per month. The average travel time to and from the site of an incident or service request is about 25 minutes. This is considered a medium density user environment, consistent with a corporate campus containing multiple office buildings. Additionally, the average work time for an incident is 18 minutes, while the average work time for a service request is 51 minutes. With this data we can calculate the Incident and Service Request handle time as follows:
Incident Handle Time = 25 minutes travel time + 18 minutes work time = 43 minutes Service Request Handle Time = 25 minutes travel time + 51 minutes work time = 76 minutes
And we can now calculate the workload using the formula from above:
Workload = (1,750 incidents/month X 43 minutes handle time per incident) + (800 service requests/month X 76 minutes handle time per service request) = 136,050 workload minutes per month
Now that we have the desktop workload for our financial services company, we can determine the technician headcount if we know how many minutes the average technician works in a month. Using data from MetricNet’s worldwide Desktop Support Benchmarking Database, it turns out that the average desktop support technician logs about 5,800 work minutes per month. That is, if we add up all of the incidents and service requests handled by a desktop support technician in a month, and multiply that by the incident and service request handle time, it amounts to an average of 5,800 work minutes per technician per month. This number is called Technician Capacity, and equates to a Technician Utilization of 60%, the approximate industry average for Technician Utilization. This figure is net of all vacation days, sick days, training time, admin time, and other “non working” time. For a more detailed discussion of Technician Utilization, please refer to MetricNet’s whitepaper on Desktop Support KPI’s which discusses this metric.
We can now calculate our desktop technician headcount requirements as follows:
Technician Headcount = Workload ÷ Technician Capacity Technician Headcount = 136,050 workload minutes per month ÷ 5,800 technician minutes per month = 23.5 technicians.
So to properly staff the financial services desktop support function, we would need about 24 technicians.
How does this same methodology play out for the electric utility? The 2,500 employees at the utility headquarters generate an average of 900 incidents, and 500 service requests per month. The average travel time to and from the site of an incident or service request is about 12 minutes. This is considered a high density user environment, consistent with a high rise office building. Additionally, the average work time for an incident is 14 minutes, while the average work time for a service request is 33 minutes. With this data we can calculate the Incident and Service Request handle time as follows:
Incident Handle Time = 12 minutes travel time + 14 minutes work time = 26 minutes Service Request Handle Time = 12 minutes travel time + 33 minutes work time = 45 minutes
And we can now calculate the workload using the formula from above: Workload = (900 incidents/month X 26 minutes handle time per incident) + (500 service requests/month X 45 minutes handle time per service request) = 45,900 workload minutes per month
Finally, using a technician capacity of 5,800 work minutes per month, we can calculate our headcount requirements as follows:
Technician Headcount = Workload ÷ Technician Capacity Technician Headcount = 45,900 workload minutes per month ÷ 5,800 technician minutes per month = 7.9 technicians.
We would need about 8 technicians to properly staff the desktop support function of the electric utility.
These two examples clearly illustrate the importance of basing headcount decisions on workload, rather than the size of the customer population. In the case of the financial services company, we have 24 technicians supporting 2,500 users. This is one technician for every 104 users. By contrast, we have 8 technicians supporting 2,500 users in the electric utility. This is one technician for every 313 users. The wide variation in headcount requirements is driven by the wide range of workload requirements from company to company, and from industry to industry. This, in turn, is a function of travel time, and the number of tickets generated by the user population. Travel time can range from just a few minutes is some high density user environments (think high rise office building), to as much as two hours or more in a low density user environment (multiple buildings spread out over several hundred square miles, for example).
The number of tickets generated, as mentioned previously, is driven by numerous factors including the mix of laptop and desktop computers, the number of remote users, the number of mobile devices, the refresh rate of devices, the standardization (or lack thereof) of the IT environment, and the degree of virtualization.
Metrics Needed for Staffing Decisions
In MetricNet’s article on Desktop Support KPI’s, MetricNet noted that most desktop support organizations do not have a well developed set of metrics for tracking and trending their performance. However, the headcount methodology outlined above relies upon the following metrics:
• Monthly Incident Volume
• Monthly Service Request Volume
• Average Work Time per Incident
• Average Work Time per Service Request
• Average Travel Time per Ticket
While most desktop support organizations track incident and service request volume, fewer than 20 percent track their work time or travel time. This presents a dilemma, but one that can be easily overcome. The simplest and most straightforward solution I have seen is when an entry for Work Time and Travel Time are added to the trouble ticket. When a technician closes out a ticket, he or she will estimate the work and travel time for that particular ticket, and enter those values into the appropriate fields on the ticket. The work and travel time for incidents and service requests can then be totaled up and averaged each month to develop a pretty good estimate for these numbers. These metrics, in turn, enable the calculations illustrated above to determine technician headcount.
Some organizations have been known to engage in time and motion studies whereby the technicians in desktop support will carry stopwatches with them for a certain period of time, say a week. During this time, each technician uses their stopwatch to record the precise work time and travel time for every ticket they handle. At the end of the measurement period, incident work time, service request work time, and travel time are totaled up and averaged for all technicians in desktop support. These values are then used to make or validate staffing decisions, calculate technician utilization, and update the desktop support balanced scorecard. For a detailed treatment of Technician Utilization and the Balanced Scorecard, please see the aforementioned article on Desktop Support KPI’s. Finally, the time and motion study is normally repeated once or twice annually to ensure that the values for work and travel time keep pace with the changing IT environment.
Finally, larger and more sophisticated desktop support organizations will sometimes equip their technicians with handheld devices that can be placed in various modes such as work, travel, admin, training, standby, phone support, etc. that keep track of individual work and travel time for both incidents and service requests. This, of course, makes the task of tracking these metrics much simpler and more accurate.
Optimizing Technician Headcount
Our discussion thus far has focused on a methodology that bases technician headcount on desktop support workload. But there is a second, critical factor that must be taken into account when staffing a desktop support organization. Specifically, when a desktop support organization does not follow a strict SPOC support model, they often handle a large number of incidents that should be resolved by the Level 1 Service Desk. This creates inefficiencies in the support model, and drives up the cost of support.
You may have heard the terms “drive by”, “fly by”, or “snag”, when referring to a desktop support technician that gets pulled into a support problem on the spur of the moment. This might happen, for example, when a technician is returning to their desk after completing a service request, and is “snagged” by a user who needs support for a particular issue – right then and there. These rogue requests happen in every organization, and there is a great temptation for technicians to provide support when asked, even if it means violating the SPOC support protocol. This effect, sometimes called bypass (because it bypasses the SPOC process), can actually be measured with a metric called % Resolved Level 1 Capable, which, as the name implies, measures the number of tickets resolved by desktop support that could have been resolved by the service desk.
Globally, the % Resolved Level 1 Capable, averages 21%. That is, 21% of all tickets resolved by desktop support had the potential to be resolved by the Level 1 service desk. Some of these tickets are unnecessarily escalated by Level 1 to desktop support, while others are the result of bypass, as described above. Either way, they represent defects in the support delivery model, and add significantly to the cost of support.
In North America last year the average fully loaded cost of resolving a ticket at Level 1 was about $21, while the average fully loaded cost of resolving a ticket at desktop support was about $63. For a desktop support organization handing 2,500 tickets per month, 21% Level 1 capable equates to 525 tickets that should have been resolved at Level 1: 21% Level 1 Capable X 2,500 Tickets = 525 Tickets. The average cost of these defects can be calculated as follows: 525 tickets X ($63 per desktop ticket - $21 per service desk ticket) = $22,050. That’s $22,050 in unnecessary support costs each month, or $264,600 per year!
The implication is that the measured workload for desktop support can be inflated by tickets that should be resolved at level 1. When this happens, the desktop support organization may appear to be staffed properly, when in fact they are overstaffed because they are handling a large number of escalated and bypass tickets that should have been resolved at level 1. As shown above, this level 1 “subsidy” can be very costly. The solution to this problem is to track this metric – % Resolved Level 1 Capable – and make every effort to minimize ticket defects by enforcing a strict SPOC support model, and by providing the training and tools necessary at level 1 to minimize the number of tickets that are unnecessarily escalated to desktop support.
Conclusion
Most Desktop Support organizations lack a rigorous methodology for determining technician staffing levels. Additionally, many do not follow a strict SPOC support model. These factors often result in staffing levels that are far from optimal, and can saddle a support organization with high costs. In this article we have presented a straightforward methodology for determining the appropriate technician headcount for desktop support. Additionally, we have recommended tracking a handful of metrics, including % Resolved Level 1 Capable, that can help to ensure that your desktop support function is staffed efficiently. Finally, we have shown that following a strict SPOC support model is crucial to achieving optimal staffing levels in desktop support.
MetricNet conducts Desktop Support Benchmarks for organizations worldwide. For more information, please visit our benchmarking store, or contact MetricNet. You can register for MetricNet's free webcast on Desktop Support Best Practices by visiting our webcast page.
