Calculating support load
Warning: math ahead. But you can skip it, I don't mind
Following up from last week’s overview of the four major types of support coverage, let’s investigate what counts as a fully staffed support team under each model. But before we investigate the individual models in detail, let’s take time to discuss support load, since that has a strong bearing on how large a team actually needs to be. I’ve mentioned it before, but it’s important to get a clear understanding of what I actually mean by ‘support load’.
So … what is it? I’m going to give a bit of a cop-out answer: it’s a little vague. Basically, support load is ‘how busy your team is handling its assigned work’, where ‘assigned work’ includes ticket handling but also ancillary stuff like entering bugs, answering internal questions from other teams, interacting with engineering, working with Product on feature requests, and so on. In smaller organizations, Support may also be responsible for product QA/testing, documentation, training, and so on. ‘Support load’ is an abstraction of all these things into a single measure: just how busy is the support team given its current responsibilities?
Because the core task of every support team is ‘it has to handle customer issues’, let’s focus our attention on that. This simple-looking equation is the quickest way to get an understanding of how busy a team is. (If you’re allergic to math or just don’t want to get into the nitty gritty, feel free to skip to the next section, Implications.)
L = ticket load
t = tickets per day
a = average handle time (in hours) per ticket, counting only active work on the ticket
e = number of engineers
h = hours per day available for ticket handling per engineer
Intuitively speaking, L is the ratio of ticket solving capacity needed to available ticket solving capacity. If the ratio is equal to or less than 1, it means that there is sufficient capacity to handle, on average, the tickets that come in each day. If it’s more than one, then tickets aren’t going to be handled as fast as they’re coming in, and will pile up, requiring additional assistance from outside the team (or taking less time per ticket).
Straightforward enough, right? But of course the devil is in the details. Figuring out an average count of tickets per day doesn’t take long, assuming you don’t have wild swings from day to day, but it may be weeks or months before average handle time becomes apparent. And both of these measures will change over time, so they’ll need to be constantly recalculated. In case it wasn’t already clear, you’ll need to revisit this equation regularly to ensure L is reasonably accurate.
The useful thing about this equation is that it can easily be reconfigured to give you a decent ballpark figure of the number of engineers you need for a given ticket volume, once you have a good understanding of ticket complexity (here modeled with a, average handle time). Replace ticket load with 1 (to assume ‘sufficient capacity to handle what’s coming in) and you get:
To bring this down to earth, let’s look at an example. You have a team of two engineers, each of whom has six hours per day available for handling tickets. At your latest estimation, you’re getting ten tickets a day, and each one takes about an hour of active work to complete.
L is 5/6, or .83, which means that you have enough capacity (plus some spare) to handle your existing ticket load. This is good! If you had 2 more tickets per day, or if tickets took a little longer to solve on average, you’d be hovering around an L of 1, meaning your team is on the edge of being overloaded.
Implications
A few things are immediately clear when thinking about the above calculations:
There is a direct relationship between the overall ticket load and the number of engineers your team needs to have. Obvious, right? Still worth explicitly stating. You can’t have a steadily increasing ticket load with the same team size and expect things to be fine forever.
The best way to ensure the relationship between increased ticket load and increased staffing needs is as gentle as possible is to take steps to affect a, average handle time. Every decrease in average ticket handle time is directly reflected in the number of ticket work-hours required per day.
The more other things your team is doing beyond handling support tickets, the lower h (hours per day available for ticket handling) will be.
Following from the last point, the more different things your team is responsible for, the larger your team will have to be to handle the same volume of tickets. Again, this may be intuitively obvious, but important to make explicitly clear!
If L is too high, meaning your team is overloaded, there are four things you can do to lower it:
Increase e, your headcount. If you have the budget for it, this may be a good long-term solution. But it takes time to ramp up new talent, and more often than not you’re not able to make new hires at the drop of a hat.
Decrease a, average handle time. As I mentioned above, this is going to be a worthwhile thing to work on no matter your staffing level or ticket count. Improvements in handle time will assist your ticket load forever. There are innumerable ways to decrease the amount of time, on average, your engineers spend on tickets, but I’ll discuss this in more detail in a future post.
Increase h, hours per day available to handle tickets. If your team is being pulled in too many directions, it won’t have enough dedicated hours in the day to address its core role of handling customer issues. If the non-support tasks your team is doing are critical to the organization, though, this implies that either some things won’t get done or your organization will have to assign those tasks to someone else.
Decrease t, number of tickets handled. If you don’t mind dropping some tickets on the floor, or only handling tickets from certain customers, or whatever other measures you may take to decrease total ticket count, this is an option. Going back to last week, though, this is guaranteed to increase customer disappointment.
That was a long way of saying: the more tickets you have, the more you need to have the right team size to handle those incoming customer issues as well as all the other tasks your team is responsible for. Next week we’ll look at what this means for staffing levels for the four different support coverage models. Spoiler alert: it ain’t cheap to do it right. But the more we can decrease overall ticket handling time, the easier it will be to ensure your team always has capacity to handle the next ticket that comes in.
Thanks for reading Andy's Support Notes 💻💥📝!