What business process automation actually costs

Ask three firms what it would cost to automate a process in your business and you will get three answers that do not compare to each other. One quotes a project. One quotes a monthly subscription. One says "it depends" and stops there.

That is frustrating, but it is not a dodge. The honest answer depends on facts about your business that nobody can see from outside it, and any firm that gives you a confident number before looking is guessing. What you can do, before you talk to anyone, is understand the cost structure underneath the quote. Then you can tell a real estimate from a hopeful one.

#Why nobody gives you a number up front

The same request can be a two-week job or a six-month one, and the difference is almost never the automation itself.

It is the state of the systems it has to touch. A process that lives in one system with a documented API is straightforward. The same process, when it spans an ERP that a vendor no longer supports, a spreadsheet three people maintain by hand, and a step where someone reads an email and makes a judgment call, is a different job entirely. The work is not writing the automation. It is making the systems able to hand work to each other reliably.

That is why a scoping conversation is not a sales tactic. It is the only way anyone finds out which job this is.

#The four things you are paying for

Most quotes bundle these together. Ask for them separately, because they behave differently over time.

1. Finding out what is actually happening. The documented process and the real process are rarely the same. Somebody has a workaround. There is a case that gets handled by hand every Thursday and never made it into the process doc. This part is cheap relative to everything else and it is the part that, when skipped, causes the expensive rework later.

2. Building it. This is the part people mean when they say "the cost." It is usually not the largest number over a three-year horizon.

3. Keeping it running. Automation is not an appliance. The systems it connects change underneath it. A vendor updates an API, a form gains a field, a business rule shifts, and something that worked for eight months quietly stops. Ongoing cost is real, and a quote that does not include it has moved that cost to you without telling you.

4. Knowing when it breaks. This is the one that gets left out, and it is the one that decides whether the whole thing was worth buying.

#The cost nobody quotes

An automation that fails loudly is an inconvenience. An automation that fails quietly is a liability, and it costs more than the build did.

Quiet failure looks like this: the job stops running, nothing alerts, and the work silently does not happen. Nobody notices until a customer calls, or until month-end reconciliation does not balance, or until someone goes looking for records that were never written. By then you have a data problem on top of the original process problem, and the cleanup is manual.

We have seen this from the wrong end. A scheduled job at one client had not run in months. The way it surfaced was the client telling us it was broken. That is backwards, and the fix was not a better automation. It was a check that could report its own failure without a human going to look.

So the question to press on is not "does it work." Anything works on the day it ships. The question is how you will find out on the day it stops. If a system cannot go red, you have no basis for trusting it when it looks green.

#The number that matters more than the price

Before you evaluate a quote, get rough on what the manual version costs you now. Not precisely, roughly is fine.

How many hours a week go into this, and at what loaded rate? How often does it get done wrong, and what does fixing one of those cost? What does it delay? What can you not do at all right now because those hours are spoken for?

That figure is the denominator for every quote you receive. Without it, a price is just a number you either like or do not like. With it, you can tell whether a proposal pays back in five months or in five years, and you can tell when the honest answer is that this process is not worth automating yet.

Some are not. A process that runs twice a month and takes 20 minutes is not an automation candidate no matter how annoying it is. A firm that tells you that is worth more than one that quotes it.

#How to read a quote

Four things separate a real estimate from an optimistic one.

• It names its assumptions. A quote that says "assuming the ERP exposes order status through its API, which we have not confirmed" is more trustworthy than a lower number with no conditions attached. The assumptions are where the variance lives.
• It prices the ongoing cost, not just the build. Ask directly: what does this cost me in year 2, and who is responsible when it breaks?
• It says how you will know it is working. Monitoring, alerting, and a record of what ran. If the answer is vague, the real answer is that you will find out from a customer.
• It leaves you owning the result. You should be able to see what the system does, inspect its decisions, and hand it to someone else. If the automation only makes sense to the firm that built it, you have not bought an asset. You have bought a dependency.

#What we do about it

We do not publish a rate card, for the reason at the top of this piece: the number would be wrong for most of the people who read it, and a wrong number is worse than no number. What we do instead is scope before quoting, price the operating cost alongside the build, and build the monitoring in rather than selling it later.

Every material action the system takes is recorded and reviewable, and anything that needs judgment routes to a person instead of guessing. If we cannot produce the receipt, we do not call the work complete.

If you have a process in mind and want a straight answer about whether it is worth automating, including the answer that it is not, get in touch. The scoping conversation will tell you more than any number on a website could.