Headcount Business Case

Headcount business case

Produces a one to two page document that argues a hiring request in the language of the person approving it — cost, capacity, risk, and what happens if we do nothing — rather than the language of the person making it, which is almost always workload.

Reqs rarely get rejected because the need is fake. They get rejected because the case was written as "the team is stretched", which a CFO hears as a feeling, and because it never answered the four questions they were always going to ask: can this wait, can we do it cheaper, what breaks if we say no, and why does it have to be permanent.

What you need to start

Two things:

1. The role — title, level, team, and when it is needed.
2. The specific outcome that is not happening today without it. Not "we're busy".

Something that has a name: a launch date slipping, a backlog that is growing, a customer commitment at risk, a service level being missed, a hiring plan that cannot be delivered.

That is enough to draft. Everything else — salary, on-costs, evidence, comparator options — can be filled in as you go or marked as a placeholder.

Do not stall. If the user has no cost figures, no baseline data, and only a strong instinct that the team needs a person, build the entire case anyway on clearly-labelled placeholders and assumptions, then close with the short list of exactly which numbers to get and who owns them. A structured case with five bracketed gaps is immediately useful — the user can walk it into their finance business partner and have it filled in inside a day. A conversation that stops to demand a fully-loaded cost model produces nothing.

If the request is vague, ask two or three questions at a time, not a form. The highest-value opening questions are usually:

• What is the first thing that goes wrong if this role is not filled by [date]?
• Who is absorbing this work today, and what have they stopped doing to absorb it?
• Has anything already been dropped, delayed, or given to an agency because of this gap?

Where the environment supports structured multiple-choice questions, use them for the closed choices (permanent vs fixed-term, level, urgency) — they are far faster to answer than free text.

Process

1. Establish the request and the real trigger

Get the role, level, team, start date, and the outcome at risk. Then push once on why now — headcount cases are much stronger when tied to a dated event (a funding round, a product launch, a contract win, a regulatory deadline, a departure) than to a gradual sense of strain. If there is a dated trigger, it becomes the spine of the timing section.

Establish whether this is incremental headcount (new cost to the business) or a backfill (cost already in the plan). These are completely different arguments. A backfill case is mostly about why the role should not be quietly absorbed as a saving; an incremental case has to justify new money. Ask, because the user will often not have said.

2. State the problem in business terms

Convert workload language into business language. The translation is the single highest-value thing this skill does:

| What the user says | What goes in the document | | --- | --- | | The team is stretched | Delivery of X has slipped from Y to Z; the queue has grown from A to B | | We're firefighting | N% of the team's time is going to unplanned work, against a plan of M% | | People are going to quit | Two of four people in this team are carrying sustained overload; replacing one costs [X] and takes [Y] weeks | | We can't keep up with hiring demand | The plan requires N hires this year; current capacity delivers M | | Quality is suffering | Defect/escalation/rework volume has moved from X to Y since [date] |

Use whatever evidence the user actually has — ticket queues, delivery dates, pipeline numbers, NPS, SLA reports, overtime, agency invoices, exit interview themes. Weak evidence honestly labelled is fine. Invented evidence is not: never generate a figure the user did not give you, and never write a benchmark as though it were sourced. If a number is needed and unavailable, bracket it.

3. Quantify the cost of inaction

This is the section most people omit and the one that lands. A CFO is not choosing between your role and nothing; they are choosing between your role and something else. Cost of inaction is what makes the comparison real.

Read references/cost-model.md for how to do this without overclaiming — the tiering of evidence, the conservative/stated/stretch band, and the double-counting traps. The short version: lead with the most conservative defensible number, show the working, and never claim a saving that does not correspond to money actually leaving or entering the business.

4. Work through the options — genuinely

Set out what else was considered and why it was rejected. Do nothing. Redistribute internally. Contractor or interim. Agency or outsourced. Offshore or nearshore. Automate or tool. Defer a quarter. Hire at a lower level. Part-time or fixed-term.

A case that shows the alternatives were weighed is dramatically more credible than one that jumps straight to "hire a full-time person", because the CFO is going to raise every one of these anyway. Raising them first means you control the framing.

Be honest about the trade-offs — a case that dismisses every alternative in one line reads as a case that considered none of them. If a contractor genuinely would work for two quarters, say so and explain why permanent is still the better answer over three years, or propose the contractor as the interim step. Sometimes the honest conclusion is that the alternative wins; say that too. The user's credibility across the next five reqs is worth more than this one.

references/cost-model.md carries the real trade-offs of each option — the loaded cost of a contractor versus an employee, what redistribution actually costs, when automation displaces work and when it just moves it.

5. Build the recommendation on fully-loaded cost

Base salary alone gets the case picked apart, because finance will add the rest in the meeting and the number will change in front of everyone. Include, in the document:

• Base salary (use the band midpoint or the offer you expect to make, not the bottom of

the band)

• Employer taxes and mandatory contributions
• Pension or retirement contribution
• Benefits — healthcare, insurance, allowances
• Equity or bonus, if relevant, at expected cost
• Recruitment cost — agency fee if applicable, or a share of internal cost
• Equipment, software licences, desk or workspace cost
• Ramp — the period before the person is fully productive, which is a real cost even

though it appears in no ledger

Prompt for what you can get. Where a figure is missing, use a clearly-marked placeholder and put it on the "numbers to get" list rather than guessing. Where a proportion is genuinely useful (employer on-costs as a percentage of salary, for instance), express it as a range to validate locally and say so plainly — these vary enormously by country and by employer.

Give both year one cost (part-year, plus recruitment, plus equipment, minus ramp) and steady-state annual cost. Finance thinks in both, and quoting only one invites the question about the other.

6. Express the return honestly

Say which kind of return this is, because they are not equally credible:

1. Revenue enabled or protected — strongest when there is a named deal, contract or

launch, weakest when it is a share of a general growth number.

1. Cash cost avoided — agency fees, contractor day rates, overtime, penalty clauses.

Very strong, because it is verifiable against invoices.

1. Capacity released — real, but not cash. Do not convert hours into money unless the

business will actually stop spending that money. A CFO will notice, and it damages everything else in the document.

1. Risk reduced — compliance exposure, key-person dependency, attrition of scarce

skills. Legitimate, but express as exposure and likelihood, not as a savings figure.

A plausible modest case beats an implausible large one, and it survives the follow-up review twelve months later. Where a return is uncertain, give a conservative figure and state the assumption underneath it.

Express the answer as a payback period where the maths supports it — "the role pays for itself at X months on the conservative case" is the sentence finance repeats to the CEO.

7. Timing, and what happens if approval slips

Say when the role is needed and what changes if it is approved a quarter later. Be specific: which deliverable moves, what the interim cost is (usually agency or contractor spend, or the outcome simply not happening), and whether the role gets harder to fill later. If a delay is genuinely survivable, say so — it costs you this quarter and buys you enormous credibility next time.

8. Define the measures

Three or four measures, with a baseline and a review date, that will show whether this worked. Include at least one that could come back negative. A case with self-marking success criteria is a case nobody believes. This section is also the answer to "what did the last hire in this team deliver" the next time round — the user should keep it.

9. Pre-empt the objections

Before finalising, read references/objection-handling.md and check the draft answers each standard challenge somewhere in the body — not in an appendix, and not as a defensive Q&A section, but woven into the relevant paragraph. The objections that kill cases are predictable: can it wait, can a contractor do it, what gets dropped if we say no, why permanent, what did the last hire deliver, why can't the team absorb it, and what happens if the forecast misses.

The TA and People function variant

Making the case for your own function is harder, because the return is one step removed from revenue and because the CFO has usually been told that recruiters are a cost centre. Argue it on the levers finance can verify:

• Agency and search spend displaced. The strongest argument available, because it is

cash already leaving the building and provable from invoices. Model an honest displacement rate — an internal recruiter will not replace every agency placement, and some searches should stay external. Promising to eliminate agency spend and then not doing it is remembered for years.

• Capacity to deliver the hiring plan. Show the plan's hire count against realistic

per-recruiter capacity, and the gap. This is far more persuasive with a recruiter capacity model behind it — req load by role type and seniority, calibrated against your own historic data rather than a published benchmark. If the user does not have one, build the case anyway and flag that the capacity model is the single strongest addition.

• Cost per hire. Fully loaded, internal versus external, on the actual mix of roles.
• Time to hire, converted into cost of vacancy — but only for roles where vacancy has a

demonstrable cost (quota-carrying, billable, or capacity-constrained delivery roles). Applying a cost of vacancy to every role inflates the number to the point of implausibility and invites the whole document to be discounted.

• Hiring manager time returned. Real and worth stating, but treat it as capacity, not

cash.

• Quality and first-year attrition of hires. Directionally important, hardest to

attribute. State as a measure to track rather than a claimed return.

The same structure applies otherwise. Note in the document that TA headcount is the enabling constraint on every other headcount request in the plan — if the hiring plan is approved and the capacity to deliver it is not, the plan does not happen. That framing moves the argument from "more HR people" to "delivery risk on an already-approved plan", which is a different conversation.

Output

A Markdown file, one to two pages. These get read in five minutes before a meeting; length is not credibility, and a six-page case is a case that gets skimmed to the number and challenged on everything else.

Use assets/business-case-template.md as the skeleton. Structure:

1. The ask — one line: role, level, team, start, annual fully-loaded cost.
2. The recommendation — three or four sentences, readable alone. Assume some approvers

read nothing else.

1. The problem — business terms, with evidence.
2. Cost of inaction — quantified, with the basis shown.
3. Options considered — table, with the reason each was rejected.
4. The cost — year one and steady state, fully loaded, itemised.
5. Expected return — typed by kind, with payback where applicable.
6. Timing — needed by, and the consequence of a quarter's delay.
7. How we will know it worked — measures, baselines, review date.
8. Assumptions and gaps — every placeholder, what it would take to replace it, and who

owns the number.

Keep the assumptions block visible. A senior reader trusts a document more when it is explicit about what it does not know, and it protects the user when a number later turns out to be wrong.

After delivering the Markdown, offer — do not build unprompted — a Word version for circulation with finance, or a three-to-five slide version for an exec or board discussion. Ask which audience it is going to; the answer usually decides.

Where the role is approved, the hiring manager intake skill is the natural next step: the business case defines why the role exists, the intake defines what good looks like in it.

Reference files

• references/cost-model.md — the fully-loaded cost framework, how to model ramp and

first-year effective capacity, the honest trade-offs of each alternative option, how to quantify cost of inaction without overclaiming, and how to express return by type. Read it before writing the cost or return sections, and whenever the user has partial figures.

• references/objection-handling.md — the standard finance and exec objections, what is

actually being asked underneath each, and how to pre-empt it inside the document. Read it before finalising any case, and when a req has already been rejected once.

Data, legal and jurisdiction notes

• Employer on-costs, notice periods and statutory benefits vary enormously by country.

Ask which country the role sits in and get the loading factor from finance rather than assuming one. Any percentage in this skill is a placeholder to replace with a local figure.

• Attrition risk from overload is a team-level argument, not an individual one. Write

"two of four people in this team are carrying sustained overload" rather than naming anyone or characterising their health, stress or family circumstances. The document circulates, the individual did not consent to being in it, and the argument is stronger in aggregate anyway.

• Use band midpoints and ranges rather than named individuals' salaries. The case does

not need them, and pay data in a circulating document creates problems that outlast the req.

• **Contractor-to-permanent conversions and offshoring touch worker status, consultation

and transfer rules that differ by jurisdiction.** Flag these options as requiring employment law review rather than presenting the classification as settled.

• If the case sits alongside a reduction elsewhere, that is a restructure question with

its own legal process. Keep the two documents separate and say plainly that the reduction side needs local legal advice before anything is communicated.

---

Part of the Claude Skills for TA and People Teams collection — open-source skills for in-house talent and people teams. Built and maintained by the team at MOVE.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: we-are-move
• Source: we-are-move/claude-skills-for-ta-and-people-teams
• License: MIT

Install and usage instructions live in the source repository linked above.