Where to start automating routine work

Automation is usually discussed the wrong way around. The conversation starts with a tool somebody read about and works backwards to find something for it to do, and the result is a subscription that saves twenty minutes a month.

The productive order is the reverse. Find where the hours actually go, price them, and only then ask what would remove them.

Signs that a process is ready to be automated

Not every repetitive task is worth touching. These are the markers that one is.

• The same data is typed twice. Copied from one place into another.
• It happens on a schedule. Every day, every order, every week.
• A mistake in it is expensive. Wrong price, wrong stock, wrong address.
• It has to wait for one person. Who is sometimes away.
• It is described the same way every time. With no judgment involved.

The last one is the real test. If the task can be written as a set of rules with no exceptions requiring a decision, it can be automated. If half the cases need somebody to think, automation handles the other half and leaves the thinking, which is still worth doing but is a different calculation.

A task with two or three of these is a strong candidate. One on its own usually is not enough.

How to find the most expensive routine

Count the hours rather than the feeling

Everyone knows which task they hate. That is rarely the one costing the most.

The measurement takes a week and requires nothing beyond a shared sheet. Each person notes where their time went, in large blocks such as handling inquiries, paperwork, moving data between systems or answering the same questions over and over. A rough estimate at the end of each day is enough; nobody needs to track time to the minute. At the end of the week the repeated items are grouped and the hours are added.

The result is reliably surprising. The task everyone complains about turns out to be forty minutes a week. Something nobody mentions, because it has always been done that way, turns out to be six hours.

Then comes the arithmetic. Hours per month multiplied by what an hour of that person’s time costs the business, which is their full cost rather than their salary line. That figure is the budget the automation has to beat.

The cost of a manual error in numbers

The hours are only half of it, and usually the smaller half.

Manual data entry has an error rate. In practice it sits at a small percentage, which sounds negligible until it is multiplied by volume. Two hundred orders a month with a modest error rate is several wrong orders every month, and each one carries a cost beyond the price of the item.

• The direct loss. The wrong item shipped, the wrong price honored.
• The time to fix it. Usually more than the time to do it right.
• The customer’s response. Some of them do not come back.
• The knock-on errors. Stock and accounts now disagree.
• The checking that follows. Somebody now verifies everything manually.

The last item is the hidden one. After a few bad incidents a company adds a checking step, and that step costs more hours than the errors did.

What businesses automate first

The pattern is consistent enough to be a shortlist, and it is ordered by how quickly each pays back.

Inquiries reaching the right place without retyping. The form, the mailbox and the messaging app all creating a record automatically. This is nearly always first because it is cheap and because the loss it prevents is direct revenue.

Notifications when something needs attention. A new inquiry, an order that has sat unpaid, a delivery that is late. Replacing the habit of checking with a message that arrives.

Documents that assemble themselves. Quotes, invoices and delivery notes generated from data that already exists rather than typed into a template.

Stock and price synchronization between the shop and wherever the real numbers live. This one is usually the highest value in retail and also the most technical, and it is where a wrong figure costs the most.

Reports that build themselves. Assembling a report manually takes hours, so reports are produced less often than they should be.

Here is the shortlist, ordered by how quickly each usually pays back.

• Inquiries into one place. Cheapest to do, prevents direct losses.
• Notifications instead of checking. Quick to set up, removes a habit.
• Documents generated from data. Removes typing and typos together.
• Stock and prices synchronized. Highest value in retail, most technical.
• Reports assembled automatically. Lets you make decisions more often.
• Reminders to customers. Payment due, appointment tomorrow, renewal.

The last one is the one small businesses skip most often, although an unpaid invoice that nobody chased is revenue already earned and then lost.

An off-the-shelf service, connected services, or a custom build

The three routes differ in cost, in speed and in how well they survive change.

An off-the-shelf service is the cheapest and fastest, and the right answer more often than people expect. Invoicing, scheduling, mailing, simple stock management all have mature products, and adapting your process slightly to fit one is usually cheaper than building around your existing habits.

Connecting services means using an automation layer to pass data between tools you already have. It is quick and inexpensive to start, and it degrades as the number of connections grows. Five connections is manageable. Twenty is a system nobody understands, with no error handling and no owner, and it fails silently.

Building your own is justified when the process is genuinely specific, when the volume is high enough that per-user pricing hurts, or when the data cannot leave your own systems. The comparison in detail, with the crossover point, is in our article on an off-the-shelf CRM or a custom system.

How not to buy more than you need

The most common overspend is buying a platform when an integration would do.

The test is to write down exactly what should happen, in one sentence, before looking at any product. For example, “When an order is paid, create the invoice and send it to the customer.” That sentence is an integration and costs accordingly. A platform that also does customer portals, project management and analytics is a larger purchase, and the parts you did not need still have to be configured and maintained.

The second overspend is automating a process that is about to change. If the way you take orders will be different in six months, automating the current way means paying for something with a short life.

Before buying anything, ask whether you can take your data with you. A service that will not export what you have accumulated in a usable format locks you in more tightly than any contract.

Why automation fails on the human side

The technical part is usually the easy part. The failures are almost always human.

The most common is that the automation runs alongside the old manual process rather than replacing it. Both are done, the automation is now overhead, and within a month somebody switches it off.

The second is that nobody was told what to do when it fails. Every automation fails occasionally, and if there is no visible signal and no named person, the failure sits unnoticed until a customer reports it.

The third is that the automation was built around one person’s way of working, and that person left. What remains is a process nobody understands well enough to change.

• Replace the manual step, do not add to it. Or it becomes overhead.
• Make failures visible. A silent failure is worse than no automation.
• Name an owner. Somebody who notices and can fix it.
• Write down what it does. In plain language, one page.
• Keep a manual fallback. For the days it does not work.

What to do before writing a specification

The specification is where money starts being spent, and in our experience projects most often overrun when it is written too early.

The current process has to be written down first, exactly as it is rather than as it should be. This takes an afternoon and it routinely uncovers steps that exist for no remaining reason.

What the description needs to contain is short, and it is the same every time.

• Every step in order. Including the ones that seem obvious.
• Who does each one. By role, not by name.
• What they open. Which system, which file, which mailbox.
• Where the data comes from. And where it goes afterwards.
• What the exceptions are. The cases that get handled differently.
• How often it happens. Per day, per order, per week.

Then the process is cleaned up manually. Removing the pointless steps before automating is what stops the automation from encoding somebody’s old workaround permanently.

Only then is it worth describing what the automated version should do, and by that point the description is short, because most of the thinking has already happened.

Work of this kind is ordinary custom web development rather than a specialism, and the largest variable in what it costs is how clearly the process was described before anyone started building.

What it costs and how to calculate payback

A single improvement on an existing project, something to fix, improve or add, runs from $300 to $1,000.

Small integrations, meaning connecting two existing systems so data moves between them, run from $500 to $2,000.

Larger automation work, with two-way sync between systems, background queues and complex business logic, runs from $3,000 to $8,000. A separate tool with its own interface for the whole team is a web app, and its starter version costs from $4,000.

The payback calculation is deliberately blunt. Take the hours saved per month, multiply by the cost of those hours, add a conservative estimate of the errors avoided, and divide the build cost by that monthly figure. The answer is the number of months to payback.

Anything under twelve months is a straightforward yes. Twelve to twenty-four is a judgment call that depends on how stable the process is. Beyond twenty-four months the honest answer is usually to do it manually for now, because the process will probably change before the investment returns.

The number people forget to include is the ongoing cost. Automation is not free to run. Subscriptions, occasional maintenance when a connected service changes its interface, and somebody’s attention when it fails. Budgeting a small monthly sum for each automation keeps the calculation honest.

And one more correction, which is rarely made. Automation almost never frees a person completely. It takes the dullest part of the operation and leaves the rest, because somebody still checks the exception, fixes the error and approves the unusual case. So the sensible thing is to count not all the routine hours but a noticeably smaller share of them. If a solution pays back on that basis, it will pay back for certain.

When automating is the wrong move

Several situations look like automation candidates and are not.

Low volume. A task done four times a month does not justify a build regardless of how tedious it is, and the correct fix is often a better template rather than a system.

A process that is genuinely still being figured out. Automating a workflow that will be different next quarter is paying to make it harder to change.

A task where the judgment is the work. Deciding which customer gets a discount, writing a reply that requires knowing the history, choosing what to reorder. Those can be assisted, and automating them produces confident mistakes.

A business whose real problem is elsewhere. Automating order processing when the difficulty is that there are too few orders organizes the shortfall rather than fixing it.

And finally, a business that needs not one automated routine but a tool of its own for running the whole company. That is a different kind of project, and the boundary is drawn in our article on when your business needs a web app. Pricing and timelines for that kind of build are on the web application development page. Where automation gets attached to a sales process specifically, the sequence that makes it stick is described in our article on why CRM rollouts fail and the starting decisions in our article on CRM for small business.

Conclusions

Automation is worth doing where the hours are measurable, the rules have no exceptions and the process is stable enough to still exist in a year.

The order that works is to measure, clean up by hand, try a ready-made tool for a few months, and only then decide whether to build your own. The order that wastes money is to choose a tool first and then find work for it.

If you know something in your business is eating hours and are not sure whether it is worth automating, describe the process step by step, including who does what and how often. We will say whether an off-the-shelf service covers it, whether it is a small integration or a build, and what the payback period looks like on your numbers. If it comes out beyond two years, you will know that before any quote.