The formula
Four lines of arithmetic. Everything else on this page is either an explanation of one of them or a warning about how they are commonly abused.
- Annual net benefit
- (hours saved per week × 52 × fully loaded hourly cost) + revenue recovered − annual running cost
- Payback period, in months
- build cost ÷ (annual net benefit ÷ 12)
- First year return on investment
- ((annual net benefit − build cost) ÷ build cost) × 100
- Fully loaded hourly cost
- (annual salary × 1.25 to 1.4) ÷ 1,880 productive hours a year
The 1.25 to 1.4 multiplier converts salary into what the person actually costs the organisation once employer contributions, equipment, software and a share of overhead are included. The 1,880 figure is a full time year after holiday, public holidays and typical absence, and it is deliberately conservative: using 2,080 raises the apparent return by about a tenth and makes the case harder to defend when somebody in finance recalculates it.
A worked example, with the actual numbers
Supplier invoice processing at a mid-sized business. One member of the finance team spends two hours a day keying invoices into the accounting system. After automation, the system extracts and posts the routine ones and queues anything it is not confident about, leaving about ten minutes a day of checking. This is the most common first project we see, so the figures below are representative rather than flattering.
Step one, establish the position before
Two hours a day, five days a week, is 10 hours a week. The clerk is on USD 42,000. Multiply by 1.3 for the fully loaded cost and you get USD 54,600, which across 1,880 productive hours is USD 29 an hour. Ten hours a week at USD 29 is USD 290 a week, or USD 15,080 a year spent on this one process.
Step two, establish the position after
Ten minutes a day of checking is 50 minutes a week, call it 0.8 hours. At USD 29 that is USD 23 a week, or USD 1,210 a year. Hours saved are therefore 9.2 a week, worth USD 267 a week and USD 13,870 a year.
Step three, subtract what it costs to run
Model usage at roughly USD 90 a month and the automation platform at USD 40 a month gives USD 130 a month, or USD 1,560 a year. The annual net benefit is USD 13,870 minus USD 1,560, which is USD 12,310.
Step four, divide by what it cost to build
At a build cost of USD 7,500, the monthly net benefit is USD 1,026, so payback lands at 7.3 months. First year return on investment is USD 12,310 minus USD 7,500, divided by USD 7,500, which is 64 per cent. In the second year the build cost is gone and only the running cost remains, so the cumulative net benefit across two years is USD 17,120.
7.3 months
Payback period on a USD 7,500 build
64%
First year return on investment
USD 17,120
Cumulative net benefit across two years
| Line | Figure | Where it comes from |
|---|---|---|
| Hours before, per week | 10.0 | 2 hours a day, 5 days a week |
| Hours after, per week | 0.8 | 10 minutes a day of checking the exception queue |
| Hours saved, per week | 9.2 | The difference between the two |
| Fully loaded hourly cost | USD 29 | USD 42,000 salary × 1.3, divided by 1,880 hours |
| Gross annual saving | USD 13,870 | 9.2 hours × 52 weeks × USD 29 |
| Annual running cost | USD 1,560 | Model usage and platform, at USD 130 a month |
| Annual net benefit | USD 12,310 | Gross saving minus running cost |
| Build cost | USD 7,500 | One off, quoted before the build starts |
| Payback | 7.3 months | 7,500 ÷ (12,310 ÷ 12) |
| First year return | 64% | (12,310 − 7,500) ÷ 7,500, expressed as a percentage |
When the return is revenue rather than hours
Some automations save no time at all and still pay for themselves, because the return sits on the revenue side. The arithmetic is the same shape but the input is different: take the number of enquiries currently lost, multiply by the conversion rate you achieve on the ones you do reach, and multiply by average order value.
Twenty enquiries a month arriving outside working hours, of which half are currently lost, at a 20 per cent conversion rate and an average order value of USD 900, is ten recovered enquiries, two additional customers and USD 1,800 a month. That is a larger figure than most time savings, and it is also the softer of the two, because it rests on an assumed conversion rate. Where both exist, present them separately and never sum them into a single headline.
Four mistakes that make a business case look better than it is
Counting hours that do not go anywhere
Saving nine hours a week is only money if those hours are redeployed to something measurable or if headcount genuinely changes. If the time simply disperses across the day, the honest case is capacity and accuracy, and it should be argued on those terms rather than dressed as cash.
Ignoring the review time
Almost no automation reaches 100 per cent coverage. The exception queue is real work and belongs in the after column. A model that assumes the process falls to zero minutes is the most common reason a forecast is missed.
Leaving out the running cost
Model usage, telephony, platform fees and hosting are ongoing and scale with volume. On a low value process they can consume a large share of the saving, which is worth discovering during the business case rather than in month four.
Using base salary instead of the loaded cost
This one understates the return, and it is still a mistake, because it makes a genuinely good project look marginal and get declined. Use the loaded figure and show the multiplier you applied.
What to measure after go live
- Completion rate. The share of items the system finished without a person touching them, tracked weekly rather than as a single number at launch.
- Exception rate and its causes, grouped. Three recurring causes usually account for most of the queue, and fixing them is where the second half of the return comes from.
- Error rate found downstream. Items the system completed incorrectly and somebody caught later. This is the number that decides whether the completion rate can be trusted.
- Minutes on the queue, sampled monthly, because this is the figure that quietly grows as volume rises.
- Running cost per item, so that the case still holds when volume doubles.
Our own position, marked as ours
Our published guarantee is stated as we prove return on investment, rather than as a refund promise, and the mechanism behind it is exactly the arithmetic above. Inside the 28 day window that starts the day a system goes live, we measure what the process cost before against what it costs now. If the return is not there, the fee is refunded in full and the system is decommissioned. The figures used in the example on this page are typical for a first build rather than measured results for any named client.
Frequently asked questions
Should saved hours be counted as money if nobody is made redundant?
Only if those hours go somewhere measurable. If the person now handles more volume, serves more customers or stops working late, the saving is real. If the time simply disperses, the honest business case is capacity and error reduction rather than cash, and it should be presented that way.
What hourly rate should be used?
The fully loaded rate, which is salary plus employer contributions, software, equipment and a share of overhead. It is commonly 1.25 to 1.4 times base salary. Using base salary alone understates the return, which sounds conservative but makes the case harder to defend when finance recalculates it.
How long should payback be before a project is worth doing?
Under twelve months is a straightforward decision for most organisations, and under six months rarely needs a committee. Beyond eighteen months the case usually depends on something other than labour hours, such as risk, compliance or revenue that is currently being lost.
How do you measure the return after go live rather than predicting it?
Record a baseline before anything is built: a timed sample of the current process over at least a week. After go live, count the items the system completed without intervention, the items that went to the exception queue, and the minutes spent on that queue. Return is the difference between the two measurements, not the forecast.
What if the automation only handles part of the process?
That is the normal outcome and the arithmetic still works. Model it as a percentage: if the system completes 80 per cent of items unaided, the remaining 20 per cent keeps its original cost. A business case built on 100 per cent coverage is the most common reason a project disappoints.
Related answers
Disclosure, and the only sales pitch on this page
This page is published by a company that sells the thing it describes.
Oxford Crown Technologies builds voice and operations agents for organisations headquartered in London and across the Gulf. We publish these pages as reference material, including market figures that are not ours and that do not always favour us, because a buyer who understands the range negotiates better with everybody, including us. Leadership holding postgraduate degrees from the University of Manchester and the University of Oxford.
Our own builds are fixed fee, live in 14 days, built on accounts in your name, and carry a 28 day money back guarantee. We prove Return on Investment, or you do not pay.
Reviewed 25 July 2026. Market figures change; where this page quotes a range from a third party, the source is named above. Figures described as ours are our published fees or typical results for a first build, not measured results for a named client.