How to Prove AI ROI in 6 Weeks (No Data Team Required)

Developers who were measurably 19% slower still believed AI sped them up 20% (METR). Here's a 6-week plan to prove AI ROI with a spreadsheet, not a data team.

You rolled out a coding agent or two. Tickets close faster. The team seems less swamped. Then someone asks the question a good feeling can't answer: what's this actually worth? If you want to prove AI ROI rather than assert it, you need a number, and you probably don't have one.

Here's why that's harder than it sounds. In a randomized trial, experienced developers took 19% longer to finish tasks when allowed to use AI tools. Afterwards, those same developers estimated AI had made them 20% faster (METR, July 2025, 16 developers across 246 real tasks). Before the study, they had forecast a 24% speedup. They weren't lying. They measured wrong, because they didn't measure at all.

That gap between felt improvement and recorded improvement is the whole problem. This is a six-week plan that closes it. One process, three metrics, one spreadsheet.

Key takeaways

• 91% of SMB leaders using AI say it boosts revenue (Salesforce, 2024), but saying it and proving it are different problems.
• Pick one process. Not the rollout.
• Track three metrics: time per task, error rate, volume handled.
• Baseline the old way for two weeks before you change anything.
• A small credible number beats a big unverifiable one.
• Ask finance for a bounded pilot with a go/no-go bar, not a rollout budget.

Why can't most teams prove the AI ROI they're sure exists?

Because the process was never measured before it changed. Without a recorded baseline, every improvement is an estimate wearing the costume of evidence. And self-estimates are worse than most people expect: METR's developers were off by roughly 39 percentage points in the wrong direction, and METR's own conclusion was blunt: that anecdotal reports of speedup can be very inaccurate (METR, 2025).

The trap is structural, not lazy. You deployed the agent because something was broken and the team was drowning. So you moved fast, it worked, and the urgency evaporated. Four months later, finance wants attribution, and nobody kept a record of how long the old way took.

That leaves two bad options. Say "trust me, it's working," which no finance team accepts. Or spin up a three-month measurement project, which makes the whole thing feel academic. Neither is necessary.

The gap scales all the way up, too. Among CEOs worldwide, 56% say AI has delivered no significant financial benefit so far and only 12% report gains in both cost and revenue (PwC's 29th Global CEO Survey, January 2026, 4,454 CEOs across 95 countries and territories). Bigger budgets don't fix it. Measurement discipline does.

This is the same trap covered in why AI rollouts stall by month three.

The six-week plan at a glance

Six weeks is the right window. Long enough to smooth out weekly noise, short enough that the project still feels urgent to everyone involved.

1. 01
   Week 0: Pick the process. One high-volume, repetitive workflow with a single owner. Choose your three metrics.
2. 02
   Weeks 1 and 2: Baseline the old way. Log every run in a shared spreadsheet. Change nothing.
3. 03
   Weeks 3 and 4: Turn it on and track the delta. Same metrics, same logging, same team. Change nothing else.
4. 04
   Weeks 5 and 6: Convert minutes into dollars. Apply the savings formula, calculate payback period, write down your assumptions.

That's it. No BI tool, no dashboard software, no data scientist.

How do you pick the right process to measure (week 0)?

A measurable pilot process meets three tests: it runs at least 20 times a week, it follows identical steps each run, and one person can explain it without getting defensive. Miss any of the three and your numbers will be as inconsistent as the process itself.

So think about one intake flow. One approval chain. One report your team still builds by hand. Not "customer service." Not "sales." One workflow you could describe in five sentences to someone who doesn't work there. If you're still choosing, start with picking which workflow to automate first.

The only three metrics that matter

Pick exactly three. No NPS. No CSAT. No vanity numbers.

Why so few? Because the moment you start tracking logins or prompt counts instead of outcomes, you lose the thread that proves value. That failure mode, measuring activity instead of outcomes, is covered in the same post on rollouts.

How do you baseline the old way (weeks 1-2)?

Baselining means logging the existing process for two full weeks before you change anything. One spreadsheet row per run, three columns, filled in at end of day. Five minutes daily, maximum. That's the entire tooling requirement, and it's deliberately boring.

Resist the urge to instrument this properly. Why keep it crude? Because every hour spent building a tracking system is an hour the baseline isn't running, and a half-finished dashboard produces worse data than a spreadsheet somebody actually fills in. The baseline will be messy either way. You're not chasing precision, you're building a number that's directionally true and survives a skeptical read.

One thing to decide now rather than later: what counts as a completed run. Does a task that gets escalated count? What about one that gets abandoned? Write the definition at the top of the sheet in week one, because if you settle it in week five you'll settle it in whatever way makes the number look better.

What if the agent is already live?

Reconstruct the "before" from history. Ticket timestamps, old email threads, and system logs still show how long the process used to take and how often it broke. Pull the two weeks immediately before go-live, so seasonality doesn't distort the comparison.

Imperfect beats absent, and finance cares more about honesty than decimal places. But say plainly that the baseline is reconstructed, and name the records you pulled it from. A reconstructed baseline you've labelled as such is credible. The same baseline presented as a clean measurement falls apart the first time someone asks how you captured it.

How do you track the new process without breaking the comparison (weeks 3-4)?

Turn on the new process and track the same three metrics, logged by the same people at the same time of day. Two rules protect the comparison: change nothing else, and log every failure.

Swap a tool mid-test, add a second automation, adjust volume targets, and you've destroyed attribution. You'll have a better number and no way to explain where it came from.

The second rule matters more than it looks, and the research shows why. When METR ran a follow-up study in late 2025, between 30% and 50% of participating developers admitted they were quietly declining to submit certain tasks because they didn't want to do those tasks without AI (METR, February 2026, 57 developers across 143 repositories). Nobody instructed them to cherry-pick. It happened anyway, inside a controlled trial run by professional researchers who were watching for exactly that. What are the odds your team is more disciplined than that?

Assume it'll happen and make it hard to. Log every redo, every exception, every time the agent handed back something wrong. Those entries are what make the final number survive scrutiny, and their absence is the first thing a skeptical reader notices.

How do you turn minutes saved into a dollar figure (weeks 5-6)?

One formula does the work:

(Old time per task − New time per task) × Weekly volume × Fully loaded hourly cost = Weekly savings

Fully loaded hourly cost is salary plus benefits plus overhead, divided by roughly 2,000 working hours a year. Finance already has this number, so ask for it rather than inventing one. A made-up rate is the fastest way to lose the room.

Then multiply weekly savings by 52 for the annual figure, and calculate payback period as total project cost divided by weekly savings. A $12,000 project saving $1,500 a week pays back in eight weeks. That's usually the only number your CFO repeats to anyone else.

Worked example: Acme SaaS (illustrative only)

These figures are a placeholder company and illustrative math, not a client outcome. Acme SaaS times its contract-intake process before and after deploying an agent.

The math runs in four steps. Twenty-five minutes saved across 60 tasks is 25 hours a week. Twenty-five hours at $40 is $1,000 in weekly savings. Annualized, $52,000. So if setup cost $10,000, payback lands at 10 weeks and net first-year savings sit near $42,000.

Write those four steps down. Because when someone re-runs your math with a $32 hourly rate instead of $40, you want them adjusting one input rather than rebuilding your reasoning from scratch.

What separates real proof from a number nobody trusts?

Defensible proof has three components: a before-and-after on one process measured both times identically, error and failure cases documented rather than omitted, and assumptions written down so the math can be re-run with different inputs. Walk in with those three and a modest number, and you win the room.

Notice what's absent from that list. Size. A $1,000-a-week saving on one workflow, documented properly, travels further inside a company than a $400,000 annual figure built on estimates, because the first one can be checked and the second one can only be believed. Once a number gets questioned and holds, it becomes the reference point for the next three projects.

What if the numbers are bad? Then you've learned something in six weeks instead of eighteen months. Only one in four CEOs say their organisation tolerates high risk in innovation, has disciplined processes for stopping underperforming initiatives, or runs a dedicated innovation function (PwC, January 2026). Companies with entire strategy functions struggle to kill things. A ten-person ops team with a spreadsheet has no such excuse, which is the advantage nobody mentions.

So set the kill criteria in week 0, before you're emotionally invested. If the tracked metrics show no clear improvement by the end of week four, treat that as the answer. A killed pilot with clean documentation reads as more credible than a rollout that underperforms in silence for a year. Forcing a good story out of flat data only costs you the next budget conversation.

How do you turn the number into a case finance approves?

The six weeks give you one defensible number, and that number is the evidence for the next ask. If you need sign-off before week 0, ask for the six weeks as a bounded pilot. Either way, the ask takes the same discipline. Cases that get rejected typically lead with a vendor-supplied "10x ROI" claim that crumbles the moment someone asks to see the math. Build yours across four layers:

1. 01
   Direct time savings. Hours saved multiplied by the fully loaded hourly rate: the weekly figure from weeks 5 and 6. This is your most defensible number because it draws from your own baseline, not vendor projections.
2. 02
   Output multiplier. What the reclaimed time actually produces. Only count time you can realistically redirect, not every saved minute.
3. 03
   Revenue attribution. Most teams skip this layer because direct attribution is genuinely hard. That instinct is right. If you include revenue projections, apply confidence weighting: high-confidence benefits at 100% credit, medium at 60%, low at 25%. Hard benefits alone must cover the investment.
4. 04
   Total cost of ownership. Add setup, training, maintenance, governance overhead, and switching costs to the license fee. Realistic year-one TCO often runs well above the sticker price: a $30K annual license can mean $45-75K in year-one cost once those are counted.

(L1 + L2 + L3 − L4) / L4 = ROI multiple

Present three scenarios: conservative (50% adoption), base (70%), and optimistic (90% with full workflow change). Running the scenarios signals you've thought through failure modes, which is exactly what your CFO is already doing.

Then ask what you're already paying for that you should stop paying for. Pull the last 12 months of software spend and tag every tool by usage: daily, weekly, monthly, or "who bought this?" Those tools are your AI budget, pre-funded. I've watched a 60-person sales team fund their entire AI rollout by cutting four tools nobody could remember buying. The CFO approved it in under 48 hours because there was no net-new ask.

Finally, ask for the pilot, not the rollout. Asking for $200K to roll out AI across 100 reps triggers every organizational immune response. Asking for $4,800 to run the six-week plan with eight reps and a pass/fail bar? That's an experiment budget, and many CFOs approve those at their level without escalation. Write the go/no-go line into the ask, the same stop rule at the end of week 4, and name the three things most likely to fail: typically adoption, data quality, and integration complexity. Acknowledging risk isn't weakness. It's the fastest way to build trust with a finance audience.

What do you report every quarter once it's live?

Once the pilot becomes a rollout, the question changes from "did it work?" to "is it still working?", and the people asking are the owner, the leadership team or the board. They don't speak engineering; they speak risk, margin, and revenue. Four numbers cover them:

1. 01
   Cost per successful outcome. Total AI cost divided by goals actually achieved: a resolved ticket, an unedited report, a draft someone accepted. Cost per token is a trap, because it rewards cheaper models that might fail half the time. You want this trending down quarter over quarter, say from €0.45 per outcome to €0.28. More in pricing AI by cost per outcome.
2. 02
   AI-influenced revenue. Revenue from anything sold purely as an AI feature, plus a segment comparison: net dollar retention for customers who use AI features heavily versus those who don't. If heavy users retain at 120% and non-users at 90%, you have justified the budget.
3. 03
   Production reliability score.(1 − [hallucination rate + refusal rate + error rate]) × 100, measured by LLM-as-a-judge evaluators sampling production traffic, not by user complaints. Aim above 99% on narrow paths like extraction or classification, and separate critical failures from creative variance on open-ended chat.
4. 04
   Compliance readiness index. The share of your high-risk AI systems with audit-ready documentation: prompt version history, proof of data residency, risk assessments on file. Under the EU AI Act, obligations for the high-risk use cases in Annex III apply from 2 December 2027, and fines for prohibited practices reach €35M or 7% of worldwide annual turnover, whichever is higher (Article 99). See the architecture traps that survive the delay.

The first and third are the week-0 metrics grown up: time per task becomes cost per outcome, error rate becomes reliability. If you ran the six weeks properly, you already have the habit.

FAQ: proving AI ROI without a data team

Do I need a data team to prove AI ROI?

No. A shared spreadsheet with three columns, logged once a day for six weeks on a single process, produces a defensible number. Dashboards become useful later, once you're tracking five or ten processes simultaneously and manual logging stops scaling.

What's a realistic time savings for a first AI project?

Smaller than the marketing suggests. Across nationally representative US survey data, workers using generative AI reported time savings equivalent to just 1.4% of total work hours, with between 1% and 5% of all work hours AI-assisted (Bick, Blandin and Deming, NBER Working Paper 32966, September 2024, revised February 2025). Workflow-level savings on a well-chosen repetitive process run far higher than that economy-wide average, which is exactly why you measure your own process instead of borrowing a headline percentage.

What if my error rate goes up during the test?

Track it and report it. Documented failures are what make a time-savings figure believable, and a suspiciously clean win invites the scrutiny you were trying to avoid. Rising errors also tell you something useful: the agent may be shifting work into review rather than removing it.

Start with one process, not the whole rollout

Six weeks, one process, three metrics, one spreadsheet. Pick the process in week 0. Log the old way for two weeks. Run the new way for two weeks without touching anything else. Then do the math in weeks five and six, and write down what you assumed.

Once you can point at a real dollar figure on one workflow, you stop needing to defend the rollout with login counts. That's the whole reason this beats a usage dashboard: a small believable number ends the argument, while a large unverifiable one restarts it every quarter.

And remember what METR's developers demonstrated. Being certain a tool is helping is not evidence that it is. Write the number down.