Case: AI Investment Under a Budget Reduction

A regional property insurer’s finance chief told the technology group to cut its 60.0 million budget by 10%. The chief technology officer had one planning week to bring back a package. On one side, the head of data science argued that the board’s strategy named AI and that a claims-triage assistant with a promising pilot should not be starved. On the other, the director of the platform team argued that claims intake was the system through which premium-paying customers reached the company when something went wrong, and that it had been failing too often. Both were describing real money. Neither could say which of the two the company would regret cutting.

The insurer, its people, and every figure here are invented for this case; amounts are in millions of dollars and are hypothetical. The question is how a leader compares a reliability investment with an AI investment when both compete for the same reduced budget and the same few engineers. Doing so means converting each into the same terms: what it costs, what it changes, who must build it, and what evidence would reverse the decision.

A 10% cut is a 37.5% cut

The 60.0 million plan became 54.0. Of the 60.0, 44.0 was committed: salaries of existing staff, signed contracts, and base cloud and license charges. The company had frozen hiring but would not lay people off this year, and severance would have added cost in the year it was meant to save. That left 16.0 of discretionary spending, and 6.0 of 16.0 is 37.5%. The percentage handed down by finance describes the whole budget; the part that can move absorbs almost four times that share. The discretionary lines were seven:

• Claims-intake resilience, a re-platforming of the queue and database behind claims intake: 3.0.
• A claims-triage assistant, a language-model tool that summarizes a new claim and proposes routing for a human handler: 4.0.
• A customer-service knowledge assistant for call-center agents: 2.2.
• A refresh of the fraud model and its feature pipeline: 1.8.
• Coding-assistant licenses for engineers, with an evaluation program: 0.8.
• Phase 2 of a data-warehouse migration: 3.0.
• Contractor backfill, which pays outside engineers to cover work other than claims intake: 1.2.

These sum to 16.0. A familiar approach would rank them by projected return and cut from the bottom. That ranking is unavailable here, because the return on the reliability line is avoided loss and the return on the AI lines is a forecast of changed work, and neither forecast says whether the people to build it exist. The portfolio discipline in Ninety-Four Projects, Every One Approved applies: compare combinations the organization can actually deliver. For this insurer that begins with staffing.

The constraint money does not fix

Only five engineers understood the claims-intake platform well enough to change or recover it. Over twelve months they supply 5 × 12 = 60 engineer-months. Run work, meaning on-call duty, support requests, and patching, takes about 40% of that, which leaves 36 engineer-months for projects. Four of the seven lines needed those same five people: 24 engineer-months for the re-platforming, 30 for the triage assistant, which had to be wired into intake, 6 for the knowledge assistant, which reads claims notes, and 6 for the fraud pipeline, which consumes intake events. That is 66 engineer-months of demand against 36 of capacity, or 1.83 times. The plan approved before the cut was already undeliverable by the people it depended on; a smaller budget did not create that problem, but it removed the option of hiring around it.

The same five people carried the on-call rotation. One week in five is 20% of their time. If one left and was not replaced, the share would rise to one week in four, 25%. Google’s SRE book, which describes its own operating model, caps on-call time at 25% of an engineer’s time and reserves at least half for engineering work. It gives eight engineers as the minimum for a single-site rotation and six for a dual-site one. Five is below both, and those figures belong to a different organization, so they are a reference point rather than a rule. They still show how thin the margin is. The rotation is also the main source of toil, the repetitive manual operational work that grows with the service: the insurer’s four manual failovers last year each pulled the same people away from project work. The wider pattern is described in The Same Engineer Every Night.

This changes what a cut means. Removing dollars from a line whose work is done by the five does not shorten the queue for their time unless it also removes scope. Cutting contractor backfill is the opposite case: it would pull intake engineers into the work contractors were hired to do, such as the warehouse migration, and make their shortage worse. The package therefore had to meet two budgets at once, 6.0 in dollars and 36 in engineer-months.

Putting reliability in business terms

Claims intake had a service objective of 99.9% over a year. A year of 365 days has 8,760 hours, so the objective allowed 8.76 hours of failed or timed-out intake. The measured figure for the last twelve months was 21 hours across seven incidents, or 99.76% (8,739 of 8,760 hours). That is 2.4 times the allowance. In the vocabulary of SLIs, SLOs, and Error Budgets, the error budget was overspent by 12.24 hours. The Site Reliability Workbook describes an error budget policy as the agreement on what happens next, such as giving priority to reliability work or pausing risky changes. The insurer had no such policy, so the overrun changed nothing in planning until the cut forced a choice.

The 21 hours also had causes. Fifteen hours, in four incidents, came from failover and restore steps that engineers performed by hand. Four hours, in two incidents, came from the design of the queue itself, and two hours, in one incident, from a vendor fault. Claims operations estimated the cost of an hour of failed intake at 0.04 million: overtime to clear the backlog, manual processing, and credits to partner agents. Twenty-one hours at 0.04 is 0.84 million a year. Two scopes were on the table.

Option	Cost	Intake engineer-months	Failure hours left	Yearly cost of remaining failures	Avoided cost versus doing nothing
Do nothing	0	0	21	0.84	0
Automate failover and test restores	1.2	12	6	0.24	0.60
Full re-platforming of queue and database	3.0	24	2	0.08	0.76

The narrower scope pays back its 1.2 in 1.2 ÷ 0.60 = 2.0 years on the failures it removes, and it brings the service inside its objective: 6 hours is 68% of the 8.76 allowed, leaving 2.76 hours of margin. The full scope costs 3.0 and avoids 0.76 a year. Its extra 1.8 buys 4 more hours, worth 4 × 0.04 = 0.16 a year, which is a payback of 11.25 years. The SRE book warns that an incremental improvement in reliability may cost 100 times as much as the previous one. The multiplier is not a law; here the increment simply costs 1.8 for 0.16 a year. The marginal analysis shows where reliability spending stops being the best use of an engineer’s year.

There is a second argument for the narrower scope that the yearly cost does not capture. Storm season multiplies claims volume. Suppose a surge week brings four times the normal intake and the restore procedure, which no one had ever rehearsed, took three days. Then 72 hours at 4 × 0.04 per hour costs 11.52 million. That single event is nearly twice the whole cut. Restore testing is part of the narrower scope; if it brought a surge-week restore down to 8 hours, the same event would cost 1.28. At an assumed 3% chance per year of such a week, the expected cost falls from about 0.35 to 0.04, adding roughly 0.31 a year to the 0.60 and bringing the narrower scope’s payback to 1.2 ÷ 0.907 = 1.3 years. The probability is an assumption to challenge, but the payback does not depend on it: the argument for rare, large losses supports rehearsing recovery, and it does not support the larger rebuild.

Putting the AI investment in the same terms

The claims-triage assistant had a value hypothesis: handlers would spend less time reading and routing new claims. The company handled 500,000 eligible claims a year. In a three-month pilot with volunteer handlers, the tool saved about 6 minutes per claim when used, and handlers used it on 45% of eligible claims. A handler minute cost \$0.70 in loaded cost. At full use the time released is 500,000 × 6 = 3.0 million minutes, worth 3.0 million × \$0.70 = \$2.1 million a year.

Time released is not cash. As Live for a Year, Used by a Third explains, payroll does not fall when handlers finish claims sooner; savings appear only where something paid is reduced. The insurer’s paid lever was overtime and temporary staff during surges, 1.8 million a year. The budget therefore credited the assistant with value only to the extent that this line fell. The full-scope figure of 2.1 exceeds the 1.8 pool, so even complete adoption could not be banked in full. Below the pool, the model assumes each dollar of time released does reduce overtime and temporary spending, which is the assumption the first phase must test.

The assistant also has a total cost of ownership beyond the 4.0. Running it requires model usage, monitoring, and review of its output, which the finance team put at 0.5 a year. That is a commitment for every later budget, including one that might be cut again. For the net benefit a in adoption share, the yearly net is 2.1a − 0.5. To pay back 4.0 in four years the net must be 1.0 a year, so 2.1a = 1.5 and a = 71.4%. That adoption share is the switching value: below it, the four-year payback fails. At the pilot’s 45%, the net is 0.945 − 0.5 = 0.445 a year, a payback of about 9.0 years.

A narrower first phase targets two claim types that the pilot suggested were slower to handle. They covered 200,000 claims a year, and the tool saved about 9 minutes on each. The phase cost 2.0 with a yearly run cost of 0.3. Its full-use value is 200,000 × 9 × 0.70 = 1.26 million, which is 70% of the overtime pool. The four-year break-even is (2.0 ÷ 4 + 0.3) ÷ 1.26 = 63.5%.

Option	Cost	Run cost per year	Yearly value at full use	Break-even adoption, four-year payback	Yearly net at the pilot’s 45%
Full scope: 500,000 claims, 6 minutes each	4.0	0.5	2.10	71.4%	0.445
Phase 1: 200,000 claims, 9 minutes each	2.0	0.3	1.26	63.5%	0.267

Neither option clears its threshold at 45%, and that is the central finding. Choosing phase 1 does not claim that the assistant is profitable. It buys, for half the money, an answer to the one assumption that decides the outcome: whether adoption can rise from 45% to about 64% once the tool is built into the handler’s workflow, not offered to volunteers. The pilot exit criteria are written before spending: if adoption on the two claim types is below 63.5% after ninety days in production, or overtime and temporary spending has not fallen as modeled, the second tranche is not released. The 2.0 is released in two parts, 0.8 for integration and workflow redesign and 1.2 after the gate. Money already spent at the gate is a sunk cost and is not a reason to continue.

The remaining AI lines are easier to place. The knowledge assistant had no measured pilot and no paid expense it would reduce, so it could be deferred without a deadline or a continuing loss, which is the question cost of delay asks. The fraud-model refresh maintains a model already in production, so deferring it moves risk onto a system that currently works rather than waiting for an unproven one. The coding-assistant line was cheap and could continue, but the 2024 DORA report found that AI adoption increases individual productivity, flow, and job satisfaction while negatively affecting delivery stability and throughput. The insurer therefore funded the evaluation program with a measure of failed changes and rework next to usage and perceived speed. Those tools were being introduced into the same teams whose reliability was the subject of the case.

The package

The committee needed a combination that met both budgets. The package cut the intake work to the narrower scope (a reduction of 1.8), funded phase 1 of the triage assistant instead of the full scope (2.0), and deferred the knowledge assistant (2.2). Those cuts total 1.8 + 2.0 + 2.2 = 6.0.

Line	Planned	Funded	Intake engineer-months planned	Intake engineer-months funded
Claims-intake resilience	3.0	1.2	24	12
Claims-triage assistant	4.0	2.0	30	16
Customer-service knowledge assistant	2.2	0	6	0
Fraud model refresh	1.8	1.8	6	6
Coding assistants and evaluation	0.8	0.8	0	0
Warehouse migration, phase 2	3.0	3.0	0	0
Contractor backfill	1.2	1.2	0	0
Total	16.0	10.0	66	34

The funded work needs 34 of the 36 available intake engineer-months, leaving 2, or 5.6%. That is little slack, so the sequence matters: failover automation and restore testing come first, because every incident they prevent returns time to the same five people, and the triage assistant’s integration work follows. The package has consequences the committee wrote down. Failure hours fall from 21 to 6 and yearly cost from 0.84 to 0.24. The company gives up the assistance that 300,000 other eligible claims might have received, and its call-center agents continue searching manually. Choosing the narrower scope leaves three incidents’ worth of queue-design and vendor failures in the forecast. The accepted risk is 6 hours a year of failed intake, which is inside the objective, and a restore time for surge weeks that the test will measure before it is believed.

The head of claims operations owns that risk. A technology group can recommend it, but the risk appetite for delayed claims is a business decision about customers and regulators, and the head of claims signed the acceptance.

Alternatives and the conditions for revisiting them

Four alternatives were weighed and set aside. Cutting the warehouse migration instead of part of the triage assistant looked cleaner, but a deferral would extend the legacy warehouse support contract. At an assumed 0.25 per quarter, that is 1.0 for the year, so a 3.0 saving would net 2.0 and require the team to restart. Keeping the full 3.0 re-platforming would cost 1.8 more for 0.16 a year of avoided loss. Cutting reliability entirely would leave 21 hours of failures against an 8.76-hour allowance and the surge exposure with no owner who had accepted it. Buying a hosted knowledge assistant instead of deferring it would convert a one-time cost into a subscription, and a subscription is a cost that reappears in the next budget; The Case Said Four Million and the Cost Was Nine shows how a partial quote becomes a larger bill. Each of these is a choice among complete strategies, as in Five Verbs and One Question.

Each decision carries a condition under which the committee reopens it, set when the package is approved and owned by a named role.

Condition	Reopens	Owner and response
Failed-intake hours in any rolling twelve months exceed 8.76, or the restore test takes longer than 24 hours	The full re-platforming, at 1.8 more	Platform director and head of claims; apply the error budget policy and reconsider the scope
After ninety days, adoption on the two claim types is below 63.5%, or overtime and temporary-staff spending has not fallen as modeled	The second tranche of 1.2	Head of data science and finance; stop or redesign the workflow rather than continue
Run cost of the assistant exceeds 0.3 a year	The break-even adoption share, which for phase 1 rises to 71.4% at 0.4	Finance and head of data science; recompute before the second tranche is released
Any of the five intake engineers leaves	Sequencing: the fraud pipeline’s 6 engineer-months move first, and on-call becomes one week in four	Platform director; do not add work on the strength of backfill that has not been hired
1.0 of cloud savings appears in two consecutive monthly invoices	The knowledge assistant, as a scoped test of at most 1.0	Chief technology officer and finance; see The Bill Doubled for how savings are verified

The last row shows why the committee required invoices. A projected cloud saving does not reduce the cut, because finance counts only reductions it can see. The condition lets good news restore the deferred line without letting a forecast pay for it in advance.

References:

• Google, Site Reliability Engineering, Chapter 3: Embracing Risk — reliability targets, cost of increments, error budgets.
• Google, Site Reliability Engineering, Chapter 11: Being On-Call — on-call time limits and team size.
• Google, Site Reliability Engineering, Chapter 5: Eliminating Toil — defining toil and keeping time for engineering work.
• Google, The Site Reliability Workbook, Implementing SLOs — error budget policy.
• DORA, 2024 Accelerate State of DevOps Report — AI adoption and software delivery performance.