TL;DR: Automation gets sold on a number, and the number is usually wrong twice over — the time saved is overstated because it is computed per item, and the running cost is understated because model spend sits on a different budget line. Finance rejects the report rather than argue with it, and the credibility loss costs more than the tool. Across 260 practitioner threads in PainHunt, the gap people describe is not "does automation work" but "can I prove it in a way that holds up".
The evidence
PainHunt holds 260 posts on automation ROI scoring 10+/15 over the last 180 days, average score 11.2, average intensity 7.3/10. The bulk arrive through Bluesky (178), with Medium (24), Discourse (13), Mastodon (10) and a small Reddit and Substack tail. That distribution is worth stating plainly rather than dressing up: this is a topic that gets discussed in public a lot, and the deepest single description of the mechanism came from a Discourse thread, not from the volume.
Two failure modes recur, and they push the same number in opposite directions.
Savings are overstated. Time-saved tooling defaults to a linear per-item model: one record, one fixed time cost, multiply. Real batch work does not behave that way — there is a setup and teardown cost paid once no matter how many records follow. Practitioners describe the resulting estimate running 4x or more above what the work actually cost, and name the correct shape directly: fixed plus marginal, F + M × items.
Two structural gaps make it worse. Sub-workflows often do not report their time to the parent, so teams that follow the best practice of splitting work into modules under-count the very work they did most carefully. And loops that share an execution identifier get counted twice unless something deduplicates them.
Costs are understated. The other half of the corpus is people discovering the running bill. A business owner running n8n workflows describes $50/month of model API spend eating directly into the return. Solopreneurs and finance leads describe monthly invoices exceeding expectation as token costs outpace the forecast. None of this typically appears in the same report as the time saved, because it lands on a different budget line.
The consequence people describe is not a smaller number. It is the report being thrown out entirely, and the team losing standing for the next request.
Why now
Three things changed at once.
The spend became variable. A licence used to be a line item you approved annually. Model-metered automation moves the cost into something that changes with usage, which means the ROI is no longer a fact you establish once — it moves every month, and nobody owns recomputing it.
Automation moved out of engineering. Operations, marketing and finance teams now build workflows directly. They are closer to the business case and further from the instrumentation, so the number they report is whatever the tool's dashboard says. When that dashboard is optimistic by design, they carry the error to their CFO without knowing it.
Finance started asking. With AI budgets under scrutiny, "we automated it" is no longer sufficient. The threads describing rejection are not describing hostile finance teams. They are describing a number that did not reconcile, produced by someone with no way to produce a better one.
The wedge
The obvious build is a nicer dashboard. The threads point somewhere narrower.
- A measurement layer that is defensible, not flattering. Fixed-plus-marginal by default, sub-workflow time rolled into the parent, loop-aware deduplication, and an audit trail showing how each figure was derived. The product is not the number; it is being able to answer "where did that come from" in a meeting.
- One report with both sides of the ledger. Time saved and model spend, same period, same page. Neither half is hard to obtain alone; the value is entirely in them not being on separate lines owned by separate people.
- Attribution per client for agencies. Agencies running automation for several clients need per-client cost attribution to invoice with markup, and describe it breaking as soon as work is split into sub-workflows. That is a narrower buyer with a sharper reason to pay — the number is their invoice, not their credibility.
The common thread: sell the ability to withstand scrutiny, not the size of the saving.
Risks and honest caveats
- You are correcting a number people liked. Your product's first act is to tell a buyer their automation saved less than they told their boss. That is a real adoption barrier and it is worth designing the first-run experience around, rather than discovering it in a demo.
- Accurate attribution needs hooks the platforms may not give you. Sub-workflow and loop-level accounting depends on execution metadata the platform chooses to expose. Where it does not, you are estimating too — just more honestly — and you have to say so.
- The platforms can ship this. Time-tracking is a plausible native feature for any automation vendor. The defensible position is cross-platform and cross-vendor cost, which no single platform is motivated to build.
- The buyer may be too small. Solo operators feel this pain but will not pay much to solve it; the agencies and ops teams who will pay are fewer. Price against the invoice or the budget approval, not against the frustration.
How to validate this further
Read the underlying threads in the Pain Point Browser, and pressure-test which of the three wedges matches your access to buyers with the Idea Validator. Related: self-hosted n8n reliability and serverless spending caps.