Setting a Baseline Headcount Plan Before an AI Rollout

Include a task only when all five conditions hold:

1. It is repeated on a predictable cadence (per ticket, per invoice, per pull request, per day).
2. One person or one small team owns the run end to end.
3. The run has a definable start and end, so you can time it.
4. Errors are observable, either by a downstream check or a customer complaint.
5. The AI is expected to change either the time, the error rate, or both.

Leave out anything where the AI only changes quality of thought (strategy memos, design critique) or where volume is too low to sample. Those belong in a soft-benefits note, not in the hours or error ledger.

A useful split is by workflow stage rather than by job title. A support organization's "refund request" task cuts across triage, lookup, response drafting and approval, and the AI may touch only one of those steps. If you baseline the whole job, you will overstate savings. The same discipline applies to coding work: measure per workflow (feature work, tests, migrations, code review) rather than per seat, because one seat can carry very different tasks the Waydev ROI guide.

Note that most documentation on AI measurement already insists on a pre-rollout baseline. One metrics guide recommends setting baselines 3 to 6 months before introducing AI, recording total labor costs and time taken for specific tasks the Naitive metrics guide. The standard software-engineering version is a 90-day pre-rollout window on cycle time, throughput, change failure rate and rework the Waydev ROI guide. Pick one window per task and write it down.

There are four recognized ways to get task times: direct stopwatch time studies, work sampling of portions of the task, predetermined motion-time tables, and databases of similar tasks the BSM Lean work measurement note. For knowledge work, only the first two are credible. Tables and databases were built for repetitive manual motion, not for reading a contract.

Two practical rules:

• Sample enough runs. Twenty is a workable floor per task, spread across people and days. Direct stopwatch studies risk measuring an outlier, and the recognized fix is to measure repeatedly with different combinations of people and equipment the same BSM Lean note. If your task takes an hour and happens twice a week, spread those 20 runs over ten weeks, or accept wider uncertainty and say so.
• Prefer system timestamps where they exist. Ticket open and close times, commit to merge times, and invoice receipt to approval times are free, unbiased and already logged. A stopwatch is for the gap between those timestamps, not a replacement for them.

Work sampling, the technique of taking intermittent observations over a period, is the cheaper option for long, fragmented tasks; it has been used since the 1930s and is standard in industrial engineering the Lean 6 Sigma Hub work sampling guide. Its weakness is that it estimates proportions of time, not the duration of one run, so pair it with timestamps when you need per-run numbers.

Whatever you collect, report the count and a range, not a single average. A time study exists to establish a standard time, which is a benchmark for later comparison, and any benchmark without a stated spread invites an argument you will lose the SixSigma.us time study overview. A simple mean plus minimum and maximum per task is enough for a finance conversation.

The error side is where baselines usually collapse into guesswork. Use the cost-of-poor-quality structure: internal failure costs (rework, rectification, failure analysis) and external failure costs (complaints, returns, warranty, credits), and note that tracking these costs lets you benchmark performance over time the SixSigma.us COPQ explainer. Both belong in your error ledger, because an AI that shifts errors from "caught internally" to "caught by the customer" has made things worse while improving the internal number.

A worked example makes the arithmetic concrete. Take a document-processing task, 10,000 transactions a month, an error rate of 5 percent, and $50 of cost per error. A financial services case cited in one ROI guide reports cutting errors from 5 percent to 0.3 percent on exactly those volumes, which came to $28,200 a month or $338,400 a year the Naitive metrics guide. The baseline record that makes such a claim checkable is three numbers: 500 errors per month at baseline, $50 per error, and $25,000 of monthly error cost.

To get the $50, build the cost per error from parts:

Note the last row. Keep judgment-based estimates out of the hard error cost, or a single generous assumption will discredit the whole ledger. Fully loaded hourly rates should include benefits and overhead, typically 1.3 to 1.5 times base salary the Pickaxe ROI guide.

One row per task, one column per field. A minimum viable schema:

task_id | task_name | owner | system_of_record | runs_per_week | sample_n
time_mean_min | time_min_min | time_max_min | error_rate_pct | error_cost_usd
baseline_start | baseline_end | collector | approved_by | notes | revision

Three storage rules turn a spreadsheet into evidence:

1. Freeze it. Save a read-only copy with the baseline window in the filename, and record a hash or a version number. Any later edit creates a new revision, never an overwrite.
2. Put it where finance can find it. The system of record for baseline data should be the same place cost center owners look, not a personal drive. Link it from the business case document.
3. Name a person. "Owner" means the person who will answer questions about the numbers in twelve months, not the team.

The reason to be strict is that public ROI evidence is uneven: many published business cases are vendor-published, annualized, expected or gross of implementation cost, which is why one benchmark report assigns confidence scores instead of forcing comparability the Alice Labs benchmark report. Your internal baseline should be the one dataset in the room that does not need a confidence caveat.

The baseline's real job is to seed two ledgers that stay separate forever. Mixing them is the most common way savings claims become unfalsifiable.

Ledger one: hours saved. Baseline hours per period minus post-rollout hours per period, for the same volume. Volume normalization matters: if ticket volume doubled after rollout, raw hours may rise while hours per ticket fall. Report hours per unit of work, then multiply by actual volume.

Ledger two: error cost avoided. Baseline error cost per period minus post-rollout error cost per period, using the same cost components. If a component changes definition mid-flight, restate the baseline and say you did.

There is a third number that must be subtracted from both: the rework the AI itself creates. The clean formulation is that if AI drafts in 20 minutes instead of 60 but you spend 25 minutes fixing it, the saving is 15 minutes, not 40 the Naitive metrics guide. Net time saved must be measured after review and rework time, using measured data rather than survey estimates the Waydev ROI guide.

Then apply the honesty test that finance will apply anyway. Counted hours are capacity, not cash, unless headcount, contractor spend or overtime actually fell. Present them as capacity (for example, the equivalent of a stated number of full-time staff) and show where the capacity went. A guide to AI agent ROI calls the alternative "phantom productivity": a claim that hours were saved while nobody can show where they went the Pickaxe ROI guide. One benchmark report also flags that AI automation delivers credible workflow-level gains while enterprise-wide ROI remains uneven and conditional on baseline measurement and workflow redesign the Alice Labs benchmark report.

A one-page ledger format that survives review:

If your AI touches several systems and model types, the post-rollout side is easier to keep consistent when time and error data come from one place. Quanta Inference (https://quantaintelligence.ai/inference) exposes text, image, video, audio and embedding models through one OpenAI-compatible API, which keeps the measurement surface to a single key and a single cost line.

Expect three challenges. First, "the sample is too small." Answer with the sample count per task and the observed range, and offer to re-sample one task if the spread is wide. Statistical notes on uncertainty exist precisely because sample estimates differ from the true value, and reporting a confidence interval is the standard way to show how much the ONS uncertainty explainer. Interval methods for sampled proportions are well documented, including the recommendation to use exact intervals such as Clopper-Pearson for activity sampling rather than the simple Wald interval, which behaves badly near zero and one the activity sampling paper. Second, "people worked slower because they were being watched." Acknowledge it, and lean on system timestamps for the headline numbers. Third, "the AI changed the process, so the comparison is unfair." This one is legitimate. Record process changes in the notes column at go-live, and define a fixed comparison window per task rather than an open-ended one.

One more objection is worth pre-empting: "we already know it works." Confidence is not evidence. Over 80 percent of a sample of enterprise AI initiatives failed to deliver their intended business value for reasons that include measuring the wrong thing, so a documented pre-launch baseline is cheap insurance the RAND report. The exercise usually takes one analyst two to three weeks per workflow, which is small next to the cost of defending an unprovable claim to a board.

When the baseline is in place and the rollout is live, the same two ledgers become the input to any further automation decision, and a short structured review of goals against the numbers is often the fastest way to decide what to automate next. A free 30-minute discovery call (https://quantaintelligence.ai/calendar) covers exactly that comparison.