Business Value & ROI

Tie AI work to money: define business success metrics (not just technical ones), calculate ROI honestly including the total cost of ownership people underestimate (inference at scale, the LLMOps maintenance treadmill), build a business case, and track value after launch.

~3hbusiness-valueroiconsulting
Learning objectives
  • Define business success metrics for an AI project, distinct from technical metrics.
  • Calculate ROI honestly: value delivered vs. the total cost of ownership.
  • Account for the costs people underestimate — inference at scale and the LLMOps maintenance treadmill.
  • Build a business case and track value after launch, not just at the pitch.
Note

This is the 8/8 skill. Clients don't buy models; they buy outcomes — money saved, revenue gained, risk reduced. Translating AI work into business value is what closes deals and renews engagements. The "code" here is a small ROI calculation; the skill is the reasoning around it.

Business metrics vs. technical metrics

An eval score of 0.92 (Track 5) is a technical metric — it means nothing to a CFO. Business value is measured in the client's terms: time, money, revenue, risk. Every project needs both, with a clear line from one to the other:

Technical metricBusiness metric it should ladder up to
Answer faithfulness / accuracyFewer escalations, lower error-handling cost, less risk
Retrieval quality / deflectionSupport tickets deflected → agent hours saved → €
Latency (p95)User satisfaction, task completion, conversion
Automation success rateManual hours eliminated → labor cost saved

The discipline: for every technical metric you optimize, name the business metric it moves. If you can't draw that line, you're optimizing something the client doesn't value. This is the bridge from Track 5's eval work to the boardroom.

Tip

Exercise 1 has you take a project and map its technical metrics to the business KPIs they should move — plus the leading indicators you'd watch early.

Calculating ROI

ROI = (value delivered − total cost) / total cost. Both sides need honest numbers. Value is usually one of a few forms — quantify it in the client's units:

  • Labor saved — hours eliminated × loaded hourly cost. (E.g. 200 support hrs/month × €30 = €6,000/month.)
  • Revenue gained — more conversions, faster response, upsell.
  • Cost avoided — fewer errors, less rework, avoided penalties.
  • Risk reduced — harder to price, but real (compliance, churn).
# A simple monthly ROI sketch — the numbers you'd put in front of a client.
value_per_month = 200 * 30          # 200 support hours saved × €30/hr loaded cost = €6,000
run_cost_per_month = 800            # inference (tokens) + hosting + monitoring
build_cost = 15000                  # one-time build (or the diagnostic + build fee)
maint_per_month = 1000              # the part people forget: prompt/model upkeep, evals, incidents

monthly_net = value_per_month - run_cost_per_month - maint_per_month   # 6000 - 800 - 1000 = €4,200/month
payback_months = build_cost / monthly_net                             # 15000 / 4200 ≈ 3.6 months to break even
# Present BOTH: monthly net benefit AND payback period — a CFO reads payback fast.

Present payback period (how long until it pays for itself) and ongoing monthly net — those are the numbers a non-technical decision-maker acts on. Be conservative on value and generous on cost; an ROI case that survives scrutiny wins more than an optimistic one that collapses.

Tip

Exercise 2 has you compute ROI and payback for a project from its value and cost inputs, and sanity-check whether it's worth doing.

Total cost of ownership — the part people miss

The number-one ROI mistake is counting only the build cost. An AI system's real cost is dominated by what comes after launch:

  • Inference cost at scale — tokens are cheap per call and expensive per million. A demo costs cents; the same app at production volume can cost thousands/month. Model it with real volume × per-token pricing (Track 5 observability gives you the numbers).
  • The maintenance treadmill — prompts drift, models get deprecated, evals must be re-run, incidents happen (all of Track 5's LLMOps). This is ongoing engineering time, not a one-off.
  • Human-in-the-loop cost — if the design needs human review (Track 6), that reviewer time is a running cost.
  • Data & integration upkeep — the RAG corpus, connectors, and permissions need maintaining.

A project with a great build-cost ROI can be net-negative once TCO is honest — especially high-volume, low-value-per-call ones. Surfacing TCO protects the client and your reputation (an AI system that quietly costs more than it saves ends relationships).

Watch out

Watch the volume × margin trap: a per-task automation that saves €0.50 but costs €0.40 in inference + maintenance at a million tasks/month is barely worth it and fragile to model price changes. Always model cost at production volume, not demo volume.

Tip

Exercise 3 has you build a total-cost-of-ownership estimate for a project and find where the naive build-only ROI misleads.

The business case

A business case assembles discovery + ROI into a decision document a stakeholder can approve. Keep it tight:

  1. The problem & its cost — from discovery, in the client's numbers ("support spends 200 hrs/month on X").
  2. The proposed solution — briefly, and why this scope (Track 8 Topic 1).
  3. The value — quantified benefit, conservatively.
  4. The cost — build + honest TCO (run + maintenance).
  5. ROI & payback — the headline numbers.
  6. Risks & assumptions — what could change the math (volume, model pricing, adoption), and how you'll measure.

The best business cases are honest about uncertainty — a range with stated assumptions beats a single confident number that reality breaks.

Tip

Exercise 4 has you assemble a one-page business case for a project from its discovery and ROI inputs.

Track value after launch

The business case is a prediction; value realization is the proof. Instrument the business metric (using the observability/eval loop from Track 5) so you can show the client the actual hours saved / tickets deflected / revenue moved after launch. This turns "we think it helped" into "here's the measured benefit" — which is what renews contracts and justifies the next phase. Predicted ROI wins the project; measured ROI wins the relationship.

Pitfalls

  • Reporting only technical metrics. A 0.92 eval score means nothing to a buyer — ladder it to a business KPI.
  • Counting only build cost. TCO (inference at scale + maintenance + HITL) often dominates — model it honestly.
  • Demo-volume cost estimates. Costs that look tiny in a demo explode at production volume — use real volume.
  • Optimistic single-number ROI. A conservative, assumption-stated case survives scrutiny; a rosy one collapses.
  • Never measuring realized value. Predicted ROI isn't proof — instrument the business metric and report actuals.

Recap

  • Pair every technical metric with the business metric it moves (time, money, revenue, risk) — clients buy outcomes, not eval scores.
  • ROI = (value − total cost) / total cost; present payback period and monthly net in the client's units.
  • Account for the total cost of ownership people miss — inference at scale and the LLMOps maintenance treadmill — and model cost at production volume.
  • Assemble a tight business case (problem, solution, value, cost, ROI, risks) that's honest about uncertainty.
  • Track realized value after launch — measured ROI wins the relationship.
  • Worked examples map to the exercises: metric mapping (Ex 1), ROI/payback (Ex 2), TCO estimate (Ex 3), a business case (Ex 4).

Business Value & ROI — Exercises

Business exercises with light arithmetic. Use realistic-ish numbers; the reasoning matters more than precision.


Exercise 1 — Map technical metrics to business KPIs

For a support-deflection RAG assistant, map each technical metric to the business KPI it should move, and name a leading indicator you'd watch in week 1.

Reference solution
Technical metricBusiness KPI
Retrieval quality / answer accuracyTicket deflection rate → support hours saved → €
Faithfulness (no hallucination)Fewer wrong answers → less escalation/rework, lower risk
p95 latencyUser satisfaction / self-serve completion rate
Abstention correctnessTrust / avoided bad advice (risk)

Leading indicator (week 1): self-serve resolution rate and thumbs-up/down on answers — early signals that predict the lagging KPI (monthly support hours saved) before a full month of data. If you can't ladder a technical metric to a KPI, you're optimizing something the client doesn't value.


Exercise 2 — ROI and payback

A project saves 150 support hours/month at €28/hr loaded cost. Run cost (inference + hosting) is €600/month, maintenance €900/month, and the build is €12,000. Compute monthly net and payback period. Is it worth doing?

Reference solution
value = 150 * 28          # €4,200/month saved
run = 600
maint = 900
build = 12000
monthly_net = value - run - maint      # 4200 - 600 - 900 = €2,700/month
payback = build / monthly_net          # 12000 / 2700 ≈ 4.4 months
  • Monthly net benefit: €2,700.
  • Payback: ~4.4 months, then €2,700/month ongoing.

Worth doing — a sub-6-month payback with a solid ongoing net is a strong case. Present both numbers: payback (a CFO reads it instantly) and monthly net. Be conservative on the hours-saved estimate; if it's really 100 hrs not 150, recompute (net €2,200, payback ~5.5 months) — still fine, but check the sensitivity.


Exercise 3 — Total cost of ownership

A per-email classification automation looks great in a demo. At production volume it processes 800,000 emails/month. Each classification costs ~€0.0006 in tokens; maintenance is €1,200/month; it replaces work worth €0.004/email. Compute the honest monthly net and explain where build-only ROI misled.

Reference solution
volume = 800_000
value = volume * 0.004        # €3,200/month of work replaced
inference = volume * 0.0006   # €480/month tokens
maint = 1200
monthly_net = value - inference - maint   # 3200 - 480 - 1200 = €1,520/month

Net €1,520/month — positive, but far thinner than a build-only view suggests. Where build-only ROI misled:

  • It ignored inference at scale (€480/mo — invisible in a demo of 50 emails).
  • It ignored the maintenance treadmill (€1,200/mo — prompt drift, model deprecation, evals, incidents).
  • The margin per email is €0.004 value vs €0.0006 cost — the volume × margin trap: if the model's price rose or value-per-email were lower (€0.002), it could go net-negative. Always model at production volume and stress- test against price changes.

Honest TCO protects the client from an automation that quietly costs more than it saves — and protects your reputation.


Exercise 4 — Assemble a business case

Turn the Exercise 2 project into a one-page business case a stakeholder could approve.

Reference solution

Business case: Support RAG assistant

  1. Problem & cost: Support handles ~150 hrs/month of repetitive documentation questions, costing ~€4,200/mo in agent time (from discovery).
  2. Solution: A grounded RAG assistant over the product docs deflecting common questions; narrow first slice (one team, top 200 pages) per the scoping topic.
  3. Value (conservative): ~150 hrs/month saved = €4,200/mo. (Range: €2,800–€4,200 depending on deflection.)
  4. Cost: €12,000 build; €600/mo run + €900/mo maintenance (honest TCO).
  5. ROI & payback: €2,700/mo net; payback ~4.4 months, then €2,700/mo ongoing.
  6. Risks & assumptions: deflection rate (biggest swing), inference cost if volume grows, adoption by the support team; measured via the golden-set eval + deflection tracking after launch.

Note it states a range and assumptions, not a single confident number — that honesty survives CFO scrutiny and sets up measuring realized value post-launch (measured ROI renews the relationship).