Helium – AI automation agency logo
Helium – AI automation agency logo
Helium – AI automation agency logo
Helium – AI automation agency logo

The Real ROI of AI Automation for Small Businesses

Research published in 2025 found the overwhelming majority of enterprise AI pilots produced no measurable financial return. The reasons are unglamorous, and they are the same reasons small-business projects fail.

In July 2025, MIT’s Project NANDA published research on enterprise generative AI adoption that produced an uncomfortable headline: despite an estimated $30 to $40 billion of enterprise investment, roughly 95% of projects had produced no measurable return. Around 5% were delivering real value.

It is worth being careful about what that does and does not say. It is a study of large organisations, not twenty-person companies, and "no measurable return" often means nobody set up a way to measure rather than that nothing happened. But the direction is hard to argue with, and the reasons behind it apply at any size.

Why most of it produces nothing

The failures are not technical. Three patterns cover most of them.

The project was scoped to a demonstration. Somebody chose the use case that would look impressive rather than the one that costs money every week. Impressive use cases tend to be rare events, which means the system runs occasionally, nobody builds a habit around it, and it quietly stops being used.

It was never connected to anything. A tool that produces good output which then has to be copied into the system where the work actually happens has not removed the work. It has added a step and moved the effort.

Nobody owned it after launch. Processes change. If no one is responsible for noticing that the system is now doing the wrong thing, it degrades until someone switches it off.

None of these are failures of the technology. They are failures of scoping and ownership, which is encouraging, because both are fixable in an afternoon of decisions. The businesses getting real value from AI are rarely the most technically ambitious. They are the ones who pointed it at a job somebody already does every day.

What ROI actually means at your size

In a twenty-person company, "hours saved" is usually a fiction. If automating a task frees four hours a week and nothing changes about what that person does with the four hours, you have saved nothing. You have made a job slightly more pleasant, which is worth something, but it does not appear anywhere.

Automation pays in a small business through one of three routes, and it is worth knowing which one you are buying:

  • Revenue you were losing. Enquiries that went unanswered, follow-ups that stopped at message two, quotes that took four days. This is almost always the biggest number and the hardest to see, because nobody counts the deals they never knew about.

  • A hire you no longer need to make. Not a redundancy. A role you were about to advertise because the volume had grown past what the current team could hold.

  • Capacity released to billable work. Real only if the freed time actually goes somewhere that earns. In a services business with a backlog, that is straightforward. Without a backlog, it is not.

If a proposed automation does not map to one of those three, it may still be worth doing for sanity or accuracy. It is not an ROI case, and calling it one is how projects lose credibility internally.

Where it pays quickly

The fastest returns tend to come from the least interesting places.

Response speed on inbound enquiries. This is revenue recovery rather than cost saving, and the effect is immediate. Nothing else on this list moves the number as fast.

Chasing things. Documents, signatures, information from clients. Someone is doing this by hand every week and it is pure administrative cost with a direct effect on how long jobs take to close.

Assembling the same report every month. If a person spends half a day pulling numbers out of four systems, that half-day is recoverable in full, every month, and the output is usually more accurate.

Moving information between systems. Unglamorous, invisible, and constant. It rarely feels like a priority, which is exactly why it is still being done by hand.

Where it does not

Anything running monthly or less. The build cost outlives the process.

Work that genuinely varies every time. If your team cannot describe the rules, a system cannot follow them. That is a process problem first.

Anything replacing a judgement your clients are paying you for. Automating the thing you are actually hired to do is how you become interchangeable.

Sizing it before you spend

Four questions, answerable in an afternoon, filter most bad ideas out:

  • How many times a week does this happen? Under five, be sceptical.

  • What does it cost when it goes wrong or gets missed? Include the deals lost to slow replies. This number is usually larger than the labour cost and is the one people forget.

  • Who owns it in six months? If the answer is nobody, the value has an expiry date.

  • What would we measure to know it worked, and can we measure it today? If you cannot establish the before, you will never prove the after, which is precisely how 95% of projects end up with "no measurable return".

Start with one

The single most reliable predictor of whether automation pays is scope. One process, running daily, connected to the systems you already use, with somebody's name against it and a number agreed in advance.

That is a far less exciting plan than a transformation programme, and it is roughly the difference between the 5% and everyone else.

Working the arithmetic yourself

The fastest way to know whether something is worth building is to do the sum before anyone quotes you. Use your own figures. The point is the shape of the calculation, not the numbers.

Take inbound response speed, since it is usually the biggest item. Count the enquiries you receive in a month. Estimate honestly what share currently get a reply within an hour, and what share wait until the next working day. Take the ones that wait, and apply your normal close rate to them, then apply your average deal value.

Now assume you recover some fraction of the waiting group by answering immediately. Not all of them, and not because a faster reply is magic, but because some of those people bought from whoever answered first. Even at a conservative fraction, most service businesses find this number is larger than the entire cost of the system, and larger than every efficiency saving on their list combined.

Then do the same for the administrative work, which is easier. Hours per week, multiplied by the loaded cost of the person doing it, multiplied by fifty. That number will be smaller and more certain. Both belong in the case, but be clear with yourself about which one you are actually buying.

What to ask before you buy anything

Five questions separate a system that will still be running next year from an expensive experiment.

  • What does it connect to, and who maintains those connections? The integration is where value is created and where things break.

  • What happens when it fails? If the answer is anything other than "it retries, then tells a named person why", it will fail silently and you will find out from a client.

  • What are we measuring, and what is it today? Insist on the baseline before the build. Without it you are guaranteed to end up in the majority with no measurable return.

  • Who can change it in six months without calling you? Processes move. A system only its builder can edit has a short life.

  • What happens to our data and our logic if we stop working together? Ask early, while the answer is cheap.

The honest summary

Automation is not a bet on technology any more. The tools work. It is a bet on scope and follow-through, and both are ordinary management decisions rather than technical ones, which is why they are within your control.

Businesses that pick one daily process, connect it properly, agree a number in advance and give it an owner tend to get their money back quickly and then do it again. Businesses that buy capability and hope a use case emerges tend to end up in the 95%. The difference is decided before anything is built.

AI Optimize scopes to a job somebody already does every day, connects it to the tools you already pay for, and agrees the measure before the build. That work sits under Workflow Automation.

Sources
  • Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari, The GenAI Divide: State of AI in Business 2025, MIT Project NANDA, July 2025. Based on a review of over 300 publicly disclosed AI initiatives, 52 structured interviews and 153 survey responses from senior leaders, conducted between January and June 2025.

Related reading

WHAT WE BUILD

This is the part we solve