What It Costs to Automate a Manual Process

Nobody publishes a price for this, and the reason isn't coyness. "Automate our onboarding" can mean a scheduled email and a folder being created, or it can mean four systems, a permissions model and a legal review. Those are not the same purchase, and a published range wide enough to cover both would tell you nothing.

What can be published is how the number gets decided. This post is that: the shapes this work is billed in, the things that genuinely move your figure, the running cost most quotes leave out, and how to read two proposals that look like they're for the same job.

We sell automation work (Automation & Integration is one of our services), so this is an explanation from an interested party. It's written to be useful even if you buy from someone else.

The three shapes

Almost every credible quote you'll see is one of these three, and the shape should follow the work rather than the seller's preference.

A fixed price per automation. One workflow, one number, one date. This is the right shape when the process is understood well enough to scope — the steps are known, the systems involved have a sane way in, and the exceptions have been counted. Most individual automations land here, and it's the shape you should push for, because it moves the risk of the estimate onto the person who wrote it.

Hourly, for the parts nobody can scope honestly. Sometimes a system is undocumented, or an API turns out to be a fight, or the "simple" process has eleven exception paths that only surface once you watch someone do it. A fixed price against that kind of unknown isn't safer for you — it just means the padding gets paid whether or not the risk materialises. An honest provider tells you which piece is hourly and why, rather than quietly inflating one number.

A monthly fee, for keeping things alive. Automations are not furniture. Tools change, credentials rotate, an API version gets retired, the business changes the process. If nobody owns that, your automations decay quietly. Some buyers keep this in-house; some buy it. Either is fine. Not deciding is the expensive option.

Watch for the fourth shape, which isn't billing at all: a per-seat or per-task platform subscription, paid forever, on top of whichever of the above you bought. More on that below.

What actually moves your number

Six things, roughly in order of how much they matter.

Whether the process is written down. This is the big one and it surprises people. If nobody can say exactly how the work is done today, the first chunk of any engagement is finding out. Two businesses automating "the same" invoice process can differ by a factor of several purely on this. It's also the part you can do yourself — counting the hours and writing down the steps before anyone quotes is the cheapest way to lower a price.

How the systems let you in. A documented API with proper authentication is the good case. A system with only a CSV export is workable. A vendor portal with no API, no export and a login somebody types by hand is the expensive case, and occasionally the impossible one. This single fact can swing a quote more than the complexity of the logic ever will.

The number of exception paths. The happy path is usually easy. The cost lives in "unless it's a returning customer", "unless the amount is over the approval limit", "unless it came in through the other form". Every exception is more logic, more testing, and more of the automation's total lifetime spent being fixed. Counting them honestly at the start is worth real money.

What happens when it's wrong. An automation that formats a report can fail with a shrug. One that moves money, changes permissions or emails customers needs checks, logging, an approval step, and someone alerted when it stops. That's not padding, it's the difference between a script and something you can leave running. Say plainly which of the two you're buying.

Volume. A workflow that runs fifty times a month and one that runs fifty thousand times a month are different engineering problems, even with identical logic. Rate limits, retries and error handling that a low-volume job can ignore become the bulk of the work at scale.

Who owns the data. Personal data, payment data, or anything covered by a policy your customers were promised adds review and constraints. Not enormous, usually, but real — and much cheaper to raise at the start than to retrofit.

The running cost nobody quotes

The build is a one-off. Three things aren't, and they're the line items most often missing from a comparison:

• Platform fees, if the solution sits on one. These are usually priced per task, per run or per seat, which means your bill rises with your success. Fine at small volumes, occasionally absurd at large ones. Ask what the cost looks like at three times today's volume before you commit.
• Maintenance. Something will change underneath every automation you own. Budget for it deliberately or it comes out of somebody's week unplanned.
• The knowledge. If how an automation works lives only in one person's head, you've swapped a manual process for an undocumented system — which is a worse trade than it looks. Documentation produced as part of the build is the cheapest it will ever be.

The parts that are cheaper than people expect

Not everything is a project. Some of the highest-value findings cost very little:

Scheduled reports that currently get built by hand are often close to trivial once you can reach the data. Notifications — telling the right person that a thing happened, instead of them checking — are usually small and disproportionately useful. Getting rid of a manual retype between two systems that both already have APIs is frequently less work than the meeting about it. And the single best-value outcome is discovering a step that shouldn't be automated at all, because two teams can simply agree to stop doing it.

That's why the counting exercise pays for itself before anyone writes code: it finds the cheap wins as reliably as it finds the expensive ones.

Reading two quotes that aren't comparable

When two proposals differ wildly, the difference is almost never the hourly rate. It's scope. Ask both of them the same five questions:

1. What exactly is included — the build only, or testing, documentation and handover as well?
2. What happens when it breaks in month four? Who fixes it, and is that billed?
3. Is there a platform subscription underneath this, and what does it cost at three times our volume?
4. How many exception paths have you assumed? Name them.
5. If we stop working with you, what do we keep, and can another developer pick it up?

The last one is the one buyers skip and providers hope you'll skip. An automation you can't take elsewhere isn't an asset, it's a subscription with extra steps. The answers to those five explain the price gap nearly every time.

Worth deciding alongside all this is whether you want a platform or something built — the two carry their costs in completely different places, one up front and one forever.

Where to start without spending anything

Write down the manual work, put hours against it, and take that to whoever you're asking for a quote. You'll get better numbers, faster, because the expensive unknown has already been removed.

If you'd rather have it done for you, that's what our free automation map is: five working days, a written inventory of the manual work with hours against each item, the integration picture, and a build order — including what we'd leave alone. It's free, there's nothing to sign, and the document is yours whether or not we ever quote you.

We only quote work you've told us you want to do. Everything before that is the map, and the map is free.