Return on Investment (ROI)

What Return on Investment means

Return on investment, as the site uses the term, is what an AI tool or workflow returns against what it costs. The return is usually counted in time saved, cost reduced or revenue gained, together with the time it takes to pay back. It can only be shown against a baseline taken before the tool arrived.

This page is about how to measure it honestly. It does not promise a result. The site never states a saving, a payback or a return as its own claim, and the figures quoted below come from articles the site publishes, which attribute them to outside research. They show what has been reported elsewhere, not what any business will get.

Time saved, cost reduced, revenue gained

The three kinds of return are different measurements and they should not be mixed in one number. Time saved is the one most small teams start with, because it can be timed. Cost reduced needs the full cost of running the tool, which is the subject of total cost of ownership. Revenue gained is the hardest to attribute, because many things move revenue at once.

The well-scoped workflow article gives the practical rule for all three. Tie the measurement to a business outcome someone already tracks, and take the baseline before building anything, because the return only shows up clearly when there is something specific to compare it against. See business outcomes for judging AI by results the business cares about.

Why a baseline comes first

If nobody timed the task before the tool arrived, the only evidence left is opinion. The time-saving article says this plainly. You cannot prove a saving without a baseline, and any saving claimed later rests on memory.

It lists three habits that keep the gap between feeling and proof open. No baseline was taken. Success was never defined, so usage became the result and the tool had succeeded the moment it was opened. And time saved was self-reported, which produces a confident, friendly number that nobody can check. Each is easy to fix once it is visible.

Feeling faster is not being faster

The time-saving article reports a 2025 randomised trial by an independent research group. Experienced developers expected AI to speed them up. The measured result was that they took longer with it, and they still believed it had made them faster. The article is careful to say that this is a narrow study of one kind of skilled work, that it should not be stretched to every tool and team, and that it does not show AI is slow. What it shows is that the feeling of speed can run the opposite way from the clock, so the only way to know is to measure your own task.

It also reports a 2026 survey of large-company executives in which most said AI had sped up work, while only a small share could point to an organisation-wide return. The survey’s own explanation is that the extra output queues at the same reviews and approvals as before, so the gain is absorbed on the way through.

Where the time goes

When an AI tool is introduced, the time a task takes does not shrink by the amount the AI step shrinks. The article says time moves into four places: checking, fixing, re-prompting and handoff. A saving exists only if the sum of all four, plus the AI step itself, is smaller than the old total.

The running cost article makes the same point from the cost side. Human review can cancel the saving if checking takes nearly as long as doing the work. Its lesson is to review by risk and not by habit: a low-risk step may need only a sample check, while a step touching money, a contract or personal data needs a person first. Count the time of everyone who touches the work, not only the person at the keyboard, because a task can look faster for the user while the checking lands on a colleague.

The cost side

A return is a ratio, so the cost has to be honest too. The running cost article lists what goes into it: model usage, platform, human review, maintenance and governance. It warns that a workflow used more costs more to run, so a rising bill is a sign of success only if the value rises with it. Its advice is to ask for the cost per completed task and not the cost per model call, because the first is what the business actually pays.

Why Narrow Workflows return more

The central point of the well-scoped article is measurability. A defined, single-purpose workflow produces a number that can be measured. A general rollout across an organisation usually does not. The definition on this page says the same: the return concentrates where a workflow is narrow and well scoped, and a broad, loosely defined rollout is where it goes missing.

The article’s advice follows from that. Start with one process with a clear input, a clear output and a review point, where a human in the loop checks the result before it goes on. Treat scope, the core of workflow design, as the decision that determines the result.

What the published figures say, and what they do not

The well-scoped article reports an analysis of 200 AI projects across French SMEs, with a median return on investment of 159% and an average payback of 6.7 months. It sets that against the vague aggregate adoption statistics that dominate coverage, and puts the difference down to scope. It also reports independent research on average time savings across regular AI users, which it calls an average across a wide range of use cases.

These are third-party figures, reported by an article that cites outside sources, and the site has not measured them. They do not describe any particular business, and a median is not a forecast. Their use here is to show why scope matters, not to set an expectation. A business’s own number comes from its own baseline.

Measuring one task

The time-saving article gives a test that needs no dashboard. It has five steps: pick one task with a clear start and finish, time it for a week before the tool, define success in one sentence and say where the released hours will go, time the whole cycle with the tool, and re-check at 30 days. The re-check matters because early results flatter a new tool. If the saving holds at 30 days and quality has not fallen, the return can be defended.

Two details keep it honest. Record times as they happen and not from memory, and have someone other than the tool’s champion look at the results. Agree what the same quality means in advance. A workable test is whether the reviewer would sign the output off unchanged.

Keep, scale, switch or drop

The article ends each review with one of four verdicts. Keep, when the whole cycle is shorter at the same quality. Scale, when the saving is clear and the task is common elsewhere, measuring the next one the same way. Switch, when one part of the cycle is eating the gain. Drop, when the cycle is no shorter or quality has fallen. The article calls dropping a good result, not a failure, because a few weeks of testing avoided paying indefinitely for a tool that does not earn it. Set the review date in advance, since a tool with no scheduled review tends to stay by default.

A worked example

This is an illustration, not a real client. A small firm wants to know whether an AI tool is worth keeping for its weekly customer reports. It times the report for a week before the tool, with the same people who will use it. It writes one sentence: the same quality in less total time, with the released hours going to a backlog of customer calls.

With the tool, it times the whole cycle, including the prompt, the checking, the fixing and the sign-off. It re-times at 30 days. The drafting is quicker but the checking has grown, and the net saving is smaller than people believed. The firm keeps the tool for the reports and does not extend it yet. The number it holds is its own, and it is what the next decision is made against.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is counting usage as return. A tool is not succeeding because it is opened. The second is quoting a published median as the business’s expected return. The third is counting only the AI step and leaving out checking, fixing, re-prompting and handoff. The fourth is counting only the subscription as the cost.

Where it goes wrong

One failure is a broad rollout with no defined scope, where the return goes missing because there is nothing specific to measure. Another is self-reported savings that nobody timed. A third is an unassigned saving: hours released with no named use are absorbed by whatever is urgent and never seen.

The last is measuring once. Early results flatter a new tool, and a saving that has faded by 30 days was novelty. It is better to learn that early than after the tool has been rolled out to everyone.

Where it appears in an Audit

The time-saving article names an AI audit as one way to get the baseline a return is measured against, since it looks at where AI is already in use and what each task really takes from end to end. An audit does not promise a figure in advance. It produces the documented process a figure can be measured against.

If you want a baseline for a specific task, a discovery call is the quickest way to find the first process worth measuring.

Sources

• Is your AI tool actually saving time?: the baseline, the three habits, the 2025 trial and the 2026 survey as it reports them, where the time goes, the five-step test and the four verdicts.
• Well-scoped AI workflow: measurability, the 200-project analysis with its median return and payback as it reports them, and starting with one process.
• How much does an AI workflow actually cost to run?: the cost categories, review labour, cost per completed task and the rising-bill point.
• How we audit: the baseline an audit produces.