Verified against ChatGPT · 2026-08-12
Model three honest headcount scenarios instead of one optimistic hiring plan
Builds a headcount plan across a growth, flat, and freeze scenario for the next few quarters, forcing each scenario to name what actually gets cut or delayed rather than presenting only the plan leadership wants to hear.
The prompt
Ready to copy — highlighted parts are example details you can swap.
Build a workforce plan across three honest scenarios for the next next two quarters — growth, flat, and freeze — for one function, so leadership has a real plan for more than just the optimistic case. FUNCTION AND CURRENT HEADCOUNT Customer Success team, currently 14 people. CURRENT OR EXPECTED WORKLOAD DRIVERS Customer count expected to grow 20% if the enterprise deal pipeline closes as forecast; flat otherwise. OPEN REQS AND THEIR STATUS 3 open reqs: 1 approved and in final interviews, 2 approved but sourcing hasn't started. BUDGET SIGNAL FOR EACH SCENARIO Finance has said budget for all 3 reqs is contingent on Q3 revenue hitting target; freeze scenario would mean a hiring pause company-wide. For the growth scenario, size headcount to the stated workload drivers and note which open reqs actually need to be filled versus which are nice-to-have expansion, since "growth" scenarios tend to get built by adding roles without checking whether the workload driver actually justifies each one specifically. For the flat scenario, hold headcount roughly level and identify which open reqs get paused, not just "reprioritized" euphemistically — name the specific req and the real consequence of not filling it (a project slips, a team absorbs more on-call load, whatever is true). For the freeze scenario, go further than pausing open reqs: identify what current work would have to stop or be descoped given existing headcount and workload, and name it specifically rather than assuming the same team can just absorb everything by working harder — an unfunded freeze scenario that doesn't name a tradeoff isn't a real scenario, it's wishful thinking with a different label. For each scenario, name the single most likely trigger that would tell leadership this scenario is the one actually playing out (a specific revenue signal, a specific attrition rate, a specific delivery slip) rather than leaving the decision of "which scenario are we in" as a vague quarterly gut check. OUTPUT FORMAT A table with one row per scenario (growth / flat / freeze), columns for: net headcount change, which open reqs proceed vs pause vs cancel, the one concrete tradeoff or consequence, and the trigger signal that would indicate this scenario is the one happening. Follow the table with one paragraph recommending which scenario currently looks most likely given the inputs provided, stated as a judgment call, not a certainty.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Workforce plans built without a forced multi-scenario structure tend to collapse into a single optimistic plan with soft hedging language, because a model given "build a workforce plan" without further constraint will default to the scenario implied by the framing of the request, usually growth, and treat the other possibilities as an afterthought footnote rather than a fully worked-out alternative. Requiring each of the three scenarios to name a specific, concrete tradeoff rather than accepting a euphemism like "reprioritized" matters because "reprioritized" is exactly the kind of soft language GPT-5.1 will default to when asked to describe cutting something, since it avoids stating an uncomfortable consequence directly — forcing a named specific consequence (a project slips, a team absorbs more load) produces a plan leadership can actually act on, versus one that sounds responsible while committing to nothing. The freeze scenario's requirement to identify what current work stops, not just what future hiring pauses, closes a common gap in these exercises: a freeze scenario that only talks about not hiring is incomplete, because the actual operational question under a freeze is what the existing team stops doing, and a model left to its own devices will often quietly assume the same output continues with fewer people, which is not a real scenario but an unstated assumption of proportionally higher productivity that usually doesn't hold. Requiring a named trigger signal per scenario converts this from a document that gets built once and filed away into an operational tool leadership can actually check against reality quarter to quarter, which matters because scenario plans without trigger signals tend to never get revisited until the situation has already deteriorated past the point where the flat or freeze plan could be implemented calmly.
What you get back
Growth row: net +2 (the approved req in final interviews plus one of the two unsourced reqs; the second unsourced req is genuinely nice-to-have, not workload-justified). Flat row: net 0, the req in final interviews still proceeds since it's already committed, the two unsourced reqs pause, meaning on-call load per person rises roughly 15%. Freeze row: net 0 including canceling the in-flight interview process, and the team would need to descope proactive account check-ins to cover reactive support only. Trigger for freeze: if Q3 revenue comes in more than 8% under forecast. Recommendation: flat scenario currently looks most likely given the enterprise pipeline is only partially committed.
Verified against
ChatGPT GPT-5.1 · 2026-08-12
Changelog
- 2026-08-12 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
