The Business Case for Custom AI Workflows: Time, Rework, Consistency, and Onboarding

Prompting is the time spent getting the AI to produce something usable. Checking is the reviewer’s time verifying it. Rework is the time spent fixing what came back wrong. Re-teaching is the time spent explaining the process again to a new hire, a covering colleague, or somebody who forgot.

Most business cases count only prompting, because it is the one people notice. The other three are absorbed invisibly — by reviewers working late, by the person who redoes it quietly, by the senior who answers the same question for the fourth time this quarter.

Hours saved is a weak claim for two reasons. It assumes the saved hour converts into something valuable, which finance will reasonably question, and it ignores the largest costs entirely.

It is also unfalsifiable in the wrong direction: nobody can prove the hours were saved, so the number gets discounted to nothing in the room. A specific claim like “first-pass completeness went from 40% to 85% across thirty runs” survives scrutiny in a way that “we saved six hours a week” does not.

For any business that delivers the same kind of work to many clients, consistency is not an internal efficiency concern — it is what the client is buying. A client who gets an excellent brief one month and a thin one the next has learned something about the vendor, and it is not good.

This is the part of the case that does not show up as a cost line and matters most commercially. It is worth stating plainly: the workflow is the mechanism by which every client gets the same standard regardless of who is staffed on the account.

In most teams the constraint is not drafting capacity. It is the small number of senior people who can tell whether a draft is right, and their time is the thing everything queues behind.

This should reorder your priorities. A workflow that halves drafting time moves work to a queue that was not the bottleneck. A workflow that produces output a reviewer can approve in five minutes instead of twenty-five removes time from the actual constraint, which is worth several times as much.

Ask how long it takes a new hire to produce a deliverable a senior would send without edits. In most teams the honest answer is between two and four months, and the cost is paid twice — once by the new hire and once by whoever supervises them.

A tested workflow shortens this because the standard is written down and enforced at the point of work rather than transmitted through observation. The mechanics are covered in hiring, onboarding, and enablement workflows.

Most repeated judgment work has a hero: one person whose version is always right. The business case for capturing their method is continuity, not cost — work currently stops when they are unavailable, and nobody else can absorb it at the same quality.

Frame this honestly in the room. You are not replacing the expert; you are stopping the organisation from being one resignation away from losing a process. That framing also matters for the expert, whose cooperation you need.

Variance is a risk position, not just an annoyance. If one in six client briefs misses a material risk, the expected cost is a function of how often that happens and what a missed risk costs — a churned renewal, a scope dispute, a remediation project.

You rarely have clean data on this, so use the incidents you do have. Two escalations last year traceable to a missed signal is a concrete, defensible anchor, and it is more persuasive than a modelled number nobody believes.

Before anything is built, take ten real instances of the job as currently performed and record the same five numbers you intend to report later. This takes an afternoon and it is the single highest-leverage thing in the whole exercise.

Use real work, not a reconstruction. A baseline collected from memory is worth nothing, and everyone in the approval meeting will know it.

The headline operational metric is elapsed time from inputs available to a draft the reviewer is willing to read. It captures prompting and self-repair together, which is what actually changes.

Report it as a distribution, not an average. “Nine of ten runs under twelve minutes, one at forty because the transcript was missing” tells the real story, and the outlier is usually the most informative data point you have.

First-pass completeness is the most direct measure of whether the definition of done is working. Count the required sections in the output specification and record how many arrived complete without a follow-up prompt.

It is also the metric most sensitive to a bad edit, which makes it an excellent regression signal. If completeness drops after a version change, you changed something you did not mean to.

Count two things per run: claims asserted without a source in the inputs, and material facts present in the inputs that the output failed to surface. Both are recorded by the reviewer in a single line, so the measurement costs almost nothing.

This is the quality metric executives actually care about once it is explained, because it is the one that maps to risk. A workflow with a stated unknowns policy should drive invention close to zero — the mechanism is in the unknowns policy that stops invention. The full set worth tracking once a workflow is live is in quality metrics for AI workflows.

Before a workflow exists, ask each person on the team to send you what they currently use. Six people usually produce four or five materially different variants, and often one person has no repeatable method at all. Count the personal Custom GPTs, Projects, and Gems as variants too — they are the same divergence in a nicer wrapper, as described in counting Custom GPTs as prompt variants.

Count it again at ninety days. Going from five variants to one is a concrete consistency claim and it is trivially auditable, which makes it unusually credible in a room full of sceptics.

Express the operational gain as work absorbed rather than hours saved. “The same two account managers now cover thirty accounts at the previous review depth instead of twenty” is a claim about output, and finance can price it.

Be careful to only claim capacity that was genuinely constrained. If nobody was waiting for more account reviews, the capacity is real but worthless, and claiming it damages the rest of the case.

Some real benefits do not have a number: the weekly update that no longer eats Sunday evening, the handoff that arrives in a shape the receiving team can use, the reviewer who stops dreading the queue.

Include these, briefly, and label them as qualitative. Presenting them as soft benefits alongside hard numbers is credible; dressing them up with invented figures undermines everything above them.

Four claims reliably get a business case rejected, and all of them are avoidable. Each one asserts something the audience knows you cannot support.

The general rule: claim only what you measured, on the runs you measured, over the period you measured. A modest, verifiable case gets approved. An ambitious, unverifiable one gets a follow-up meeting that never happens.

Take a weekly job done by six people. Baseline: 45 minutes of drafting and self-repair, 20 minutes of senior review, and roughly one rework cycle in three. That is about six and a half hours of team time a week, of which two hours sit on the senior reviewer.

A workflow that lands drafts at 15 minutes with 8 minutes of review and rework in one run of ten takes it to roughly two and a half hours a week, with under an hour on the reviewer. The number worth leading with is the reviewer hour, because that was the constrained resource. For founder-led teams the constrained resource is usually the founder, which is its own case — see one shared workflow for a founder-led team.

Agencies multiply differently. The same workflow runs across every account, so the gain scales with client count while the build cost stays fixed — twenty clients means twenty times the runs against one artifact.

There is a second effect that matters more commercially: variance across accounts collapses, so the quality a client experiences stops depending on who is staffed on them. That is covered in agency math for AI workflows, and the consultancy variant — where the product is judgment itself — is in productizing delivery without diluting judgment.

If the job is common — a meeting recap, a standard research summary, a competitor scan — a ready-made skill you install and adjust will be cheaper and faster than anything bespoke, and it will be tested more broadly than a first build of your own.

The test is whether your version of the job carries rules nobody outside your company would have. If not, start from the library or a bundle and only build custom if it genuinely does not fit. The full decision test is in what to install and what to commission.

Custom pays back quickly when three things are true at once: the job runs weekly or more, the output depends on your own rules or source systems, and a senior reviewer is currently the bottleneck.

With those conditions, the reviewer-time reduction alone usually covers the build within a quarter, and the consistency and onboarding gains arrive on top. Without them — a monthly job, generic rules, no review constraint — the honest answer is that custom is premature.

Structure the page in six blocks: the job and how often it runs; the baseline five numbers from ten real runs; the definition of done the workflow will enforce; the target for each metric at thirty and ninety days; the pilot scope with a named reviewer and owner; and the decision point at ninety days — keep, revise, or kill.

The ninety-day kill option is what makes the rest credible. A proposal that includes the conditions under which it would be abandoned reads as an experiment with a budget rather than a commitment, and it gets approved more often. Scoping is described on the custom workflows page, the rollout sequence in pilot to shared standard, and the questions to put to a vendor in what to ask a vendor before signing.