The €40,000 question: how to calculate whether an AI automation is actually worth building.

Most AI automation pitches we see are wrong about the same thing. They overstate the labour saving, they ignore the error cost, they treat opportunity cost as if it doesn't exist, and they price the build as if the model and the prompt and the workflow will still be working a year from now without anyone touching them.

We've watched companies sign €40,000 build contracts for automations that were going to save them €11,000 a year, and we've watched companies refuse to spend €4,000 on automations that were quietly costing them €60,000 a year in opportunity cost they couldn't see on any P&L. The point of this piece is to show you the model we run internally before we accept a project, line by line, with the numbers we actually use.

It is not a complicated model. It has four columns. But each column has one or two terms that almost everyone forgets, and the forgetting is what produces the bad decisions.

01 · The four columnsWhat every automation decision actually weighs

Every automation decision, in our experience, reduces to four numbers being weighed against one number. The four are: labour cost saved, error cost saved, opportunity cost unlocked, and decay cost incurred. The one is build-and-run cost. If the four-column sum exceeds the one for long enough, you build. If it doesn't, you don't. The whole point of this piece is to make each of those numbers honest.

02 · Labour costThe one everyone gets wrong

Almost every AI vendor pitch starts with labour cost saved, and almost every one inflates it the same way. They take the time the task currently takes, multiply it by the salary of the person doing it, and call that the saving. It produces big numbers. It is also wrong on three axes.

The first error is using salary instead of loaded rate. A €45,000-a-year employee in Spain costs the company closer to €62,000 once you add social security contributions, holidays, sick leave, the share of the office and equipment they consume, and the manager's time supervising them. If you use salary alone, you are understating the saving by roughly 35%. That cuts in your favour, but it also means you are doing the maths wrong, and you will eventually meet a CFO who does it right and is not impressed by your earlier numbers.

The second error is using the wrong unit. The right question is not "how much time does this task take" but "how much time would this task take if it were done well". A lot of the work that automation displaces was already being done badly because the person doing it was rushed, or bored, or interrupted. The honest comparison is against the quality-adjusted version of the human task, which is often slower than what's actually happening today. This sounds like it argues against automation, and sometimes it does, but more often it argues for it: you discover that the human version is producing a substandard output that you've been quietly tolerating, and the automation pays for itself partly by raising the floor.

The third error — and this is the big one — is forgetting that the labour does not always actually go away. If you automate 40% of a sales coordinator's job, and the coordinator now spends that 40% on something else useful, that is a real saving. If they spend it on something that doesn't matter, or you can't measure, then you have not saved €25,000 a year, you have given someone a less stressful workday. That may still be a good outcome, but it does not show up on the P&L, and you should not pretend otherwise when you build the model.

Our internal rule on labour cost: we only count time that is being meaningfully redeployed (we agree in advance with the client what the freed person will do instead, and we put it in writing), or time that lets us avoid hiring the next person we would otherwise need. Everything else is filed under "soft benefit, do not include in payback calculation".

03 · Error costThe one everyone forgets

Manual work makes mistakes. Automated work makes mistakes too, but they are different mistakes — typically rarer, more uniform, and easier to fix at the source. The interesting question is whether the cost of the new mistake distribution is lower than the cost of the old one.

Almost no client has good data on this. They know what their error rate feels like; they don't know what it costs them. So we estimate. We pick three or four representative error types from the manual process — a sales lead routed to the wrong territory, an invoice issued with the wrong VAT rate, a support ticket misclassified — and for each one we estimate three things: how often it happens (per month, conservative), what it costs to detect (often the biggest hidden cost, because someone is reading 200 invoices to find the four wrong ones), and what it costs to remediate per occurrence (refund, rework, customer apology, lost trust).

The output is a number, in euros per month, that the existing manual process is silently costing. Nine times out of ten it is larger than the labour cost of the process. Sometimes it is much larger. We had a client whose accounts receivable team was costing about €4,200 a month in salaries and was leaking about €11,000 a month in late-payment write-offs because invoices were going out two to three weeks late on average. The automation that fixed the timing problem paid for itself in 11 weeks, almost entirely on column two, before column one had moved at all.

Nine times out of ten, the error cost of a manual process is larger than the labour cost of the process — and almost no client has measured it.

— Internal heuristic · 184 engagements

The trap in column two is symmetric: AI systems also make mistakes, and you need to estimate that too. Honestly. Our heuristic is that for well-bounded tasks (categorisation, extraction, routing) a properly evaluated AI workflow runs at 1–4% error rate after the first month of tuning, depending on the difficulty of the task. For unbounded tasks (open-ended drafting, judgement calls, novel situations) the rate is much higher and the failure modes are harder to spot. We discount column two harshly when the task is not well-bounded, and we sometimes set it to zero.

04 · Opportunity costThe one everyone underestimates

This is the column where the big numbers live, and it is also the column where almost no one bothers to do the work. Opportunity cost is the value of the things you can now do that you genuinely could not do before. Not "could do faster". Could not do at all.

A staffing firm we work with used to send candidate shortlists to clients within 72 hours of receiving a brief. After we built them an automation that ingested the brief, ran it against their CV database, drafted the shortlist with reasoning, and put it in front of a recruiter for review, they started sending shortlists within 90 minutes. The labour saving was real but modest, maybe €1,800 a month. The opportunity cost saving — the contracts they won because they were the first response a client received, when previously they were always third or fourth — was approximately €18,000 a month inside six months. We could not have predicted that number in advance with any precision. We could predict the direction, and we could put a defensible floor on it by talking to two of their existing clients about what faster turnaround would have been worth.

The way we estimate column three is by looking for things the client would want to do but currently can't, because the manual version is too slow, too expensive, or too uneven in quality. Then we ask what the value would be if they could. We discount that number heavily — usually 50–70% — because opportunity cost numbers are inherently speculative. But we include it. Excluding it produces wrong answers in both directions: it kills good projects and lets through bad ones. The bad ones are usually labour-saving plays in functions where the saved time has nowhere to go.

05 · Decay costThe one no one talks about

This is the column that most ROI models pretend doesn't exist, and it is the reason a lot of automations that look great in year one are hated by year three.

An AI automation is not a piece of equipment that depreciates predictably. It is a process glued to a model, which is glued to a prompt, which is glued to a set of source systems, which are all moving at different speeds. The model gets deprecated; the prompt drifts as the team starts asking for more from it; the source systems are migrated, restructured, or sunset; the regulatory environment shifts; and the underlying business changes shape. Every one of these is a maintenance event waiting to happen, and if you don't budget for it, you will discover that the automation that was saving you €38,000 a year now costs €18,000 a year to keep working.

The decay column is a negative number. Every automation we ship has a maintenance budget attached, expressed as a percentage of the build cost per year, and we do not call a project profitable unless the four-column sum still beats the build-plus-maintenance cost over a defensible time horizon. Our default assumptions, which we revise per project:

• Maintenance budget: 12–18% of build cost per year, depending on how many external systems the automation depends on. A workflow that touches one CRM and one email account is at the low end. A workflow that touches a CRM, an ERP, a document store, and a third-party scoring API is at the high end, because four interfaces are four things that can change underneath you.
• Model upgrade events: plan for two during a three-year horizon, each costing 5–10% of original build cost (re-evaluation, prompt adjustment, output validation against the previous model's behaviour).
• Prompt and policy drift: assume the team will want to expand what the automation does within six months. Either you budget for those expansions or you accept the original scope is the only scope. Neither is wrong; both need to be priced.
• Sunset cost: at some point you will turn this thing off. Migration of in-flight cases and the audit trail back to a manual process or a successor system has a real cost, typically 5–8% of build, and it is worth pricing it now rather than discovering it in year four.

If you do not include a decay column, your three-year ROI estimate will be wrong by 25–40%. We have never seen a client do this on their own.

06 · Build & runThe single column on the right

This one is the most concrete and is therefore the easiest to argue about. We break it into five lines:

The first is build cost, which is what we charge to ship the first working version. Most of our SMB automations land in the €6,000–€28,000 range depending on integration complexity. The biggest single driver is not model selection or prompt engineering — it is the number of source systems that have to be wired in and the cleanliness of their APIs.

The second is infrastructure cost, which is the model API spend, hosting, observability tooling, and any third-party services the automation calls. For a typical SMB workflow handling 500–5,000 events a month, this is €40–€400 a month, dominated by inference cost. We instrument every automation we ship so the client can see this number going up and down in real time and react to it.

The third is maintenance retainer, which we discussed above as a percentage of build cost. We strongly recommend clients put this on a retainer rather than calling us every time the automation breaks, because the retainer model means small drifts get caught early when they're cheap, instead of accumulating into one expensive emergency.

The fourth is internal time cost: someone on the client side has to own this thing. Reviewing edge cases the automation is uncertain about, approving suggested expansions, providing the institutional knowledge that the automation needs to stay accurate. This is typically 1–4 hours a week of someone competent. It is real cost. It is almost always omitted from vendor pitches.

The fifth is change management cost: training, documentation, the meeting where someone explains to the team why this is happening, the help desk burden in the first month while people work out how to use it. This is a one-time cost, but it is not zero, and we usually budget 8–15% of build cost depending on how many people the automation affects.

Add these up and you have a number that is much larger than the build quote you were originally given. That is the point of doing this exercise: the build quote is the first 60–70% of the actual cost, not the whole thing.

07 · Worked exampleThe model run on a real engagement

Here is the model we ran for a real engagement, with figures lightly anonymised. The client is a 22-person logistics broker in Madrid; the automation in question routes incoming shipment requests from email and a web form to the right operations team and drafts an initial response with pricing.

The story this table tells is the story we want every client to be able to read. The labour saving is real but not heroic. The error saving is meaningful. The opportunity column is what turns the project from "marginal" into "clear yes". The decay is small but acknowledged. The cost side includes everything, not just our invoice.

Notice in particular two lines: the internal owner time (€7,200/yr) is the single largest cost on the right-hand side, larger than what we charge the client for the build amortised. If you don't price your own people's time honestly, you can convince yourself any project pays back. And the change management line, while small, is a one-time cost that almost every model omits and that has killed at least three projects we've seen at other firms.

08 · SensitivityHow we stress-test the model

A model that produces a single number is a model that is going to be wrong. Once we have the four-and-one structure populated, we re-run it three times: with the opportunity column at zero, with the labour column at half, and with maintenance at double. If the project is still net positive in all three sensitivities, we say so and we recommend it. If it falls over in one sensitivity, we flag the dependency. If it falls over in two, we usually walk away or restructure the scope.

The Madrid logistics example survives all three of those. Net of the opportunity column entirely, it is still €5,800/yr positive, with a 35-month payback. Net of half the labour saving, it is €19,300/yr positive. With doubled maintenance, it is €25,900/yr positive. We told the client, in writing, that the project was robust to those three failure modes and not robust to a regulatory change in the broker industry that altered the routing logic, which would force a rebuild of about 40% of the prompt-and-validation layer. Two years in, that hasn't happened. If it had, they would not have been surprised.

09 · RestatedThe €40,000 question, in one paragraph

We called this piece "the €40,000 question" because that is the rough median value of the projects where we see clients make the worst decisions in either direction. Below €15,000, the cost of getting it wrong is small enough that it's faster to just try. Above €80,000, almost everyone slows down and asks the right questions. The €25,000–€60,000 range is where pitch energy and finance scrutiny meet and produce the largest mistakes — projects that look like a no-brainer because the labour cost saving alone justifies them, and projects that look like an indulgence because the labour cost saving alone doesn't.

The model in this piece is what we use to make those calls honestly. It has four columns and one column. The four columns each have a trap, and the one column has five lines. If you carry only one thing away from this, carry the four columns: labour, error, opportunity, decay. If you can put a defensible number against each of them — and discount the speculative ones harshly — you will make better automation decisions than 80% of the SMB market, including most of the ones spending much more than €40,000 on this stuff.

Below €15,000 it's faster to just try. Above €80,000 everyone slows down. The €25,000–€60,000 range is where pitch energy meets finance scrutiny and produces the largest mistakes.

— Why we called it the €40k question

If you want us to run this model on a project you're considering, send us the brief. We do the first pass for free; we have an obvious bias to be optimistic, and we tell you about it; and we will tell you when we think the answer is "don't build this".