When automation is not worth it, the numbers say so before anyone does. A task pays for automating only when the hours it costs per year beat the build hours, the yearly maintenance and the fixed costs together. Below that line, leaving the work with a person is the cheaper decision.
This is for a founder or owner of a company of five to twenty-five people weighing a first or a next automation. It is about the line under which you do not build, not about how far along you already are. The 5 levels of marketing automation answers that one.
When does an automation not pay for itself?
An automation does not pay for itself when the task costs fewer hours per year than the build, the recurring maintenance and the fixed costs add up to. The sum has two sides and four numbers. Three of those four are yours. Only one of them can be looked up anywhere.
Your side of the sum: how often the task runs, how long one run takes, and your fully loaded hourly cost, which is gross employer cost per hour, not salary. No primary source exists for that last number, so any article that fills it in is guessing about your company.
The automation’s side: build hours once, maintenance hours every year, the fixed platform cost twelve times a year, and usage cost per token if a model runs inside the workflow.
That is why this article gives you no payback period and no average saving. A payback period is the output of your own four numbers; any figure printed before you fill them in belongs to somebody else’s task, at somebody else’s hourly cost.
How often does a task have to repeat before automating pays off?
Often enough that frequency times duration produces more hours per year than the build and the maintenance consume together. That threshold moves with two rates you set yourself, so the honest answer is a formula rather than a number. Fill it in once and most borderline tasks answer themselves.
The formula
Hours by hand, per year = times per year × hours per run. Cost by hand, per year = those hours × your fully loaded hourly cost.
Cost to automate, year one = build hours × build rate, plus maintenance hours × your hourly cost, plus fixed monthly cost × 12, plus usage cost. Every year after that, drop the build hours and keep the rest.
Automate when the cost by hand is larger than both, with margin left to survive your own estimates being wrong. Mapping the process belongs on the cost side too: a WeAdapt Quickscan starts at €995 for one to two weeks [A-006], and the FAQ says what that covers.
A worked example in which every number is an assumption
The task: three times a week, someone copies order confirmations from email into the CRM and the accounting tool.
| line | number in this example | whose number is it |
|---|---|---|
| frequency | 3 times a week, 52 weeks, so 156 runs a year | yours, from the calendar |
| duration | 10 minutes per run, so 26 hours a year | yours, timed once, not guessed |
| fully loaded hourly cost | your own gross employer cost per hour | yours; no source exists for it |
| build hours | 12 hours, once | the builder’s, asked before the start |
| maintenance | 1 hour a month, so 12 hours a year | the builder’s and yours |
| fixed platform cost | a monthly amount, times 12 | the platform’s, see below |
Twelve build hours is in the table because that is what a workflow across two systems costs in our own build practice. It is our number, not a benchmark; yours comes from whoever quotes the job, and if nobody will name it before the start you have your answer already.
Call your fully loaded hourly cost H and the build rate B, because those two are the numbers nobody else can supply. By hand the task costs 26H a year. Then:
- Built in house, where B is roughly H. Twelve build hours plus twelve maintenance hours is 24H, plus twelve months of platform cost. Year one lands on nothing.
- Built externally at twice your hourly cost. 24H of build plus 12H of maintenance is 36H, against 26H by hand. Year one is ten hours in the red.
- Every year after that. 26H by hand against 12H of maintenance plus the platform cost, so roughly 14H a year left over, as long as the process does not change.
So this task, at 26 hours a year, sits close to the line rather than over it. The decision turns on the one question arithmetic cannot answer: how many years will this task run unchanged? Three years and the sum works. Switching CRM next spring and it does not.
Change one number and it collapses. At ten minutes twice a month instead of three times a week, the same task costs four hours a year, and no build of any size clears four hours. Task frequency and duration decide more than the tooling does.
What are the four reasons to leave a task alone?
Four situations in which the sum says no regardless of the tooling: the frequency is too low, the process is not stable yet, the judgement is the output, or the task disappears next quarter. The first is arithmetic. The other three turn into extra maintenance hours or wasted build hours.
Reason 1. The frequency is too low. A task that runs monthly and takes fifteen minutes costs three hours a year. No build fits under three hours once you add the maintenance that returns every year. Frequency is the one number a cheaper build cannot compensate for.
Reason 2. The process is not stable yet. Every change to the process is a change to the workflow. n8n keeps a version history, with a new version at every save and a restore that replaces the current workflow with the version you pick [S-033]. Useful, and still an hour of someone’s attention each time. A process that changes monthly turns maintenance into a second build. Settle it on paper first; going from a working experiment to something that runs unattended is its own step.
Reason 3. The judgement is the output. If what the work produces is a decision, which candidate, which price, which exception, automating moves that decision into a review queue instead of removing it. Someone still reads every case, so the hours barely drop.
Reason 4. The task disappears next quarter. Build hours are spent once, in full, up front. If the tool, the client or the rule behind the task ends within the year, you paid the whole build for a fraction of the return. Ask what the task looks like in twelve months before you ask what automating it costs.
Why does maintenance after handover belong in the sum?
Because a live workflow needs two things nobody quotes: a path for failure and a way back. Those hours are small per month and large per year, and they are the line most often set to zero in a proposal.
In n8n the failure path is the Error Trigger node: when a linked workflow fails, it gets the details of the failed workflow and the errors, and runs the error workflow [S-031]. The way back is the version history above [S-033]. The platform supplies both mechanisms. It does not supply the person who receives the alert, judges whether it matters and does the restore.
So put maintenance after handover in the sum as hours, at a rate, every year, and decide whose hours they are before go-live rather than after the first failure. Who holds that job is the subject of who owns an automation after launch.
What does the model itself cost, and why is that rarely the reason?
Less than most people expect. List prices are quoted per million tokens, while a workflow uses thousands of tokens per run. In the example above the model is a rounding error next to the build hours. The model cost is almost never the reason an automation fails the sum.
The published Claude API price list prices usage per million tokens. Anthropic works an example through in that same documentation, consulted 27 September 2026: 10,000 customer conversations of about 3,700 tokens each, handled with Claude Haiku 4.5 at $1 per million input tokens and $5 per million output tokens, come to about $37 in total [S-043]. As a rough estimate one token is about 4 characters, or 0.75 words in English, and the exact count varies by language and content type [S-045]. Those are dollar prices from the vendor’s own list, quoted as published.
Against the worked example, 156 runs a year is far below 10,000 conversations: the usage line stays in small change while the build and maintenance run into hours. The fixed platform cost is the monthly line that does count, because it returns twelve times a year. n8n, for instance, can be used as n8n Cloud, with no installation, or self-hosted, where you manage your own deployment [S-006]. That choice decides whether the line is a subscription or a server plus your own hours. No amount here: the plan depends on how many workflows and executions you run. Which cost items make up the full bill is the subject of the companion article in this series.
What do you do when the sum says no?
Three moves, none of which require a build. Drop the task: ask what actually breaks if it stops, because for a recurring report that nobody opens the answer is often nothing. Shrink it: automate the ten minutes of copying and leave the five minutes of checking with a person, so both the build and the maintenance get smaller. Or bundle it with its neighbours until the frequency does add up, because four monthly tasks that share a trigger and a data source are one build instead of four. Tasks bundle well when they already sit in the same system, as 5 marketing tasks you can automate today shows.
The conclusion is often that you build nothing, and that is a real outcome rather than a failed exercise. Four numbers on an envelope cost ten minutes and no budget.
Sources
- Claude API price list, consulted 27 September 2026: about $37 per 10,000 conversations at $1 and $5 per million tokens [S-043], token rule of thumb [S-045]
- n8n documentation: Error Trigger [S-031], version history [S-033], Cloud or self-hosted [S-006]. WeAdapt FAQ: Quickscan from €995 [A-006]
Landed close to the line? That is when a second pair of eyes helps: see what an automation audit looks at. Landed clearly under it? Then you are done.