Skip to content
Albright Labs

What an Automation Project Actually Costs

Alexis van Brussel

Ask what an automation project costs and you get a build number.


The build number is real, and it is the least useful figure in the decision. It tells you what it takes to get to launch. It tells you nothing about whether the thing pays back, which is the only question worth asking before you sign.


Automation projects fail their business case in predictable ways, and almost none of them involve the build coming in over budget. They fail because nobody counted the cost of explaining the process, verifying the output, handling the exceptions, or keeping the integration alive after the person who commissioned it moved on.


This is the accounting we walk clients through before quoting anything.


The Four Costs on Every Proposal

Start with what does get counted. A well-scoped automation project has four visible line items:


Discovery: working out what the process actually does, as opposed to what the documentation says it does.

Build: the software itself.

Integration: connecting to the systems the process already touches.

Deployment: getting it running against real data, with real permissions, in the real environment.

These are the numbers on the proposal, and a competent shop can estimate them. If this were the whole cost, automation decisions would be easy.


The Four Costs That Decide the Outcome

1. The Explaining

Somebody on your team has to describe the process to the people building it. Not the ideal process: the real one, including what they do when the input is wrong, who they call when it is ambiguous, and which step exists because of something that happened in 2019.


This is real time from your most knowledgeable person, who is by definition your busiest. Budget several hours a week for the length of the build, weighted toward the front.


Teams that skip this do not save the time. They spend it later, in rework, at a worse exchange rate.


2. The Verifying

For the first stretch after launch, somebody checks the output. Not because the build is untrustworthy, but because that is how trust gets established.


This is a genuine, temporary cost: a fraction of the time the manual process consumed, for a few weeks to a few months depending on how often the process runs and how visible its failures are. It declines over time, but it does not start at zero.


An automation that saves twelve hours a month and costs three hours a month to check is saving nine. That is still a good project. It is a worse project than the proposal implied.


3. The Exception Path

Every process has exceptions. Automating the happy path and leaving exceptions to humans is usually correct, but it is a design decision with a cost, not a way of avoiding one.


You are choosing to run two processes: the automated one and the manual fallback. The fallback needs an owner, a route, and enough volume to stay familiar. A fallback used twice a year is a fallback nobody remembers how to run.


Ask early what share of cases are exceptions, and be suspicious of the answer. People underestimate this consistently, in our experience by about ten points.


4. The Carrying Cost

Automation is an asset with an annual cost of ownership:


Integrations break when the system on the other end changes, and you do not control that timing.

Credentials rotate and expire.

The process itself evolves, and the automation has to follow.

Somebody has to own it, which is a real assignment and not a footnote.

The right comparison is not "build cost versus current manual cost." It is "total five-year cost of the automated operation versus total five-year cost of the manual one," which is the same discipline described in Build vs Buy: When a Custom App Beats a SaaS Subscription.


What This Looks Like With Real Numbers

Class Action Settlement House administers class-action settlements. Their bottleneck was claim filing.


For every settlement, staff pulled each claim's details, typed each field into the settlement portal, and generated the agreement, one record at a time. It was careful, repetitive work that scaled only by adding people. As Lee at CASH put it:


The time spent loading the cases is 80% to 85% of the time we are spending.


That is the profile of a strong candidate: high repetition, rules that can be written down, inputs arriving in a consistent shape, and errors that surface immediately. It is also boring work rather than the most complicated thing they did.


We automated the filing with headless-browser automation. Import a batch of claims and the system files each one to the settlement portal, checking eligibility, filling roughly 90% of every form, and recording the claim number that comes back. A human reviews the batch at the end, which is the verifying cost showing up exactly where it should. We paired it with agreement generation, assembling the contract from a set of contact details instead of building it field by field.


I plug in the URL and it fills almost 90% of the fields. It is such an enormous timesaver, so that we focus more on selling and filing than on the other stuff.


Across the work, the automation eliminated roughly 13,500 hours of manual processing and saved about $450,000. All claims now process automatically.


The system fills about 90% of each form, not 100%. The remaining 10% is the honest part. A vendor promising to eliminate every keystroke is describing a process they have not examined closely.


The human review step at the end of the batch was designed in rather than bolted on, which is what makes the throughput gain durable instead of a source of quiet errors nobody catches for a quarter.


Being able to generate an agreement from a set of contact information has changed our lives, instead of us having to type each field and everything else.


Lee, Class Action Settlement House


How to Read a Quote

When you have a proposal in front of you, four questions separate a real estimate from an optimistic one.


What share of cases does this handle end to end? If the answer is 100%, the process has not been examined closely enough. Good answers are specific and short of total.

What happens to the cases it does not handle? There should be a named route and a named owner, not a shrug.

What breaks this, and how would we know? Integrations fail. The question is whether failure is loud or silent. Silent failure in a financial workflow is the expensive kind.

What does year two cost? A vendor who has not thought about maintenance has quoted you a launch, not a system.

A shop that answers these crisply has built this before. A shop that treats them as pessimism has not.


When the Numbers Do Not Work

Plenty of processes should not be automated, and the accounting tells you which:


The volume is too low. Automation pays back per repetition, and a quarterly process rarely earns its carrying cost.

The exception rate is too high. Past roughly 30%, you are building two processes and getting the benefits of neither.

The rules cannot be written down. That is a process-design problem wearing a technical costume, and the design work has to happen first.

The process is about to change anyway. Automating a workflow that is being renegotiated means paying twice.

Being told a project is not worth doing is a useful outcome of discovery. It is considerably cheaper than finding out in month four. This is the same ordering logic covered in How to Decide What to Automate First.


A Simple Rule of Thumb

If a proposal contains a build number and nothing about verification, exceptions, or year two, it is an estimate of what it costs to start the project, not what the project costs.


The gap between those two numbers is where automation projects go wrong.


Final Thoughts

Counted honestly, with the explaining, the verifying, the exception path, and the annual carrying cost sitting alongside the build, fewer projects clear the bar. The ones that do clear it convincingly.


The CASH engagement returned $450,000 and 13,500 hours because the process underneath it was well chosen: repetitive, rule-bound, high-volume, and cheap to check. The arithmetic worked before anyone wrote code, which is the part worth copying.


If you are weighing an automation project and want an honest read on what it will cost and whether it pays back, we are happy to walk through the numbers with you. Book a short consult.

Albright Labs

Have something you want to build?

Tell us what you are trying to accomplish, what is in the way, and when you need it. We will take it from there.

Book a consult →

A senior engineer reads it and replies within one business day.

or call +1 (610) 756-5060