To calculate the ROI of an AI project before you commission the build, use this formula: year-one return = (hours saved per week x loaded hourly rate x 47 working weeks) minus the total cost of ownership, then divide net benefit by total cost and multiply by 100. A typical UK SME build costs £15,000 to £80,000, but hidden costs (data preparation, integration, change management, ongoing tokens and licences) consume 40 to 60 percent of stated budgets, which is why an estimated 70 to 85 percent of AI initiatives miss their projected value. The decision rule is simple: a year-one ROI above 150 percent is a green light with a payback of four to five months; 80 to 150 percent means proceed only with a second value lever; below 80 percent, pause and rescope. Always write the baseline "before number" down, with a stopwatch and a witness, before a single pound is spent.
Last updated: June 2026
Because the decision you cannot reverse is the one to spend the money, and once a five-figure invoice is paid you stop asking whether the project was worth it and start asking how to justify it. Calculating ROI before the build is the only point at which the answer can still be "no" without anybody losing face or money. Most UK businesses we speak to commission AI projects on a feeling, a competitor's press release, or a convincing demo, and then discover six months later that the numbers never stacked up. The calculation is not a formality. It is the single piece of due diligence that separates an investment from a gamble.
Here is the honest rule we apply: if a vendor cannot help you build a defensible ROI model before you sign, they are selling you software, not outcomes. A genuine automation partner wants the model built first, because a project that pays back fast is the best thing that can happen to their reputation. Be sceptical of anyone who waves the ROI question away with "the efficiency gains will be obvious once it is live". Obvious to whom, measured how, against what baseline?
The stakes in 2026 are not theoretical. Industry surveys suggest that 42 percent of UK companies abandoned the majority of their AI projects during 2025, with data readiness cited as the leading cause, while around 66 percent of organisations admit they struggle to establish ROI metrics at all. When two thirds of buyers cannot measure return, the market is effectively running on hope. A pre-build calculation is how you opt out of that statistic.
There is also a procurement benefit. When you arrive at a vendor with a baseline already documented and a target ROI in mind, the entire conversation changes. You stop being a buyer who can be talked into scope and become a client who is buying a specific, measurable outcome. The vendor's incentive shifts from maximising the contract value to hitting the number, because the number is now written down and shared.
The pre-build calculation does three concrete jobs:
Do this work and you join the minority of buyers who commission AI on evidence. Skip it and you are betting the budget on a demo.
The core formula is ROI percent equals net benefit divided by total cost, multiplied by 100, where net benefit is the year-one financial return minus the total cost of ownership. For a labour-saving automation, the year-one return is the most reliable input because it is grounded in hours you can actually measure: hours saved per week, multiplied by the loaded hourly rate of the person doing the work, multiplied by 47 working weeks (the realistic UK figure once you remove holiday, bank holidays and typical sickness from 52).
Written out, the two equations you need are:
The word "loaded" is doing heavy lifting. The loaded hourly rate is not the salary divided by hours. It is salary plus employer National Insurance, plus pension contribution, plus a realistic overhead allocation for software, desk space, management time and equipment. A £30,000 administrator does not cost £30,000 to employ. Add roughly 25 to 30 percent for employer NI and pension, then an overhead multiplier, and the true loaded cost is frequently 1.4 to 1.6 times the headline salary. Using the salary alone is the single most common way businesses understate their own ROI and then wonder why the project looked marginal on paper.
The table below converts common UK salaries into a defensible loaded hourly rate, assuming a 37.5-hour week and 47 working weeks.
| Headline salary | Loaded annual cost (x1.5) | Annual hours (37.5 x 47) | Loaded hourly rate |
|---|---|---|---|
| £26,000 | £39,000 | 1,763 | £22 |
| £32,000 | £48,000 | 1,763 | £27 |
| £40,000 | £60,000 | 1,763 | £34 |
| £55,000 | £82,500 | 1,763 | £47 |
| £75,000 | £112,500 | 1,763 | £64 |
Notice the adoption factor in the ROI equation. This is the discipline that most vendor calculators quietly omit. A new system rarely captures 100 percent of the theoretical time saving in year one, because people are learning it, edge cases still get handled manually, and adoption ramps over weeks. Applying an adoption factor of 0.7 to 0.85 to your gross benefit turns a fantasy number into a forecast you can defend in front of a finance director. We will return to this discount in the conservative-modelling section, but build it into the formula from the start.
One more refinement. Not every AI project is a pure labour-saving play. Some generate revenue (an AI chatbot that captures and qualifies leads out of hours), some reduce risk (fewer compliance errors), and some improve agility (faster turnaround that wins more work). For those, the benefit line is built from a proxy metric: leads captured times conversion rate times average order value, or errors avoided times average cost per error. The formula structure is identical. Only the benefit input changes.
You establish the baseline by physically measuring the current process with a stopwatch and a witness, then writing the result down before any build begins. This "before number" is the foundation of the entire calculation, and it is also the line item finance will challenge hardest, so it has to be evidence, not estimate. The harsh truth is that most ROI models collapse here: the team guesses that a task "takes about half a day", the real figure turns out to be two hours, and the projected saving was inflated by 100 percent before a line of code was written.
We call the measurement exercise the Business Walk. It is exactly what it sounds like. You sit with the person who actually does the work, you time the task across several real instances, and you record every step including the hidden ones: the chase emails, the re-keying between systems, the corrections, the "quick check with a colleague". The output is a short Hidden Cost Report that finance can audit. Without it, your ROI is an opinion.
Follow this sequence to produce a baseline that survives scrutiny:
The table below shows what a finished Hidden Cost Report row looks like for a single process. Build one row per process you intend to automate.
| Process | Measured time per instance | Instances per week | Loaded hourly rate | Annual cost (47 wks) |
|---|---|---|---|---|
| Quote preparation and follow-up | 40 minutes | 15 | £34 | £15,980 |
| Manual invoice chasing | 25 minutes | 20 | £27 | £10,575 |
| Re-keying orders between systems | 12 minutes | 50 | £22 | £10,340 |
| Answering repeat enquiry emails | 8 minutes | 80 | £22 | £11,029 |
Our view, stated plainly: if you will not invest two days in a proper Business Walk, you are not ready to invest twenty thousand pounds in a build. The baseline is cheap insurance. It costs a fraction of a percent of the project budget and it is the difference between a model your accountant signs off and a model they quietly distrust. The businesses that get burned by AI almost always skipped this step, started from a guessed baseline, and never found out the real saving was half of what the slide deck promised.
A final point on credibility. Date the report, name the people who took the measurements, and store it. When the system goes live, you re-run the same stopwatch exercise on the new process and compare like for like. That before-and-after, both witnessed, is the most persuasive ROI evidence you can produce, and it is what turns a successful project into a case study your board remembers.
The true total cost of ownership is the build price plus every cost the build price hides, and on UK SME projects those hidden costs routinely add 40 to 60 percent on top of the headline quote. The development contract is the visible tip. Beneath it sit integration, data preparation, governance and compliance, change management, and ongoing running costs that continue for as long as the system lives. Model only the build price and your ROI will look brilliant right up to the moment the real invoices arrive.
Break total cost of ownership into one-off costs and recurring costs, and price each line with a realistic 2026 UK range rather than a single optimistic figure.
| Cost category | Type | Typical UK SME range | Why it is easy to miss |
|---|---|---|---|
| Discovery and scoping | One-off | £7,000 - £30,000 | Often unbilled until scope creep hits |
| Core build / development | One-off | £15,000 - £80,000 | The only number most buyers plan for |
| Integration with existing systems | One-off | £8,000 - £40,000 | Legacy CRM and accounting connectors are fiddly |
| Data preparation and cleaning | One-off | £4,000 - £25,000 | Messy data is the silent budget killer |
| Change management and training | One-off | £3,000 - £15,000 | Treated as free; it never is |
| Governance and compliance setup | One-off | £4,000 - £12,000 | UK GDPR, DPIA, audit trail obligations |
| Licences and API / token usage | Recurring | £1,200 - £18,000 / yr | Scales with usage; can spike unexpectedly |
| Maintenance and support | Recurring | £3,000 - £20,000 / yr | Models drift, integrations break, rules change |
Two lines deserve special attention because they are where well-run businesses still get caught out. The first is data preparation. AI systems are only as good as the data feeding them, and SME data is almost always messier than anyone admits: duplicate customer records, inconsistent product names, half-empty fields, three spellings of the same supplier. Cleaning and structuring that data is genuine work, and it is the reason data readiness tops every survey of why AI projects fail. If a quote does not mention data preparation, that cost has not vanished, it has just been left off the page and will land on you mid-project.
The second is governance and compliance. Under UK GDPR, any system processing personal data needs a lawful basis, an audit trail, and often a Data Protection Impact Assessment. The Information Commissioner's Office has published clear guidance on AI and data protection, and getting it wrong is not a minor risk. For most SMEs this is a £4,000 to £12,000 per year obligation once you account for documentation, review and the occasional legal check. Budget it as a line, not an afterthought.
The honest rule on total cost of ownership is this: take the build quote, add the integration and data lines, then add a further 20 percent contingency for the things neither party has thought of yet. If the project still clears your ROI threshold on that loaded total cost, you have a robust case. If it only works on the bare build price, the project is fragile and one surprise away from underwater. Robust projects survive their own surprises. Fragile ones do not.
Here is the full calculation on a realistic example, with nothing hidden. A 28-person UK trades-and-services company commissions an AI system to automate quote generation, follow-up and repeat-enquiry handling. The build is quoted at £18,000. The Business Walk has measured a saving of six hours per week of a co-ordinator's time, whose loaded hourly rate is £45. We will work the gross benefit, apply the adoption factor, load the total cost of ownership, and produce a year-one ROI and a payback period.
Step one: gross year-one benefit. Six hours per week x £45 loaded rate x 47 working weeks = £12,690 in recovered labour. On top of that, the same system captures and qualifies after-hours enquiries that previously went cold. The business conservatively credits two extra won jobs per month at an average margin of £600, which is 24 jobs x £600 = £14,400 of incremental gross profit. The combined gross benefit is £27,090.
Step two: apply the adoption factor. Year one is a learning year. We discount the labour saving and the revenue uplift by an adoption factor of 0.8 to reflect ramp-up, edge cases and the weeks before the team fully trusts the system. Adjusted benefit = £27,090 x 0.8 = £21,672.
Step three: load the total cost of ownership. The £18,000 build is not the whole cost. The table shows the realistic loaded total for year one.
| Cost line | Year-one amount |
|---|---|
| Core build | £18,000 |
| Integration with CRM and accounting | £4,500 |
| Data preparation | £2,800 |
| Change management and training | £2,000 |
| Governance and compliance setup | £3,000 |
| Licences and token usage (year one) | £2,400 |
| 20 percent contingency | £2,800 |
| Total year-one cost of ownership | £35,500 |
Step four: calculate ROI and payback. Net year-one benefit = adjusted benefit minus total cost = £21,672 minus £35,500 = a year-one loss of £13,828. Year-one ROI = (£21,672 - £35,500) / £35,500 x 100 = minus 39 percent. On a strict twelve-month view, this project does not pay back. That is not a reason to abandon it. It is a reason to look at year two, where the one-off costs disappear and only the recurring costs (licences plus support, roughly £6,400) remain against the same or higher adjusted benefit.
Step five: the two-year picture. The table below is the number that actually matters, because AI systems are multi-year assets, not annual subscriptions.
| Measure | Year 1 | Year 2 | Cumulative |
|---|---|---|---|
| Adjusted benefit | £21,672 | £25,736 | £47,408 |
| Total cost | £35,500 | £6,400 | £41,900 |
| Net benefit | -£13,828 | £19,336 | £5,508 |
| Cumulative ROI | -39% | - | +13% |
Year two benefit rises to £25,736 because adoption climbs from 0.8 towards 0.95 once the team is fluent. By the end of year two the project is in the black with a cumulative 13 percent ROI, and the payback point falls around month 19. That is honest. A vendor who told this client they would see payback in four months would be lying, and the client would have lost trust in the system the moment month five arrived without the promised return. The discipline of working the real numbers, including the unflattering year-one loss, is exactly what lets you make a confident decision: this project is a sound two-year investment, not a quick win, and you commission it knowing that.
You model conservatively by never trusting a single number, and instead running three scenarios: a downside case you can live with, a base case you expect, and an upside case you would celebrate. A point estimate is a guess wearing a suit. A three-case model tells you not just what the return probably is, but what happens if the project underperforms, which is the question that actually protects your budget. The discipline here is to make the downside case genuinely pessimistic, because the downside is where businesses get hurt.
The three cases differ on three levers: the adoption factor, the realised time saving, and the revenue uplift. Pull each lever to a defensible low, expected, and high value, and let the model show you the spread.
| Lever | Downside | Base | Upside |
|---|---|---|---|
| Adoption factor (year 1) | 0.6 | 0.8 | 0.9 |
| Hours saved per week | 4 | 6 | 7.5 |
| Extra won jobs per month | 1 | 2 | 3 |
| Year-one adjusted benefit | £11,832 | £21,672 | £32,481 |
The downside case is the one that earns its keep. If the project still makes sense over two years even when adoption is poor and the time saving comes in a third lower than hoped, you have a resilient investment. If the downside case is catastrophic, you either need to de-risk the project before you commission it, or you walk away. Our honest view: any AI project whose business case only works in the upside scenario should not be commissioned. The upside is a bonus, not a plan. Plan on the base case, stress-test on the downside, and treat the upside as the reason to move quickly rather than the reason to proceed at all.
A few principles keep conservative modelling rigorous rather than just pessimistic:
For automation projects that touch your sales pipeline, the upside is often understated rather than overstated, because the value of an AI voice agent that answers every call out of hours compounds with every missed call it converts. Even so, model it on the base case. If the base case clears your threshold, the upside takes care of itself.
The threshold is a traffic-light rule keyed to year-one ROI and payback period: green above 150 percent with a four to five month payback, amber between 80 and 150 percent, and red below 80 percent. These are not arbitrary. They reflect the reality that AI projects carry execution risk, so the return has to be high enough to absorb a project that underperforms its forecast and still come out ahead. A marginal projected return on a risky project is a losing bet, even when the central estimate is positive.
The decision table below is the one we put in front of clients. It converts the calculation into an action.
| Year-one ROI | Typical payback | Signal | Recommended action |
|---|---|---|---|
| Above 150% | 4 - 5 months | Green | Commission. Strong, resilient case that survives the downside. |
| 80% - 150% | 8 - 14 months | Amber | Proceed only if a second value lever (revenue or risk) is added. |
| Below 80% | 15+ months or never | Red | Pause and rescope. The case is too thin to absorb execution risk. |
A crucial nuance: payback period is bimodal in the real world, and which mode you land in depends almost entirely on whether you run a genuine change programme. Projects backed by training, process redesign and a named internal owner typically pay back in five to seven months. Projects where the software is bought and bolted on without a change programme drift to 12 to 18 months, or never pay back at all because nobody adopts them. The UK average for well-run automation consulting work lands around a 2.8 to 3.2 times return over 18 to 24 months. If your model is promising far more than that with no change programme, the model is wrong.
This is where the amber band matters most. An 80 to 150 percent project is not a no, but it is not a yes on labour savings alone. The move is to add a second value lever. A business process automation build that only saves admin time might sit at amber, but the same build that also captures lost leads, reduces a costly error rate, or unlocks faster turnaround that wins more work pushes into green. Our advice in the amber band is always the same: do not lower the threshold to make the project pass, add a lever to make the project deserve to pass.
One stance we hold firmly: never let a red project through on the strength of "strategic importance" or "we cannot be left behind". Those phrases are how marginal projects get funded and then quietly fail. If a project is genuinely strategic, the strategy will show up as a quantifiable lever (defending revenue, opening a market, removing a risk) that lifts it out of red on its own merits. If you cannot find that lever, the strategy is a story, and stories do not pay back budgets.
AI projects fail to deliver because the model assumed clean data, full adoption and a stable process, and the real world delivered messy data, partial adoption and a process nobody redesigned. The maths in the business case is rarely the problem. The execution around it is. When 70 to 85 percent of AI initiatives miss their projected value, the failure is almost never a calculation error. It is a readiness error, and readiness is something you can assess and fix before you commit.
The recurring causes, in roughly the order they bite:
The pattern across all five is the same: the failure was baked in before the build started, in the assumptions, the readiness and the absence of a change programme. None of them are technology failures. This is genuinely good news, because it means ROI is mostly within your control. Get the data ready, run a real change programme, measure the baseline honestly, and keep scope disciplined, and you move from the 70 to 85 percent that miss to the minority that hit. The single highest-leverage thing you can do is treat the change programme as part of the project, not an optional extra, and budget for it accordingly.
Our honest take: be deeply sceptical of any AI proposal that spends ten pages on the model and one paragraph on adoption. The model is the easy part. The change programme is where the return is actually earned or lost, and a partner who treats it as an afterthought is telling you exactly how your project will end.
The Softomate process is built backwards from ROI: we measure the baseline first, model the return before you commit, and only build what the numbers justify. As a London-based AI automation agency in Stanmore (HA7), we have learned that the projects which fail are the ones that skip the calculation, so we have made the calculation the entry point rather than the afterthought. The five stages below are how a typical engagement runs, with fixed-quote pricing so the total cost of ownership is known before the build starts, not discovered during it.
The indicative timeline and pricing below reflect a typical UK SME automation engagement in 2026.
| Stage | Typical duration | Indicative price |
|---|---|---|
| Discovery and Business Walk | 1 - 2 weeks | From £2,500 |
| ROI model and go/no-go | Included with discovery | Included |
| Fixed-quote build | 4 - 10 weeks | From £15,000 |
| Change programme and go-live | 2 - 4 weeks | From £2,000 |
| 90-day re-baseline | 1 week at day 90 | Included |
Whether the right answer is an AI chatbot that handles repeat enquiries, a GoHighLevel automation that runs your follow-up sequences, or a custom CRM that removes the re-keying between systems, the entry point is the same: we measure before we build. The discovery and ROI model stage stands alone, so you can commission just that, get a defensible go/no-go decision, and only proceed to the build if the numbers earn it. That is the opposite of how most agencies sell, and it is deliberate.
A strong AI project returns above 150 percent in year one with a payback of four to five months. Between 80 and 150 percent is acceptable if a second value lever is added. The UK average for well-run automation work is a 2.8 to 3.2 times return over 18 to 24 months, so be sceptical of forecasts far above that with no change programme.
Payback is bimodal. Projects backed by a genuine change programme typically pay back in five to seven months. Projects where software is bolted on without training or process redesign drift to 12 to 18 months, or never pay back because adoption fails. The deciding factor is rarely the technology; it is whether anyone owns adoption.
The most commonly forgotten lines are data preparation, integration with existing systems, governance and compliance under UK GDPR, change management and training, and ongoing token and licence costs. Together these hidden costs add 40 to 60 percent on top of the headline build quote, which is the main reason projects miss their projected ROI.
Measure the current process with a stopwatch across at least five real instances, with a witness present, and record frequency and rework rate. The saving is the difference between this witnessed baseline and the realistic post-automation time. Never guess the baseline; a guessed before-number is the single most common cause of overstated ROI.
The loaded hourly rate is salary plus employer National Insurance, pension and a fair share of overhead, divided by actual working hours. It is typically 1.4 to 1.6 times the headline salary divided by hours. Using salary alone understates the true cost of the work, which understates the saving and makes sound projects look marginal.
Treat it as a starting point, not gospel. Most vendor calculators omit the adoption factor, understate the loaded hourly rate, and leave out hidden costs like data preparation and governance, all of which flatter the result. Rebuild the model yourself with a witnessed baseline and a fully loaded total cost of ownership before you trust any number.
The adoption factor discounts your theoretical benefit to reflect that systems rarely capture 100 percent of the saving in year one, due to ramp-up, edge cases and learning. Use 0.7 to 0.85 for year one, rising towards 0.95 by year two once the team is fluent. Omitting it produces a fantasy number no finance director will accept.
Use 47 working weeks, not 52. Removing annual leave, bank holidays and typical sickness from the year gives a realistic figure for how many weeks the saving actually accrues. Using 52 overstates the annual benefit by around 10 percent and makes the project look better than it is.
Yes. Any system processing personal data needs a lawful basis, an audit trail and often a Data Protection Impact Assessment. For most SMEs, governance and compliance is a £4,000 to £12,000 per year obligation once documentation and review are included. The ICO publishes specific guidance on AI and data protection that you should budget time to follow.
A year-one loss is common and not automatically a reason to stop, because one-off build costs disappear after year one while the benefit continues. Model two years. If the cumulative position is clearly positive and the downside case still works, the project is a sound multi-year investment. If only the upside case works, do not commission it.
Calculating AI ROI before you commission the build comes down to a disciplined sequence: measure the baseline with a stopwatch and a witness, load the full cost of ownership including the 40 to 60 percent of hidden costs, apply an adoption factor of 0.7 to 0.85, and judge the result against a clear threshold. Green is above 150 percent ROI with a four to five month payback; amber, 80 to 150 percent, needs a second value lever; red, below 80 percent, means pause and rescope. Model two years, not one, because the one-off costs vanish after year one and the benefit compounds. Run base, upside and downside cases, and never commission a project that only works in the upside. Do this and you join the minority of UK businesses who buy AI on evidence rather than hope, and who know within 90 days whether the system is delivering. The calculation is cheap. Commissioning the wrong build is not.
Ready to put a real number on your AI project before you spend a pound? Start with a Discovery and Business Walk from our London business process automation team, or talk to Softomate about a fixed-quote ROI model for your specific process.
Written by Deen Dayal Yadav, Founder of Softomate Solutions, a London-based AI automation and software development agency in Stanmore (HA7). With over 12 years building software and automation systems for UK businesses, Deen has seen more projects fail on a guessed baseline than on bad code, which is why every Softomate engagement starts with measuring the before-number rather than selling the build. Softomate Solutions is registered at Companies House and works with SMEs across London and the UK to commission AI only where the numbers genuinely justify it. Learn more about our approach.
We protect the real names of all clients featured in examples and case studies. Every testimonial is from a real client.
More from the blog
Work with us
Book a free 30-minute discovery call with DD and get a personalised automation roadmap.
Softomate Solutions Limited
Deen Dayal Yadav
Online
We use essential cookies to keep the site running. With your permission, we also use analytics cookies to understand how visitors use our site so we can improve it. No data is sold. Privacy Policy
