Chapter 28: Automation ROI as a Design Input

The most important thing about the crossover analysis is when it runs. Not the inputs it requires, not the outputs it produces, not the recommendation it generates — when. An organization that runs the crossover analysis before committing engineering capacity has turned ROI into a design constraint. An organization that runs it after deployment has turned it into a history lesson.

Most organizations treat automation ROI as a finance exercise: a calculation performed after the design is set, the build is underway, or the system is already live. The calculation confirms what the engineers already built — and what the business has already committed to. It is backward-looking by construction. It measures what was decided, not whether the decision was correct. And because it is performed after the moment when scope, volume assumptions, and build investment were still negotiable, it cannot change any of them.

ROI as a design input means something different. It means the crossover analysis runs at the architecture stage — before scope is fixed, before a capability team is assigned, before a single sprint is planned. At that stage, the inputs to the analysis are still variables. The governance floor can be reduced by narrowing the executor's scope. The build cost can be reduced by descoping complexity. The volume trajectory can be interrogated and stress-tested before it becomes an assumption baked into an approved project. The analysis does not just evaluate a design. It shapes one.

This is the shift Chapter 27 pointed toward. The chapter that follows makes it operational: what the crossover analysis looks like at the architecture stage, how the four inputs are constructed when the executor does not yet exist, how volume uncertainty is handled honestly rather than optimistically, and how the analysis functions as a genuine decision gate — one with three exits, not just one.

THE CORE IDEA

Architecture is capital allocation. Every decision to build an executor is a decision to commit engineering capacity, governance infrastructure, and operational overhead to a specific workflow. Those commitments have costs, and those costs have a structure — governance floor, build investment, marginal execution — that determines whether the automation creates economic value or merely redistributes cost in ways that are harder to see.

When the CTO treats architecture as a purely technical decision — which workflows to automate, which systems to build, which platform to deploy on — the economic question gets delegated downstream, to a finance team that evaluates the business case after the design is set, or to a post-deployment review that measures outcomes against assumptions that were never properly challenged. The economic discipline arrives too late to do its most useful work.

When the CTO treats architecture as capital allocation, the economic question is embedded in the design process itself. The crossover analysis is not a gate that finance erects after engineering has finished. It is a constraint that shapes what engineering builds. Scope is calibrated to the volume trajectory. Build investment is sized to the governance floor that the executor will carry. The decision to build, to redesign, or to defer is made when it can still be made cleanly — before commitments accumulate and sunk cost logic takes over.

The practical consequence is a different kind of CTO authority. A CTO who can run the crossover analysis at the architecture stage — who can show the CFO and the board not just what the organization is building but what it will cost, when it will cross over, and what volume trajectory it depends on — is making the economic argument for automation in the language that capital allocation decisions require. That is a more durable authority than the authority of the engineer who ships impressive technology. It is the authority of the executive who manages the cost function of the organization.

THE FOUR INPUTS AT THE ARCHITECTURE STAGE

The crossover analysis requires four inputs. Chapter 27 described what each input is. The challenge at the architecture stage is constructing each input before the executor exists — working from estimates, scoping decisions, and volume projections rather than from operational data. Each input requires a different kind of work, and each one carries a different kind of uncertainty.

The governance floor estimate is the most tractable of the four inputs. The ownership model for a new executor can be specified before the executor is built: which role will serve as governance owner, what their weekly monitoring commitment will be, what monitoring infrastructure will be required, what the ACG overhead allocation will be, and what engineering capacity will be needed for recalibration. These are design decisions, not unknowns. An organization with a mature automation capability group has standard governance floor parameters for different executor types — simpler rule-based executors carry lower governance floors than complex model-based ones. The estimate should be grounded in these parameters, not derived from optimism.

FIGURE 2 — Governance Floor Reference Parameters by Executor Type
Executor Type	Gov. Owner hrs / week	Monitoring Infrastructure	ACG Overhead Allocation	Capability Maintenance	Indicative Total Floor / yr
Rule-Based Deterministic logic, no model	0.25 – 0.5 hrs	£2,000 – 5,000	£1,500 – 3,000	£5,000 – 12,000	£10,000 – 22,000
Model-Based Single ML/AI model, stable domain	0.5 – 1.0 hrs	£5,000 – 12,000	£2,500 – 5,000	£15,000 – 30,000	£25,000 – 50,000
Multi-Model / Integrated Multiple models or complex integrations	0.75 – 1.5 hrs	£8,000 – 18,000	£3,500 – 7,000	£25,000 – 50,000	£40,000 – 80,000
Agentic Autonomous multi-step reasoning and action	1.5 – 3.0 hrs	£15,000 – 35,000	£5,000 – 12,000	£40,000 – 80,000	£65,000 – 135,000
Governance owner hours assume a £100–£140/hr fully-loaded rate. Monitoring and ACG overhead are surface-level costs allocated per executor — organizations with larger execution surfaces will see lower per-executor allocations. Capability maintenance ranges reflect recalibration frequency: rule-based executors recalibrate rarely; agentic executors require frequent review. These are reference ranges for architecture-stage estimation only — actual figures must be grounded in the specific ownership model, monitoring design, and ACG operating model of the organization.

Figure 2: Indicative governance floor parameters by executor type. These are reference ranges for architecture-stage estimation — actual costs must be grounded in the specific ownership model and monitoring design for the executor under consideration. Rule-based executors carry the lowest floors; agentic executors carry the highest, reflecting the greater monitoring intensity and recalibration frequency their behavior requires.

The build cost estimate requires scoping work before the analysis can run. A governance floor can be estimated from a description of the executor's type and complexity. A build cost requires enough architectural definition to distinguish between a four-sprint build and a twenty-sprint build. This is a feature, not a bug. The requirement to estimate the build cost before running the crossover analysis forces the scoping conversation that most automation projects defer too long. If the scope is not defined enough to estimate a build cost, the organization is not ready to make an investment decision — and the crossover analysis makes that visible.

The human cost benchmark should be straightforward but frequently is not, because organizations rarely have a fully-loaded cost view of the processes they are automating. The direct labor cost is usually known. The management overhead, the error-correction cost, and the cost of the residual human work that will remain after automation are usually estimated loosely or omitted entirely. The benchmark must be constructed carefully at the architecture stage, because an understated human cost makes every automation look better than it is. A process that costs £200,000 fully loaded but appears to cost £140,000 in the direct labor view produces a crossover analysis that is wrong by thirty percent before the first input is entered.

FIGURE 3 — Human Cost Benchmark and Hybrid Cost Assembly Template
Cost Component	What to Include	Your Estimate	Claims Triage Example
A · GROSS HUMAN PROCESS COST The total fully-loaded cost of the process as it runs today — what you spend if you do not automate
Direct labor cost Fully-loaded salaries + benefits + employer contributions for all staff performing this process	All-in staff cost	____________	£560,000
Management & coordination overhead Time cost of managers and team leads who coordinate or supervise the process team	Typically 10–20% of direct labor	____________	£42,000
Error correction & rework cost Downstream cost of errors in the current human process — remediation, rework, complaint handling	Trace to operational data where possible	____________	£18,000
Quality assurance cost Dedicated QA or audit function reviewing outputs, if separate from the process team	Include only if a distinct QA layer exists	____________	£0
GROSS HUMAN PROCESS COST (A)		____________	£620,000
B · RESIDUAL HUMAN COST Human cost that remains after automation — this is NOT a saving; it appears in the hybrid cost (C) below
Residual human cost post-automation Fully-loaded cost of roles that remain — escalation handlers, specialist reviewers, oversight. Include governance-adjacent time (monitoring review, recalibration prep) here, not in the saving.	Fully-loaded cost of retained roles	____________	£68,000
NET SAVING OPPORTUNITY = (A) − (B)		____________	£552,000
C · ANNUAL HYBRID COST What you spend if you do automate — the full recurring cost of the hybrid execution model at a given volume
Governance floor — governance owner time

Figure 3: Human cost benchmark and hybrid cost assembly template. Section A establishes the gross human process cost — what the organization spends if it does not automate. Section B isolates the residual human cost that remains after automation and is not a saving. Section C assembles the annual hybrid cost at a given volume: governance floor components, amortized executor build cost (executor-specific engineering and ACG onboarding, amortized over executor operational life), platform cost allocation (executor's share of the platform build amortized over platform life — typically 5–10 years — allocated across executors in production), marginal infrastructure (the only volume-sensitive line), and the residual human cost carried from B. The crossover condition — hybrid cost (C) below gross human process cost (A) — is the economic test the automation must pass. Recalculate Section C at conservative, base, and optimistic volume to test sensitivity.

The volume trajectory is the most consequential and the most contested input. Volume is usually expressed as a point estimate when it should be expressed as a range with explicit assumptions. The crossover analysis is most useful when it is run at conservative, base-case, and optimistic volume assumptions simultaneously, so the decision-maker can see not just when the crossover occurs under the expected scenario but how sensitive that crossover is to volume. An executor that crosses over in year two under the base case but only in year five under the conservative case is a materially different investment than one that crosses over in year one under all three scenarios.

The quality of the crossover analysis at the architecture stage is a direct function of the quality of these four inputs. An analysis built on a well-scoped governance floor, a real build estimate, a fully-loaded human cost benchmark, and a range-based volume trajectory produces a decision-grade output. An analysis built on assumptions that have not been challenged produces a number that confirms the decision already made. The architecture-stage discipline is getting the inputs right — which is itself a governance and capability question, not just a finance question.

THE THREE EXITS

The crossover analysis at the architecture stage has three exits. This is what makes it a genuine decision gate rather than a validation exercise. A validation exercise has one exit — proceed. A decision gate has three: proceed, redesign scope, and defer or do not build. The organization that can use all three exits is one where the economic discipline of the crossover analysis is real. The organization that always exits through proceed is not using a decision gate. It is performing a compliance exercise.

Proceed is the correct exit when the crossover analysis shows that the total hybrid cost falls below the equivalent human cost within the executor's expected life at a volume the trajectory supports. The analysis at that point is not just permission to build — it is the economic model that will govern the post-deployment review. The inputs used in the architecture-stage analysis become the baseline against which actual performance is measured. If the executor was approved on the basis of a crossover in year two at one hundred thousand outcomes per year, the post-deployment review should confirm whether that crossover occurred at the volume projected. If it did not, the volume assumption requires examination — not the technology.

Redesign scope is the exit that most automation decisions never reach, because most organizations do not run the crossover analysis before scope is fixed. It is the most valuable exit in the gate. When the crossover analysis shows that the economics are negative or marginal at the proposed scope and volume, the correct response is not to abandon the automation but to ask whether a different design — narrower scope, lower build cost, different governance model — produces a crossover that the trajectory can reach. A classifier that was scoped to handle all returns in a product range at a build cost of £200,000 may not cross over at current volume. A classifier scoped to handle only the highest-volume return category at a build cost of £60,000 may cross over in year one. The economics drive the scope decision, not the other way around.

Defer or do not build is the exit that requires the most organizational maturity to use. It requires the CTO to say, on the basis of an economic analysis, that the automation is not justified at current scale — and to mean it. In most organizations, this exit is effectively unavailable. The culture treats automation as self-evidently beneficial. The engineering team has already invested time in scoping. The business stakeholder is expecting delivery. The governance process has no mechanism for a clean no. The crossover analysis makes the no legible — it is not a preference or a judgment, it is a number — but the organization must have the structural capacity to act on it. That capacity is itself a governance design question.

VOLUME UNCERTAINTY AS AN EXPLICIT INPUT

The single greatest source of error in automation ROI models is volume. Not governance floor underestimation, not build cost overrun, not marginal infrastructure miscalculation — volume. An executor approved on the basis of a volume trajectory that does not materialize carries a governance floor it cannot justify. The per-outcome cost never falls to the level the model projected. The crossover never arrives. The organization continues to pay the governance floor for an executor whose economics were never viable — and often does not know it, because the post-deployment review measures output volume rather than outcome economics.

The correct treatment of volume uncertainty at the architecture stage is to make it explicit rather than to resolve it with a single point estimate. The crossover analysis should be run at three volume scenarios, constructed before the analysis rather than after: a conservative scenario based on a defensible floor — the volume at which the business process could plausibly operate if growth does not materialize; a base-case scenario based on the most likely trajectory given current conditions and planned changes; and an optimistic scenario based on the upper range of plausible growth, without heroic assumptions.

The decision logic from the three scenarios is more useful than any single scenario. If the crossover occurs under all three — conservative, base, and optimistic — the automation is robust to volume risk and the decision to build is clear. If it occurs under base and optimistic but not conservative, the build carries volume risk that should be acknowledged explicitly in the approval: the organization is betting on a volume trajectory, and it should know that is what it is doing. If the crossover only occurs under the optimistic scenario, the economics do not support the build at any reasonable volume assumption, and the analysis should say so directly.

Volume uncertainty also has a scope implication that most organizations miss. When volume is uncertain, the correct response is often to narrow scope rather than to widen it. A narrower executor with a lower build cost has a lower crossover threshold — it becomes economically viable at a lower volume. An organization facing volume uncertainty should design for the conservative scenario, not the optimistic one: build the executor that can justify itself at the volume floor, and expand scope as volume materializes. This is the opposite of the instinct that most automation projects follow, which is to build the most capable system the technology allows and hope the volume arrives to justify it.

THE FAILURE MODE

The failure mode in this chapter is distinct from the failure mode in Chapter 27. Chapter 27 described an organization that ignores the governance floor and overstates its savings. This chapter's failure mode is an organization that runs the crossover analysis correctly but at the wrong time — after the design is set, after the build is approved, after the engineering team has already started. The analysis is technically correct. It is economically useless.

The post-approval crossover analysis is a common artifact in technology organizations that have adopted economic governance frameworks without internalizing what makes those frameworks useful. The framework requires a crossover analysis, so a crossover analysis is produced — typically by the finance team, working from numbers provided by the engineering team, after the design review has concluded. The analysis confirms the project is economically justified. It always does, because the inputs — the volume estimate, the build cost, the human cost benchmark — were provided by people who wanted the project approved.

The corruption of the crossover analysis happens upstream of the numbers. It happens when the volume estimate is provided by the team that wants to build the system rather than challenged by an independent party. It happens when the build cost is taken from an optimistic scoping estimate rather than a grounded engineering assessment. It happens when the human cost benchmark uses direct labor only, and the governance floor is described as an operational overhead rather than a line item in the ROI model. Each of these inputs can be technically defensible while being systematically biased in the same direction. The result is an analysis that produces the right answer to the wrong question.

The structural correction is sequencing. The crossover analysis must run before scope is fixed — while the team proposing the automation cannot yet provide the inputs, because the design decisions that determine the inputs have not yet been made. That sequencing forces the inputs to be constructed from parameters rather than from project assumptions. The governance floor comes from the ACG's standard parameters for this executor type. The build cost comes from an independent scoping estimate. The volume trajectory is reviewed by a party with no stake in the project approval. The analysis is still an estimate. But it is an estimate that cannot have been shaped by the desire for a particular outcome.

FIGURE 1 — The ROI Decision Gate: Crossover Analysis as an Architecture-Stage Input
ARCHITECTURE STAGE · Before scope is set · Before engineering is committed
Governance floor Ownership model costs, monitoring, ACG overhead, capability maintenance — annual recurring fixed cost	Build cost estimate Executor build cost (engineering + ACG onboarding) — one-time, amortized over that executor's operational life. Enter the executor-specific cost only. Platform build cost is a surface-level asset amortized over the platform's operational life (typically 5–10 years) and allocated across all executors in production — it should be included as a separate platform cost allocation line, not folded into this input.	Human cost benchmark Fully-loaded cost of the equivalent human process — labor, management, error correction, residual	Volume trajectory Outcomes/year at Year 1 and projected growth over the executor's expected operational life
▼	▼	▼	▼
CROSSOVER ANALYSIS At what year, at what volume, does the total hybrid cost fall below the equivalent human cost — fully loaded, including build cost amortization, governance floor, and marginal infrastructure?
▼	▼	▼	▼

Figure 1: The ROI Decision Gate. Four inputs — governance floor, build cost estimate, human cost benchmark, and volume trajectory — are constructed at the architecture stage, before scope is fixed. The crossover analysis produces one of three exits: proceed, redesign scope, or defer. The critical discipline is sequencing: the gate must run before engineering commitment, not after it.