Most automation business cases compare two numbers: the platform subscription and the hours saved per week. The subscription is on the invoice; the saved hours are on a slide. The case looks compelling, the project ships, and a year later the team can't quite explain why the automation budget has tripled and nobody trusts the numbers anymore.
The honest cost of an automation is roughly four to six times the platform subscription over a three-year life. Most of that invisible cost lives in categories finance never asked about during the buying decision. Here's a practical model for what to budget — and the cost categories teams almost always miss.
The visible cost: platform and per-run fees
This is the easy line on the spreadsheet. Zapier, Make, Workato, n8n, UiPath — every platform has some combination of a base subscription and a per-run/per-task/per-bot fee. Two notes:
- Per-run pricing is sneaky at scale. A workflow firing 50,000 times a month sounds fine until you check the per-task tier.
- Premium connectors are often double the price of standard ones, and the connector you need is almost always premium.
Allow for the platform cost to be 1.5–2× the headline price by year two, as usage grows and premium tiers kick in.
The build cost: more than you think
Most teams estimate build time based on the 80% case — the happy path that's easy to map in a Loom video. The other 20% takes the other 80% of the build effort. Realistically:
- Discovery. Mapping the current process honestly (not optimistically). Half a day to a week, depending on complexity.
- Happy-path build.The version you'd demo. A few hours to a few days.
- Edge cases. The bit where the input is wrong, the API returns a 429, the user filled the field with an emoji, two records exist with the same ID. Usually 2–3× the happy-path time.
- Error handling and alerting. So the automation fails loudly when it fails, instead of quietly. Often skipped on first build, painfully retrofitted later.
- Documentation. So the next person can understand it. Almost always skipped. Almost always regretted.
A working rule of thumb: take your first estimate, multiply by two, and that's the realistic number for a production-grade automation. Anything under that is a prototype with marketing.
The maintenance cost: the line that's usually missing
Automations are not write-once assets. They sit on top of APIs and UIs that change, schemas that drift, and business rules that get re-interpreted. A useful rule: budget 15–25% of the original build effort per year for ongoing maintenance.
What “maintenance” actually means in practice:
- API deprecations and version bumps. A vendor changes a field name; your automation breaks.
- New edge cases the original build didn't anticipate.
- Business rule changes — a new product type, a new tax rate, a new approval policy.
- The platform itself updating. Less common but real.
- People leaving and the next maintainer needing to rebuild understanding from a poorly documented workflow.
Multiply this across 30 active automations and you're into meaningful FTE-equivalent overhead. If you don't plan for it, the work gets pushed onto whoever's closest — usually the person who built it originally, which doesn't scale.
The observability cost: silent failure is expensive
An automation that fails silently is worse than no automation. The bill for monitoring usually shows up as:
- Time spent building alerting (a one-time cost, often under- estimated).
- Ongoing time spent triaging alerts — most of which are noise unless you tune them.
- The occasional rework cost when an automation has been silently broken for weeks and you have to manually clean up the data.
For a serious production automation, budget at least 10–15% of build cost for observability, both up-front and ongoing. Cheaper than the cleanup bill when it goes wrong.
The rework cost: the bill nobody itemises
Every automation breaks at some point. When it does:
- Someone discovers it (often the customer).
- Someone investigates what went wrong.
- Someone fixes the broken automation.
- Someone cleans up the corrupted or missing data.
- Someone tells the affected stakeholders what happened.
For a high-volume automation that fails once a quarter, this can be a full person-day each time. For a customer-facing one, multiply by trust-erosion cost. It's real money even if nobody puts a line on it.
The governance cost: the one finance asks about late
Once you have a dozen automations across two platforms and three owners, governance starts costing real time:
- Inventory: knowing what automations exist and who owns each.
- Access control: who can edit what, and how new joiners get access.
- Security review: especially for automations that handle PII or financial data.
- Audit: when the regulator or the auditor asks, you need to produce evidence.
This cost is roughly flat for the first five automations and rises steeply after that. A small allocation early — naming an owner, keeping a register, agreeing standards — is much cheaper than a retrofit at 50 automations.
A worked example
Let's say you're building a customer onboarding automation. Headline costs:
- Platform: $400/month = $4,800/year
- Initial build: estimated at 20 hours, realistic 40 hours
Add the rest:
- Edge cases and error handling: another 20 hours
- Documentation and onboarding: 5 hours
- Monitoring/alerting setup: 8 hours
- Annual maintenance: 10–15 hours per year
- Quarterly rework when something breaks: 2 hours × 4 = 8 hours/year
- Governance overhead: 2 hours per year per automation
That's 73 hours of build effort up front and ~25 hours of ongoing effort per year, on top of the $4,800/year subscription. At a loaded internal rate of $120/hour, year one comes to about $18,000 — not $4,800. Year three TCO is closer to $30,000.
The automation can absolutely still be worth it. It saves five hours of manual onboarding per customer and the team onboards 200 customers a year: $120,000 in saved time at the same loaded rate. ROI is fine. But it's a 4× ratio, not the 24× ratio the original business case implied.
How to budget honestly
- Use a three-year TCO, not a year-one number.Maintenance and rework only show up at scale.
- Loaded rate, not salary rate, for internal time.Benefits, overhead, opportunity cost — multiply the salary by roughly 1.5–2× for an honest comparison with vendor costs.
- Discount the savings.The five hours saved per week aren't five hours redeployed to new value; some of it becomes slack. Assume 60–70% capture of theoretical savings.
- Set a portfolio budget, not per-automation.At ten automations and up, ongoing costs are easier to plan as a team budget line than as ten separate cases.
The honest bottom line
Automation absolutely earns its keep — but at 4–6× the platform cost, not at 1×. Teams that budget for the full lifetime cost up front make calmer, better decisions about which automations to build, which to retire, and which to leave as manual work. Teams that don't spend the second year unhappy about the automation programme they were so excited about in year one.