How to Build a Headcount Business Case for Holiday Peak Support

Every September I have a version of the same conversation. A support leader knows the holidays are going to hurt. She watched last December happen. She has a team of nine, a forecast that says December will look like October times two, and an answer from finance that keeps arriving as "let's revisit next quarter."

Nothing about her situation is unusual. What is missing is not urgency. It is the document.

This is the headcount business case I build with clients before peak season: what goes in it, the math underneath it, and the two places these requests usually fall apart.

#Why a support headcount request gets declined

A headcount request arrives at finance as a number with a cost attached. Two agents, three months, some amount of money. Finance has to weigh that cost against something. When nothing is on the other side of the scale, waiting is the safe answer.

"Let's revisit next quarter" is not a judgment about you. It is what happens when a decision maker has no way to evaluate a request except by price.

There is a second reason, and it is the one nobody tells you: a lot of support headcount requests do not survive scrutiny. The math has a hole in it, a CFO finds the hole, and the whole request goes with it. Two holes come up over and over, and I will get to both.

#What goes into a headcount business case

Four parts, plus the number you are asking for.

1. What the work actually requires, in hours, by channel
2. What you have today, honestly counted
3. The gap between those two
4. What the gap is already costing you, in numbers you can prove

Then: how many people, starting what date, at what cost, with the tradeoff if the answer is partial.

Everything below builds those four parts in order.

#Step 1: Split the work before you count it

This is the first hole, and it is the one that quietly kills the most requests.

Support work splits into two categories that need different math.

Deferrable work is email, tickets, forms, async messaging, back-office tasks. The customer is not sitting there waiting. Work queues up and smooths across a shift. Staffing is a workload calculation: total minutes of work divided by minutes of available agent time.

Real-time work is phone and live chat. The customer is waiting. Arrivals are random, so you need more people than the raw workload implies just to hit a service level. That is an Erlang calculation, not a division problem.

Model a phone queue as a workload calculation and the number comes out roughly 15% to 30% low at typical volumes. The hire lands, the team still misses service level, and you have burned your credibility for the next request. Model each channel separately and add the requirements together. Never blend a phone AHT and an email AHT into one number.

Chat is the one people get wrong. Decide it by how it behaves, not by what the helpdesk calls it. A widget where the customer sits and waits for replies is real-time. SMS, WhatsApp, an in-app inbox they check later, social DMs: those are deferrable.

This matters more than it looks. At small-team volumes, live chat is usually coverage-bound rather than volume-bound: promise chat nine hours a day and you need someone in it for nine hours a day whether 40 conversations arrive or 140. That can mean three or four people serving a volume whose raw workload is under one person.

When that shows up, do not bury it. It changes the conversation from "how many people do I need" to "is a nine-hour chat commitment the right promise for this business." A leader who can say "chat costs us three heads in coverage, and here is what narrowing the hours would save" is having a much better meeting than one asking for headcount.

#Step 2: Make sure your handle time is the right clock

Before you multiply anything, check what your AHT actually measures.

Zendesk, Gorgias and Front all report several different things: agent active time, first-touch-to-resolution elapsed time, full thread duration. People quote whichever one the dashboard showed them. On an email queue, elapsed time can be twenty times agent-active time.

Then ask whether wrap is in it. After-contact work is usually 15% to 30% of the total and it is usually not in the number the report hands you.

That one question routinely moves the gap by a full person. Ask which report and which field, by name, before you build anything on top of it.

#Step 3: Build shrinkage from components, not from a benchmark

Shrinkage is every paid hour an agent is not available to handle contacts. Get this wrong and every number after it is wrong.

Do not use a blended figure you read somewhere. A CFO will ask what is in it, and "industry standard 30%" is not an answer. Build it up:

Component

Where it comes from

PTO and holidays

(PTO days + holidays) / working days, from your own policy

Sick and unplanned absence

Your HRIS

Paid breaks

Paid breaks only, unpaid lunch is already outside scheduled hours

Team meetings and 1:1s

Count the actual recurring calendar

Training and coaching

Includes QA feedback sessions

Project and non-queue work

Escalations, VOC, documentation, tooling

System downtime and admin

Sum these, do not compound them. Each one is a slice of the same paid hours and they do not overlap, so adding is correct. Compounding is for factors applied one after another to whatever time is left, which is not what these are, and it quietly understates what you need. If someone reviewing your model suggests compounding, that is the answer.

A real build usually totals between 30% and 38%. If yours comes in under 25%, something is missing and your model is understating the gap. If it is over 45%, you either have a coverage problem worth naming separately or you are double-counting against occupancy.

Then:

Scheduled hours per person per month = contracted weekly hours x 52 / 12

Net productive hours = scheduled hours x (1 - shrinkage)

At a 40-hour week that is 173.33 scheduled hours a month. Use your actual contracted hours. A 37.5-hour week changes the answer.

#Step 4: Apply an occupancy cap, but only to deferrable work

Occupancy is the share of available time an agent spends actively handling work. Schedule to 100% and there is no recovery time between contacts, which produces errors, then rework, then people leaving. Cap deferrable channels at 80% to 85%.

Effective handling hours per person = net productive hours x target occupancy

Required people (deferrable) = monthly workload hours / effective handling hours

Do not apply an occupancy cap to phone or live chat. Erlang already produces the idle time you need to hold service level. Applying both double-counts and inflates the request, which is exactly the kind of padding a CFO looks for.

For real-time channels, run the calculation on your busiest representative interval rather than a monthly average. Monthly averages hide the peak, which is the whole point of the exercise. Then gross the result up for shrinkage, because agents seated at that moment and people you employ are two different numbers.

#Step 5: Count what you actually have, not what the org chart says

Current productive capacity is not your headcount. Subtract:

• Open roles you are counting as staffed
• Anyone on extended leave
• Anyone split across another function

And add one thing back: the share of your own time, or a team lead's, spent in the queue. Count it. It is real capacity, and naming it sets up the strongest argument you have, which I will come back to.

Gap = total required people (all channels) minus current productive people

Round the final number up. A gap of 2.7 is a request for three, with the 2.7 shown so nobody thinks you padded it. You cannot hire 0.7 of a person, and rounding down is how you end up back in this meeting in six months.

Here is what that looks like end to end. These are illustrative numbers, not a client result:

Email and tickets. 3,800 contacts a month at 11 minutes AHT including wrap, so 697 workload hours. Shrinkage builds to 36%, so net productive hours are 111 a month per person. At 85% occupancy that is 94 effective handling hours each. 697 / 94 = 7.4 people.

Phone. Answering 80% of calls in 30 seconds at the busiest interval needs 3 agents seated. Grossed up for 36% shrinkage, that is 4.7 people employed to keep 3 seated.

Total required: 12.1 people.

What we have. Eleven on the org chart, minus one unfilled role, minus one on extended leave, plus 0.4 of a team lead who is in the queue every afternoon. 9.4 people.

Gap: 2.7. Ask for three.

Notice the gap is 29% of current headcount. If yours comes out above 50%, an input is wrong. Usually AHT is in seconds and being treated as minutes, or volume is annual and being treated as monthly. Check before you send it.

#Step 6: Prove what the gap already costs

This is the part almost everyone skips, and it is the part that gets the request approved. The hire is not a new cost. It is a cheaper substitute for costs you are already paying.

Build only from what you can evidence:

• Overtime. Actual hours from payroll, at loaded rate, times 1.5. If you are running OT to cover the gap, this is the cleanest number you have and it often covers a meaningful share of a hire by itself.
• Contractor, BPO or agency spend used to plug the gap. Invoiced amounts. Compare the effective hourly rate to your loaded internal rate. It is usually higher.
• Your own time in the queue. Hours a week you or a team lead spend handling contacts, at your loaded rate, times 52. This one is always bigger than people expect, it is easy to pull from a Zendesk assignment report, and it reframes everything: the company is paying a manager's rate for agent work and getting no management in return.
• Customers contacting twice. When first response slips, people follow up. Your repeat contact rate is measurable. Use your own rate from a period when you were meeting SLA as the target, and the difference is avoidable volume you are paying to handle.
• Backlog carrying cost. A growing queue is deferred labor you will eventually pay for. Quantify it in hours (backlog x AHT), keep it separate from the annual run rate, and present it as a one-time liability rather than a recurring cost.
• Turnover caused by workload. Build the cost per departure explicitly: recruiting, interviewer hours, training at zero output, ramp loss, and coverage during the vacancy. For a support role that usually lands between 40% and 75% of annual loaded salary. Do not use "1.5x salary" as a shortcut.

And here is what to leave out, which matters just as much: attribute turnover to workload only if you have evidence, meaning exit interview themes, a rate above your own historical baseline, or engagement survey data. Cost of a lost customer, CLV, churn value: leave them out entirely unless finance hands you their own figure with their own source.

A CFO will find one unsupported number, and finding it lets them dismiss the entire model. Four zeros with a note saying "I cannot prove this yet" is a stronger document than four estimates.

#Step 7: Model the ramp, or year one will not survive contact with reality

A new hire does not deliver full capacity on day one. Model it as a curve against your actual training program: nothing during the first two weeks, 40% through nesting, 70% to week eight, 90% to week twelve, full from week thirteen.

This makes hire timing an argument in itself. A person starting in October contributes far more this year than the same person starting in December, and showing that side by side is often what gets the full request approved now rather than split across two budget years.

Apply the curve to the benefit as well as the cost. Count full savings from month one and the model breaks the first time anyone checks.

#Step 8: Bring four scenarios, not one number

A single number invites a yes or no. Four scenarios invite a decision.

• Do nothing. Current-state cost carried forward twelve months, with the backlog trajectory if the queue is growing. This is the comparison every other number is measured against, and it is the scenario headcount requests almost always omit.
• Partial hire. Roughly half the gap, or whatever you think is politically achievable. Show the residual gap and the residual cost. The point is to make the tradeoff visible, not to argue against it.
• Full gap, hired now. The mathematically correct answer.
• Phased. The full number split into tranches, each with a date and a trigger tied to a metric you already report. "Hire tranche two when 30-day rolling volume exceeds X." A phased plan with metric triggers is much easier to approve than a lump request, because it turns a bet into a decision rule.

If AI deflection is in the conversation, model it as a reduction in volume applied only to the contact types that are genuinely automatable, at a rate you can evidence from your own pilot. Then be honest about two things. Deflection reduces the gap, it rarely closes it, because the contacts that deflect are the easy ones and your remaining AHT goes up. And deflection has a lead time. A gap that exists in December is not solved by a project that lands in Q2.

#Step 9: Report both years of ROI

Annual benefit = costs that actually stop, plus capacity returned (leader hours, backlog cleared)

Annual cost = fully loaded cost x portion of the year employed

Payback = the first month cumulative net benefit turns positive

One rule keeps this honest: count a benefit only where a cost actually stops. If you are not paying overtime today, there is no overtime saving.

Report year one and steady state. Year one is dragged down by ramp and onboarding, steady state is the honest ongoing picture, and showing both heads off the objection that you picked the flattering window.

If year-one ROI is negative, lead with it. Sometimes the hire pays back in month 14, and the leader who says that plainly gets approved more often than the one who massages it to month 11.

#The check that catches a broken model

Before this goes anywhere, run one test on yourself.

Your inputs make a prediction. If volume times handle time really exceeds your capacity by the amount you are claiming, your backlog would have grown to a specific size by now. Calculate that size. Then look at your actual backlog.

When the actual number is a fraction of the predicted one, your team is absorbing work your model says is impossible, and one of your inputs is wrong. This is the second hole, and it is the one that turns a good business case into an embarrassing meeting, because the gap looks enormous right up until someone asks "so how are they coping today?"

Three causes, in order of likelihood:

1. Handle time is the wrong clock. Back to Step 2.
2. Your volume counts messages, not contacts. A four-message thread is one ticket handled once. Helpdesk exports often count inbound messages.
3. More people are in the queue than you counted. Part-timers, team leads, another team, the founder's inbox, a vendor nobody mentioned.

Find it before your CFO does.

#The headcount business case in six lines

• Split the work by channel, and never model a phone queue like an email queue.
• Confirm what your AHT is actually measuring, including wrap.
• Build shrinkage from components and sum them.
• Cap occupancy on deferrable work only.
• Count what you really have, then round the gap up.
• Prove what the gap costs using only numbers you can evidence, and leave the rest at zero.

The hiring runway closes before the season does. Count backwards from your peak week: ramped by December 1st means starting mid-November, which means an offer out in October, which means the budget conversation is finished in September, not started in it.

If you want a second set of eyes on your numbers before they go to finance, that is what our Headcount Business Case engagement is. I build the model in Excel with every formula live so your CFO can test their own assumptions, run the reconciliation check, and hand you the document you take into the meeting.