The Headcount Case: Capacity Arithmetic in Hours
Thursday, 17:40, at Bellweather Logistics. Nadia has the month-end report open on one screen and a blank document called "third technician" on the other. The document has been blank for a week. She knows the desk needs another person. Both technicians know it. Owen, the operations director, half knows it. That is because he has walked past the desk at six in the evening three times this month and found both of them still there. What Nadia does not have is the sentence that turns "we need another person" into something Owen can take to the finance meeting and defend without her in the room. She has been told the sentence is a spreadsheet. She has never been told which spreadsheet.
The headcount case is the argument for one more person on the desk, built from the desk's own tickets. It has to prove three things in order. First, the gap between the work arriving and the hours available is real. Second, it is persistent rather than a bad month. Third, a person is the right-sized fix for it rather than a tool or a protected week. The first two come from the evidence set described in Evidence Over Anecdote. This article assumes you have read it and have six months of the evidence list filled in. This article is part of our Using Ticket Data to Justify Resources series. It is about the third thing: the arithmetic of what one more person changes, and how to write it on one page.
It covers what the case has to prove. Next come hours available, counted honestly, and hours needed, from volume and the median. Then come the gap month by month, with a picture, and where the gap went. Next are what one more person changes, and the sizes of ask and how to choose between them. Finally come the one page itself; the mistakes that lose the case; a short war story; and the headcount case one-pager to copy, in that order.
What the Headcount Case Has to Prove
The case has to prove a gap, a trend, and a fit. The gap is the capacity sum for one month: hours the tickets needed, less hours the desk had. The trend is the same sum over six months, showing the gap is the ordinary state of the desk and not the month the warehouse system was replaced. The fit is the part most cases skip: a demonstration that the size of the gap matches the size of one person. The aim is to avoid leaving the reader wondering whether a different tool or a week of fixing would have done the same job for less. A case that proves the first two and skips the third gets the answer "have you considered automating it?" That question is the subject of Anticipating the Pushback and is far easier to answer before it is asked.
Everything is in hours. The case never contains a salary, a rate or a cost. That is because hours are what the desk can prove from its tickets and money is what finance can attach to them in about a minute. A desk that puts a salary in its own document has moved the argument onto ground where finance is the expert and the desk is guessing. Keep the argument on the ground where the desk is the expert, which is how long the work takes.
Hours Available, Counted Honestly
Hours available are the hours in a month a technician can actually spend on tickets. The honest figure is far below the number of hours they are paid for. Start from the nominal month, the working days times the contracted hours. Then take off annual leave taken that month, sick days, public holidays, training, the standing meetings, and the projects the desk has been given. Do this line by line and from the real calendar rather than a guess. Also take off the daily administration that is nobody's ticket: the morning check of the mail queue, the weekly report, the walk to the server room. What is left is the number that goes in the sum.
At Bellweather the nominal month was about a hundred and fifty-eight hours for each of the two technicians. Leave averaged across the year took off about fourteen, meetings and training about ten, and the two projects the desk had been handed took about twelve. The daily administration, timed for a fortnight with a notebook, came to about five. That left roughly a hundred and seventeen hours of ticket time each in an ordinary month. That was about two hundred and thirty-five for the pair, and about a hundred and eighty-three in the month one of them took two weeks' leave. The figure looks low to anyone who has not done the deduction, and the first reviewer will say so. Show the lines. Nobody in the history of support has had a hundred and sixty hours of ticket time in a month. The people who claim to are not logging their meetings.
These are capacity figures, not performance figures, and the case should say so if there is any risk of confusion. The sum needs to know how many hours the desk had, not how many tickets each technician closed. It never compares one technician's output with another's. If a reviewer asks for per-person output, the answer is that such a figure is for coaching rather than ranking. It needs a minimum of a few hundred tickets per person before it means anything. It has no place in a headcount case, where the argument is about the desk as a whole.
Hours Needed, From Volume and the Median
Hours needed are tickets opened in the month times the median hands-on time of one ticket, both measured as the evidence article describes. Volume is counted the same way every month with walk-ups logged. The median comes from a random sample of closed tickets with its date and size written down. At Bellweather the volume ran between three hundred and eighty-five and four hundred and twenty-one tickets a month over the six months. The sampled median was thirty-nine minutes, which Nadia rounded to 0.65 of an hour. Hours needed therefore ran from about two hundred and fifty to about two hundred and seventy-four, rising gently as the organisation took on a second depot.
Check whether the ticket mix is shifting, because a stable median hides a changing desk. If the proportion of long tickets is growing, say because a new system generates more complex requests, the median sampled a year ago understates the current need. The cheapest check is to sample again from the most recent month and compare. The rules for seeing a trend in volume, as opposed to a seasonal wobble, are in Trends and Seasonality. A headcount case that has read them will not be caught out by a reviewer who asks whether the summer is always like this.
Most help desk tools report volume and backlog by age as standard, QuerySolv among them. So the month-end counts are a report rather than a tally by hand. The median is the only input that needs a technician's afternoon, and it needs it about once a year. Write the sampled figure and its date on the one-pager, because a reviewer who can see where every input came from has very little left to argue with except the conclusion.
The Gap, Month by Month
The gap is hours needed less hours available, for each month. The case shows all six side by side rather than an average, because the shape matters as much as the size. A gap that is small in ordinary months and large in the leave month tells the reader the desk has no slack. That is a different problem from a gap that is large every month, and it points at a different size of fix. The picture below is Bellweather's six months. Each month has a green bar for the hours available and a cream bar for the hours the tickets needed. The part of the cream bar that rises above the green is shaded orange as the gap. The side panel says where the gap went, which is the next section.
Read the picture as the reviewer will. The gap in an ordinary month is fifteen to forty hours and it is growing, slowly, as the volume grows. The leave month gap is eighty-five hours, because the desk lost a quarter of its capacity for two weeks and the tickets did not know. Across six months the gap adds up to two hundred and eighteen hours. That is a number the reader can hold in one hand: a working month and a half of technician time that the tickets needed and the desk did not have. The gap is never negative. A desk that has no slack in its best month has nowhere to put its worst one. This desk has had six worst ones in a row.
Where the Gap Went
The gap always goes somewhere, and the case is stronger for saying where. A reviewer who cannot see where two hundred hours went will suspect they did not exist. There are three places: the backlog, the technicians' evenings, and the quality of the work. At Bellweather the backlog grew by about a hundred and eighty tickets over the six months, which at 0.65 hours each is roughly a hundred and twenty hours. The technicians' own count of late evenings, cross-checked against the times on their replies after six o'clock, came to about sixty hours. The remaining forty or so hours had gone into shortcuts: fixes applied without the usual test, closing notes not written, the second check skipped.
The shortcuts are the hardest to count and the most important to mention, because they are the part of the gap the organisation is already paying for without knowing it. The reopen rate, the proportion of resolved tickets a requester reopens because the fix did not hold, is the nearest thing to a direct measure. At Bellweather it had drifted upward over the six months, and each reopen is a ticket's worth of work done twice. How to measure reopens without flattering or damning the desk is in Measuring Reopens Honestly. Nadia presented the shortcut hours as an estimate, in a range, and labelled it as such. An honest estimate marked as an estimate is believed. A precise figure for something nobody could have measured precisely is not.
The three destinations also tell the reader what will happen if nothing is done, without the desk having to make a threat. The backlog will keep growing at the current slope. The evenings will continue until somebody stops doing them, which in my experience they do by resigning rather than by announcing it. The shortcuts will keep converting into reopened tickets and, eventually, into the one skipped check that matters. None of that needs to be said dramatically. The picture says it, and the picture is just arithmetic.
Remember: the headcount case is hours needed against hours available, for six months, with the gap shown month by month and its destinations named. It contains no salary. It proposes an ask the same size as the gap, names the alternatives it considered, and says what will be reported back and when.
What One More Person Changes
One more technician at Bellweather adds about a hundred and fifteen hours of ticket time in an ordinary month, after the same deductions as the other two. That takes the available hours from about two hundred and thirty-five to about three hundred and fifty against a need of around two hundred and seventy-five. The gap becomes a surplus of roughly seventy-five hours a month. That surplus clears the hundred and twenty hours of backlog in about two months. After that, the desk has the slack it has not had for a year. And the leave month, with three people instead of two, still has about two hundred and ninety-five hours against two hundred and seventy-five needed. The desk stops losing a quarter of its capacity every time one person goes on holiday, which is the change the technicians will notice first.
Be honest about the ramp. A new technician is not a hundred and fifteen hours of useful ticket time in their first month. They are perhaps half that in the first quarter, while they learn the systems and the people. The existing technicians lose some hours to teaching them. Put the ramp in the case as the desk's own estimate: half capacity for three months, then full. It delays the backlog clearance by a quarter and it makes the case more believable, not less. Every manager who has hired anyone knows the first quarter is an investment and will distrust a case that pretends otherwise.
Then say what the surplus is for, because seventy-five spare hours a month is a figure a reviewer will want to cut. Some of it is the slack a desk needs to absorb a bad week without the backlog restarting. Some of it is the time to do the fixes that remove tickets at the source, which a desk at full stretch can never start. A case that names what the surplus buys has answered the cut before it is proposed. A case that leaves it as a number invites the reviewer to propose a half-time person, which brings us to sizing.
The Sizes of Ask
The ask should be the size of the gap, and there are more sizes than "one more person". A full-time technician adds a whole person's hours and is right when the gap is most of a person, or when the leave-month problem is itself the main cost. A part-time technician adds half those hours and is right when the ordinary gap is small but persistent. At Bellweather, fifty-five extra hours would roughly close the ordinary gap but would not clear the backlog or cover the leave month. Fixed-term cover for the leave months plus a one-off, planned backlog dig is right when the ordinary months are fine and only the leave months hurt. And when the gap is small and a slice of the volume comes from one fixable cause, the right ask is not a person at all but a protected week. That has its own case later in this series.
| What the six months show | Right-sized ask | Why not the others |
|---|---|---|
| Gap under a day a month in ordinary months, none in leave months | No headcount; stop or defer one non-ticket task | A person would sit idle; a tool solves a different problem |
| Small ordinary gap, but a clear slice of volume from one cause | A protected week for the fix | Headcount treats the symptom; the fix removes the tickets |
| Ordinary months roughly balanced; leave months badly under | Fixed-term cover for leave months and a one-off backlog dig | A permanent hire is more than the gap; part-time does not land when needed |
| Persistent gap of a quarter to half a person, every month | A part-time technician | A full-time hire leaves a surplus the case cannot justify |
| Persistent gap of half a person or more, worse in leave months | A full-time technician | Cover and part-time leave the ordinary gap and the no-slack problem in place |
| Gap of more than one person | One now, with the sum rerun after the ramp | Asking for two on one sum is read as a round number, and refused as one |
Name the alternatives in the case even when you are asking for the full-time person, and say in a sentence why each fits the gap less well. This is not a concession. It is the fit proof, the third of the three things the case has to show. A reader may see that the desk considered a half-time person and a protected week and can say why neither closes an eighty-five-hour leave month. In that case, the reader has very little left to propose. The alternatives the desk does not mention are the ones the reviewer will.
Writing the Ask on One Page
The case is one page, and the page has six parts in a fixed order. It starts with the gap in one paragraph, then the six months as a small table or the picture above. Next come where the gap went and what one more person changes including the ramp. Then come the alternatives considered and why they fit less well. Last is the ask itself with a date and a promise of what will be reported back. The evidence list and the sample sit behind it as an appendix for the reader who wants to check, and some will. The one page is the case; the appendix is the proof; nobody has ever been persuaded by page four.
The format for a page that senior readers actually read, including which numbers to show and which to keep ready, belongs to The Monthly Report They Will Actually Read and the rest of its series. The headcount case follows that format rather than inventing one. Two habits from it matter most here. Lead with the conclusion, "the desk needs about a hundred and fifteen more hours of ticket time a month and here is why". That way, the reader knows what they are being asked before they read the arithmetic. And put the date the data was taken on the page, because a case will be read by someone two months later, and they should know which two months.
The last line of the page is the promise to report back: the same six numbers, three months and six months after the decision, whichever way it goes. The promise costs nothing. It tells the reader the desk expects to be held to its own arithmetic. It is the single thing that makes the next ask easier. What to put in that report, and how to handle the ask that was refused, is the subject of After the Decision.
Mistakes That Lose the Headcount Case
Most lost headcount cases are lost on one of a short list of errors, each of which hands the reviewer a reason to stop reading. The list below is the one I check a case against before it leaves the desk. Every item on it is a case I have seen lose, and two of them are cases I lost myself.
- Using elapsed time from open to close instead of hands-on time, so every ticket looks like a week of work.
- Counting the full paid month as hours available, with no deduction for leave, meetings or projects.
- Putting the loaded figure on the needed side, so the meetings are counted in both columns.
- Building the case on the single busiest month rather than six.
- Writing a salary or a cost into the desk's own document.
- Comparing the desk's volume or staffing with another organisation's.
- Asking for two people on a sum that supports one, or for one on a sum that supports a protected week.
- Leaving the gap's destinations unnamed, so two hundred hours appear to have vanished.
- Omitting the alternatives considered, which invites the reviewer to propose them.
- Forgetting the ramp, so the first quarter's figures contradict the case.
A Short War Story: The Round Number at Redbrook Engineering
At Redbrook Engineering, a desk lead called Tom asked the board for two additional technicians, on the grounds that the three-person desk "needed to double" to cope with a new plant. He supported it with a single month's ticket count and a description of the team's hours. The board declined it as unrealistic, and the desk was told to manage. Six months later Tom asked again, this time with six months of the capacity sum. It showed a persistent gap of about ninety hours a month. He asked for one person, with the ramp and the alternatives on the page. It was approved without discussion. The six months between the two asks had added roughly two hundred and fifty tickets to the backlog. Those months cost the three technicians several hundred hours of unpaid evenings between them. The interval produced two reopened tickets at the new plant that stopped a production line for an afternoon each. The sum had supported one person all along. The round number had been refused, and the real number had never been offered.
The Headcount Case One-Pager
The template below is the one page, with the evidence list from the previous article as its appendix. Sections one to three come straight off the six filled-in evidence sheets. Section four is the arithmetic of this article. Section five is the fit proof, and it is not optional: a one-pager without it is a request, not a case. Section six is the ask and the promise. Keep it to the page, and if it will not fit, the usual culprit is section three, which wants to be a paragraph and not a story.
THE HEADCOUNT CASE — ONE PAGE
Desk: ______________ Prepared by: ______________ Data as at: ____________
Ask in one line: ____________________________________________________________
1. THE GAP THIS MONTH
Tickets opened ____ times median hands-on time ____ h = hours needed ____ h
Technicians ____ times ticket hours each ____ h, less leave/meetings/projects ____ h
= hours available ____ h
Gap (needed minus available) ...................................... ____ h
2. THE LAST SIX MONTHS
Month 1 2 3 4 5 6
Needed ____ ____ ____ ____ ____ ____
Available ____ ____ ____ ____ ____ ____
Gap ____ ____ ____ ____ ____ ____ Total gap ____ h
Months with a negative gap (slack): ____
3. WHERE THE GAP WENT
Backlog growth ____ tickets, about ____ h
Evenings and weekends, from the technicians' count, about ____ h
Shortcuts (reopen rate from ____ to ____), estimated ____ to ____ h
Oldest ticket waiting for hours, not for anyone: #______, ____ days: ______________
4. WHAT ONE MORE PERSON CHANGES
Extra ticket hours per ordinary month, after the same deductions .... ____ h
New available ____ h against needed ____ h = surplus ____ h a month
Ramp: about half capacity for the first ____ months
Backlog cleared in about ____ months after the ramp
Leave month with the extra person: available ____ h against needed ____ h
The surplus is for: ______________________________________________
5. ALTERNATIVES CONSIDERED
Part-time (about ____ h a month): closes the ordinary gap? yes / no Leave month? yes / no
Fixed-term cover plus a one-off backlog dig: fits because / does not fit because ____________
A protected week to remove a source of tickets: would remove about ____ tickets a month; enough? yes / no
A tooling change: the rework it would remove is about ____ h a month; enough? yes / no
6. THE ASK AND THE PROMISE
Ask: ______________________________ by: ____________
Reported back: the same six numbers at three months and six months, to ______________
Appendix: six monthly evidence lists, the hands-on sample (____ tickets, dated ________)
Nadia's one-pager went to Owen on the Monday with the picture in section two and the sample list stapled behind it. He asked two questions. Was the hundred and seventeen hours really all the ticket time a technician had? What would the seventy-five spare hours be spent on? The page already answered both, and he took it to the finance meeting without her. The third technician started eleven weeks later. The blank document had been blank because Nadia had been trying to write a persuasive argument. What Owen needed was a sum he could carry.
Frequently Asked Questions
How do I count hours available when leave varies so much month to month?
Our volume is growing. Should the case be built on today's volume or next year's?
What if the gap is real but smaller than half a person?
Should I include the hours the new person will free up for projects?
The reviewer wants per-technician productivity figures. Do I provide them?
How long should the six months be before I present the case?
From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.
