Where AI actually pays back

Across the 97 projects we have delivered, the typical payback period of an implementation sits between six and twelve months, and cost reduction in a working scenario lands at 30–60%. Those numbers are real, but they are not a property of the technology. They come from the choice of process. The same language model can save a team a fifth of its week in one place and produce nothing but review work in another.

So the first phase of every engagement is not a prototype. It is two weeks of counting: who does what by hand, how often, how long it takes and what a mistake costs. Below is the checklist we run through. If a process fails more than two of these questions, we usually say so and suggest a different one.

1. Can you count the hours?

“Our managers spend a lot of time on reports” is a complaint, not a business case. “Each teacher spends three to four hours a week writing assessments, and there are forty of them” is a business case. You need the volume (how many times a week), the duration (minutes per item) and the people involved. If nobody can estimate these within a factor of two, the first job is to measure, not to automate.

2. Is the task repetitive in structure, not just in name?

Models are good at tasks that look different on the surface but share a skeleton: a lead from a messenger always needs a budget, a location and a timeline; a student report always covers progress, behaviour and next steps. They struggle with tasks that are unique every time — negotiating a one-off contract, designing a new product line. Look for the skeleton.

3. Is there data — and can you actually get it?

Historical examples of good output are worth more than any amount of prompt engineering. Ask where last year's reports, calls, invoices or tickets live, who owns them and whether they can be exported without a six-month security review. Data that exists but can't leave a legacy system is, for planning purposes, data that doesn't exist.

4. Who checks the result today?

The fastest wins come from processes where a human already reviews the work. If a senior manager reads every proposal before it goes out, a model that drafts the proposal fits straight in: the review step stays, the drafting time disappears. If nobody checks the output today, you will need to design a check — and that is real cost.

The question is never “can a model do this?”. It is “what does a mistake cost, and who catches it?”

5. What does an error cost?

A wrong line on a coffee cup is a funny anecdote. A wrong figure in a credit decision is a regulatory problem. Neither is a reason to stop, but they lead to very different architectures: in the first case the model publishes and a human samples; in the second the model recommends and a human decides. Write the cost of an error down in money or in hours of cleanup.

6. Will the process still exist in a year?

It sounds obvious, yet we regularly see automation proposed for a workflow that is about to be replaced by a new CRM, merged after an acquisition or outsourced. Payback over 6–12 months needs the process to survive that long in roughly its current shape.

7. What number means “stop”?

Before the prototype, agree on the threshold that kills the project: “if the model's drafts need more than five minutes of editing on average, we stop”, or “if fewer than 70% of leads are classified correctly on the held-out sample, we stop”. Teams that skip this step end up debating impressions after the pilot instead of comparing a metric with a line drawn in advance.

A worked example

Here is how the arithmetic usually looks, with round illustrative numbers. A sales team of ten handles 600 inbound inquiries a week. Each one takes a manager about eight minutes to read, ask the first clarifying questions and enter into the CRM — that's 80 hours a week, two full-time people's worth of work spent before anyone has had a real sales conversation.

A model that drafts the first reply, asks the standard questions and fills in the CRM fields won't remove all of that. Managers still review the qualified leads, and some inquiries are too unusual to automate. If it removes 60% of the time on 80% of inquiries, that's roughly 38 hours a week back. Now put the cost of building, integrating and running the system next to the cost of those hours, and you have a payback period you can defend in a budget meeting — or a clear reason to pick a different process.

Two things are worth noticing. First, every number in that calculation can be checked in a week of observation. Second, none of it depends on which model you use. The model choice comes later and matters less than people expect.

Red flags

• “We want to use AI somewhere.” Start from a cost, not from a technology.
• Nobody owns the process. If three departments touch it and none is responsible, the project will stall in approvals.
• The success metric is “the team likes it”. Liking is good; it isn't a payback period.

Putting it together

A good first process usually looks unglamorous: frequent, structured, already reviewed by someone, with a year of examples sitting in a shared drive. The work we did for Heritage School is a typical shape — reports written from teachers' notes, transcription of lessons and meetings, an automatically built timetable. None of it is exotic; together it freed 3–4 hours a week per teacher and turned a two-week timetable job into twenty minutes.

If you want to run this checklist on one of your own processes, bring the numbers you have. Rough is fine — that is what the first two weeks are for.

Case · EdTech · LLM

Heritage School

An AI platform for teacher reports, lesson transcription and timetables. Freed up 3–4 hours a week per person