Business process automation

The short version

There is a test for whether your business needs automation, and it takes about a minute. Watch someone read a number off one screen and type it into another. That is not a job. That is a person being used as a cable between two systems, and it is the most expensive cable you will ever buy.

• Automation is not about removing people. It is about removing retyping, chasing and remembering.

• The best candidates are high-frequency, low-judgment and rule-based: quotes, invoices, reminders, approvals, handoffs.

• Most single automations come in under $5,000 and take two to three weeks.

• A good automation tells you when something needs a human, instead of silently doing the wrong thing.

• Automating a broken process just gets you the wrong answer faster. Fix the process first — sometimes that is the whole job.

What business process automation actually means

It means the routine steps of a process happen on their own, in the right order, without anyone remembering to start them. Job marked complete, so the invoice drafts itself, the customer gets an email, the accounting system is updated, and if the payment has not arrived in fourteen days somebody is told.

None of that is clever. All of it is currently in somebody's head or on somebody's list, which is why it slips in a busy week — and busy weeks are exactly when slipping is most expensive.

What automation is not: a project to replace staff. In practice what changes is what your team spends the day on. The people who were reconciling and chasing move to the work that actually needs them, which is usually the work customers can tell the difference in.

Where the time actually goes

Owners are usually wrong about this, and not by a little. The visible tasks are not the expensive ones — the expensive ones are the small repeated frictions nobody logs because each takes only a couple of minutes.

The four that account for most of it:

• Re-entry — the same customer, job or line item typed into two or three systems that do not talk. That is often an integration rather than an automation.

• Chasing — asking a colleague, a supplier or a customer for something that should have arrived on its own.

• Reconstruction — rebuilding the same report or summary from scratch every week because nothing keeps it up to date.

• Remembering — the deposit chase, the renewal, the certificate expiry that lives in one person's memory and occasionally does not.

A useful exercise before you talk to anyone: for one week, have two people note every time they type information that already exists somewhere else. The list is almost always longer than expected, and it is a scope document.

The processes most worth automating

The specifics vary by industry, but the shapes repeat across almost every small business:

• Quoting — a quote assembled from your price rules and past jobs, ready for an estimator to adjust and send in a couple of minutes.

• Invoicing — invoices raised from completed work, not typed again, and pushed straight into the accounting system.

• Scheduling — jobs assigned by capacity, skills, service window and travel, instead of a whiteboard and a phone call.

• Approvals — anything over a threshold routed to the right person, with a record of who approved what and when.

• Reminders and follow-ups — deposits, renewals, expiring certificates, unpaid invoices, customer check-ins.

• Onboarding — a new customer or new employee triggering the same reliable checklist every time, with nothing skipped.

• Reporting — the Monday morning numbers already in your inbox, not assembled by hand on Monday morning.

Most of these are individually small. Their value is cumulative, which is why we usually recommend starting with the one that annoys people most, not the one with the biggest theoretical payoff. Momentum matters, and the team has to want the next one.

What automation costs

Less than most people expect, because a single automation is a small, well-defined piece of work, not a system.

To know whether that is worth it, price the status quo. Six hours a week of re-entry, at a loaded cost of $35 an hour, is roughly $11,000 a year — every year, indefinitely, and it grows as you do. Against that, a $4,000 build that removes most of it pays back inside a few months and then keeps paying.

One thing to budget for that rarely appears in a quote: somebody inside the business has to own the automation once it is running. Not maintain it — own it, in the sense of being the person who notices when the alert email arrives and decides what to do. Automations without an owner are how a business ends up trusting something that stopped working in March.

Do the sum on your own numbers before you take ours. If it does not clear the bar, that is a real answer and we would rather you had it early.

When an automation fails

It will fail, and this is the part nobody demonstrates. An API goes down, a supplier changes a file format, someone types an address that does not exist. The difference between an automation you trust and one you quietly stop relying on is entirely in what happens next.

What we build in as standard:

• Retries with sensible backoff, because most failures are temporary and fix themselves in ninety seconds.

• A dead letter queue — anything that truly cannot be processed is held, not dropped.

• A named person alerted when something needs a human, with enough context to act on it.

• Idempotency, so a retry cannot send the same invoice twice or double-charge a customer.

• A log you can read in plain English: what ran, when, what it did, and what it decided not to do.

The rule we hold to is that an automation must fail loudly. Silent failure is worse than no automation at all, because everybody has already stopped checking.

When not to automate

When the process is wrong. Automating a broken process gets you the wrong outcome faster and more consistently, and makes it harder to see that it was wrong in the first place.

Leave it alone, for now, when:

• The step exists because of a rule nobody can explain any more. Find out why before encoding it forever.

• It happens a handful of times a month. Rare tasks rarely repay the build, however irritating they are.

• The judgment is the job. Deciding which customer gets the emergency slot is not a rules engine, it is management.

• The process is about to change anyway — a new supplier, a new system, a new regulation next quarter.

Quite often the discovery call ends with a simplification instead of a build: three approval steps become one, or a form loses four fields nobody reads. That is a cheaper outcome than a project, and it is worth looking for before you brief one.

If you can point at one thing your team types twice — what it is, how often it happens, and what breaks when it is forgotten — that is usually enough to say within a call whether it is worth automating and roughly what it would cost.