Workflow automation for growing businesses usually starts in the wrong place: whichever task somebody complains about loudest. That is a reasonable instinct and a poor selection method, because the loudest task is often the one that changes most, which makes it the worst thing to automate first.
The better question is which process is stable, frequent, rule-based and currently consuming someone expensive. That combination is rarer than it sounds and it is where the return lives.
Automating A Broken Process Makes It Worse
This is the failure we are called in to unpick most often. A process with unclear rules and frequent exceptions gets automated, and the automation now produces wrong outcomes faster than a person did, without the pause where somebody would have noticed.
Manual work has an accidental safety feature: a person doing something odd usually hesitates. Automation does not hesitate. It applies the rule it was given at full speed to inputs nobody anticipated.
So the first test is whether you could hand the process to a new starter with a written procedure and expect it done correctly. If not, the project is documentation, not automation, and skipping that step is what produces the expensive version.
Four Questions That Rank Candidates
- How often does it run? Something happening two hundred times a month repays a week of work. Something quarterly almost never does, however irritating it is.
- How stable are the rules? If the process changed twice this year, it will change again, and every change is rework. Stabilise first.
- Can you check the output automatically? If correctness needs a human to eyeball it, you have moved the work rather than removed it.
- What does the time currently cost? Not the salary of whoever does it, but the salary of whoever would otherwise be doing something more valuable. This is usually where the real number is.
Score your candidates against those four. The winner is rarely the task people complain about, and it is usually something quiet and repetitive that nobody has thought about in a year.
Where Growing Businesses Usually Find The First Win
Some patterns recur often enough to be worth naming.
- Moving data between systems that do not talk. Orders into accounting, form submissions into the CRM, spreadsheet into dashboard. Unglamorous, high frequency, easy to verify.
- Onboarding sequences. New client or new employee triggers a fixed set of accounts, documents and reminders. Stable rules, and the failure mode is visible immediately.
- Recurring reporting. Somebody rebuilds the same report every Monday from the same sources. Frequent, rule-based, and the output is checkable against last week.
- Document generation. Quotes, contracts and invoices assembled from a template plus known fields.
Notice what is missing: anything requiring judgement about a customer, anything with frequent exceptions, anything where being wrong is expensive and hard to detect.
The best first automation is usually something nobody is complaining about. The loud tasks are loud because they keep changing, and changing is exactly what automation handles worst.
David Kwon, Head of Automation, Engineered With AI
Build The Smallest Version That Runs
The instinct is to automate the whole process end to end. The better approach is to automate the longest boring stretch and leave a human at each end, at least initially.
A person triggers it, the automation does the repetitive middle, a person confirms the result. That keeps the failure contained while you learn what actually goes wrong, and the confirmation step can be removed later once you trust it. Removing it before you trust it is how the first bad month happens.
Instrument It Or You Will Not Know It Broke
Automation fails silently more often than loudly. A field name changes, an API returns an empty list, a credential expires, and the workflow keeps reporting success while doing nothing useful.
Three things prevent the quiet failure: a notification when a run fails, a notification when a run does not happen at all, and a log of what each run actually processed. The second one is the one everybody forgets and it is the one that catches the worst cases.
What This Should Cost In Time
A well-chosen first automation is usually days rather than months. If a candidate looks like a multi-month project, that is a signal the process is not ready or the scope has crept past what it should be for a first attempt.
The value of starting small is not the saving. It is that you learn how your own systems behave, where the data is inconsistent and which integrations are fragile, before that knowledge costs you a large project.
If you want a second opinion on which process to start with, describe two or three candidates and what happens when each goes wrong. That is usually enough to rank them properly in one conversation.
Not sure what to automate first?
Describe two or three candidate processes and what happens when each one goes wrong. We will tell you which is genuinely ready, and which needs documenting before anyone automates it.
