How do you estimate the ROI of back-office automation before spending anything?

You estimate the ROI of back-office automation by measuring how many hours a specific workflow consumes each month, multiplying by your loaded hourly cost, and comparing that saving to the package price. The package, not the vertical, sets the price: Spinner from €2,500 / $2,900 for the build plus a €200–300/month maintenance fee, Bottlenose from €5,000 / $5,900 plus a €300–700/month fee — the full grid is on the pricing page. As a measured reference point: one back-office automation gave a team back roughly 58 hours per month. At these package prices, when the volume is real and the baseline is measured rather than assumed, payback is a matter of months.

That is the whole model. The rest of this article is how to get each of the three numbers right — and how to recognise the workflows where the maths does not work.

Where do back-office hours actually go?

A common pattern in mid-size companies: hours go into reading and retyping. Emails are read by a person and turned into tickets by hand. Invoices arrive as PDFs and get keyed into the ERP field by field. Orders, delivery notes, and contracts are opened, skimmed, and copied into some other system.

Each task is small, so nobody measures it. The volume is the problem: the same five-minute task, hundreds of times a month, spread across several people. No job title says "copy data between systems," which is exactly why these hours rarely show up in any budget line.

The arithmetic needs three numbers

You do not need a financial model. You need three inputs:

• Hours per month the workflow consumes — measured, not guessed.
• Your loaded hourly cost — salary plus employer overhead, from your own finance data.
• The package price — from the published grid, known before you start, plus its monthly maintenance fee.

Then: hours per month × loaded cost = monthly saving. Subtract the monthly maintenance fee, and divide the package price by what is left = payback in months. A published price matters here — if the build is billed by time and materials, the denominator of your payback calculation is a guess.

A worked example, with measured numbers only

An industrial components distributor ran its support inbox by hand. We automated it: 85% of tickets are now created automatically from inbound email, and the team got back roughly 58 hours per month. A build of that shape — extraction from email plus writes into a ticket system, so an integration to build and a supervised flow — is typically a Bottlenose: from €5,000 / $5,900, with a €300–700/month maintenance fee.

So the example calculation is: 58 hours × your loaded hourly cost, per month, minus the fee, against €5,000 once. We will not invent a salary figure for you — plug in your own. At realistic loaded costs for a European or US back office, the payback lands within the first few months. Treat it as an example, not a quote: the 58 hours are that client's measured number, and €5,000 is the grid's entry price for a Bottlenose.

There are secondary effects — the system runs 24/7, so the Monday-morning backlog disappeared. Keep those out of the arithmetic. If the business case only works when you price in soft benefits, it is not a strong case.

Why does payback arrive in months rather than years?

Because good back-office targets share a shape: high volume, clear rules, and a measurable output. The package price is paid once; the saving recurs every month. In another engagement we processed 10,000+ invoices with 100% automation — at that volume, a one-time build against a recurring manual cost pays back quickly, and the system also surfaced real fraud that manual entry had missed.

Running costs matter too, and they sit on the price list rather than in the fine print: the maintenance fee — €200–300/month on a Spinner, included by default; €300–700/month on a Bottlenose — is the recurring cost to put in your arithmetic, with nothing else to guess at.

What makes an ROI estimate trustworthy?

Measured baselines. An estimate built on vendor benchmarks describes someone else's process, not yours. The 58 hours in the example above were measured in that client's company; your number will be different, and the only way to know it is to count it.

That is why any serious estimate starts from a map of who touches what, how often, and how long it takes, and is then computed workflow by workflow from that map. If a vendor hands you an ROI figure without having measured your baseline first, treat it as marketing.

Where automation is not worth it

An honest estimate has two halves, and the second half is a list of workflows you should not automate. The usual reasons:

• Low volumes. A workflow touched a few times a week will not repay a build, no matter how annoying it is.
• Unstable processes. If the rules change every month, maintenance eats the saving.
• Judgment work. If every case genuinely needs a human decision, automating the decision is the wrong project.

The same logic applies to targets, not just workflows. In support automation, for example, a realistic resolution target is 50-70% — and a plan built on a higher assumption will miss its ROI numbers. If the arithmetic says no, the right move is to not build, and a trustworthy estimate will say so in writing.

Want the numbers for your own back office?

Start with the free AI Audit: five minutes of questions and you will know how AI-ready you are and which workflows are worth counting hours on. Then book a call — a free 30-minute intro call where we go through the arithmetic with you and place the workflow in the right package. The full grid is on the pricing page.