AI Automation ROI: 40 Workflow Audits

The real routes are /fractional-cto and /moonship-mvp.

Method: how the 40 audits measured AI automation ROI

AI automation ROI in these audits was set by four things: monthly volume, variance between cases, the cost of a wrong output, and data readiness. Model choice mattered far less.

At Viithiisys, each audit took one broken workflow, recorded its baseline cost and error rate, scored an automation candidate, and tracked payback from go-live. The point was to compare unlike workflows on one measure. Below we cover how the sample was built, how payback was defined, what the categories look like, which workflow types fail to pay back, and the matrix we now use to score new candidates.

How were the 40 workflows chosen?

They were workflows where a client already felt the pain: manual hand-offs, rework, or queues that grew faster than headcount.

The sample comes from real client engagements, not a survey. Every workflow had an owner who could give us baseline numbers, and that is the one filter we applied. We did not pick workflows because they were good candidates for AI. Some were poor candidates, and those are among the most useful results.

How did we define payback?

Payback period is the full cost to build and run the automation, divided by the monthly net saving, counted from go-live rather than from kickoff.

Running cost has three parts:

• Model usage. Levers such as prompt caching change this materially.
• Human review time. Someone still checks the outputs that matter.
• Maintenance. Prompts, integrations and data feeds all drift.

Accuracy was checked against a labelled sample, following the approach in OpenAI's evals guide.

Hit rate means the share of audits where payback landed inside the window the client set. A workflow that pays back in eighteen months can still be a miss if the client needed twelve. We track hit rate next to payback for that reason.

How should you read these findings?

The audits describe patterns in how payback behaved, and we use them as a scoping prior, not as a benchmark. Your volumes, error costs and data will differ, so test any pattern here against your own logs before you commit budget.

What are the five workflow categories we found?

The 40 workflows fell into five categories, grouped by what the work actually is. Grouping by the type of work, rather than the industry, is what made AI automation ROI comparable across very different clients.

Why categories matter more than industries

Industry labels hid the pattern. A claims queue and an invoice queue behave alike, because both are document-heavy with a small set of outcomes. A support inbox in a bank and one in a logistics firm also behave alike. Grouping by the type of work made payback comparable across sectors.

The five categories at a glance

• Moving data. Re-keying, reconciling and syncing records between systems.
• Reading documents. Extracting fields and classifying invoices, claims, forms and contracts.
• Answering people. Triage and first-line replies to customers, staff or suppliers.
• Making routine decisions. Approvals, routing and eligibility checks with a small set of outcomes.
• Coordinating other systems. Multi-step flows that call several tools and wait on hand-offs.

Within each category, we separated work a fixed rule can handle from work that needs a model. A rule-based desktop flow is cheaper and more predictable where inputs never vary, so those cases were not counted as AI wins. Anthropic's guidance on building agents draws the same line between fixed workflows and open-ended agents, and we scored it the same way.

How does AI automation ROI differ by workflow category?

It differs by workflow shape more than by label. High-volume work with clean interfaces and a cheap review step paid back fastest. Integration-heavy or high-stakes work paid back slowest. These are patterns, not category medians.

Each category has a recognisable pattern that we use when scoping:

• Moving data paid back fastest when volume was high and the systems already had clean interfaces. Plumbing cost sank it when they did not.
• Reading documents paid back well when layouts varied but outcomes were few. It paid back poorly when every document needed a human to confirm the result.
• Answering people paid back where most questions repeated. It stalled where each answer carried legal or financial weight.
• Making routine decisions looked attractive but was the most sensitive to error cost.
• Coordinating other systems had the widest spread, because the cost of integration varied the most.

How to read these patterns

Use the typical case, not the best case. Hit rate matters as much as payback: a category with a short payback and a low hit rate is a gamble. Treat each pattern as a prior for scoping, and check it against your own volumes before committing.

Which three workflow types failed to pay back?

Three kinds of workflow failed to reach payback across the audits. Each failed for a reason that could be seen before any build began, which is why the audit scores them first.

The three failing types in detail

• Low-volume workflows. The build and maintenance cost could not be repaid by so few cases.
• High-stakes workflows with no cheap review step. Every output needed a careful human check, so review absorbed the saving.
• Workflows whose source data was missing or unreachable. The budget went to getting at the data, not to automating the work.

Why a failure list is useful

Published AI ROI case studies tend to feature successes, so a buyer deciding where not to spend often has little to go on. That buyer needs the opposite list. For each failing type, the dominant cause was visible at the scoring stage: low volume, expensive errors, or missing source data. None of the three was a model-quality problem.

What separates fast payback from slow payback?

Four factors separated fast AI automation ROI from slow: monthly volume, variance between cases, the cost of a wrong output, and whether the input data was already clean and reachable. Model choice mattered less than any of the four.

Volume and variance

High volume spreads fixed build cost over many cases. Moderate variance is the sweet spot: enough variety that rules fail, but enough repetition that a model learns the pattern. Very low variance suggests a rule will do. Very high variance means a person is doing real judgement, and the model will need constant correction.

Error cost and data readiness

If a wrong output is cheap to catch, a review step keeps quality high and savings real. If it is expensive, review eats the saving. Data readiness decides how much of the budget goes to plumbing, such as data engineering, before any model work begins. In slow-payback audits, the data work was often the largest single line of cost, not the model.

How do we score AI automation ROI before building?

The matrix scores each candidate workflow from low to high on volume, variance, error cost and data readiness, then maps the combination to one of three actions:

• Automate now. The workflow scores well on the axes that drive payback.
• Fix the process first. The work is broken upstream, and automating it would only speed up the mess.
• Leave alone. The cost of building and maintaining the automation exceeds the saving.

The same matrix in text form:

How does the scoring work?

Each axis gets a score from the audit evidence, not from opinion:

• Volume is counted from logs.
• Variance is measured by sampling cases and counting distinct outcomes.
• Error cost is estimated with the process owner.
• Data readiness is tested by pulling a sample.

Scoring from evidence keeps the conversation honest. A client who believes a workflow is high volume can be shown the log, and the score follows the log.

Where does the score lead next?

A high-scoring workflow moves to build under AI workflow automation, and teams that want a first working version quickly can start with a Moonship MVP build. A mid-scoring one often has a single blocker, such as unclear ownership or messy inputs. AI consulting is the quickest way to resolve it, and a fractional CTO can own the wider process fix when the problem spans teams. A document-heavy winner may go to document AI. Anything else goes back as a process fix.

What would we refuse to automate?

We decline workflows where a wrong output is costly and unreviewable, where volume is too low to repay the build, or where a decision needs a named accountable human. Declining early costs the client an audit instead of a failed build.

Cases we turn away

Low-volume workflows rarely clear the cost of building and maintaining a model.

High-stakes decisions without a review step carry risk that no accuracy figure removes. These are the same two patterns that appeared among the workflows that failed to pay back, so the refusal rule comes straight from the audits. For governance, the NIST AI Risk Management Framework is a sound reference for deciding where human oversight is non-negotiable.

Where to go next

If you suspect a workflow is broken, the broken workflow assessment scores it on the matrix before any build is scoped. You will see the four axis scores, the evidence behind each, and a clear recommendation: build, fix first, or leave alone.

For examples of delivered work, see our case studies.