Short answer
Start from what people actually do, not from what AI can do. Spend two weeks observing rather than interviewing, then score each candidate on four things: how often it runs, how predictable its path is, how expensive an undetected error would be, and whether the output is visible enough that a failure gets noticed. Automate first where frequency is high, the path is predictable and errors surface quickly. Never automate a process that is broken — you will remove the person who was quietly absorbing its defects.
The question that sends teams down the wrong path
"What could we automate with AI?" produces a list of impressive-sounding projects, and almost none of them survive their first quarter. The question invites you to start from capability, and capability is the one input that is now abundant.
The better question is narrower and harder to answer from a meeting room: which repeated task costs us the most, and how does it actually get done today? Nobody in the room knows the second half of that. Which is the whole problem — the real process lives in a spreadsheet on somebody's desktop, in a shared inbox with an unwritten triage rule, and in the head of the person who has done it for six years.
A quick test of whether you have found the real process: ask two people who both do it to describe it separately. If their descriptions differ, you have not documented a process — you have documented one person's habit. Automating that habit will break the moment the work reaches the other person's cases.
Finding the processes that actually exist
Interviews give you the official version. Observation gives you the real one, and the gap between them is where automation projects die. Two weeks of light observation is usually enough to see every weekly cycle twice — that window is a rule of thumb from our own engagements rather than a published standard, and the reason it holds is arithmetic: anything running on a weekly rhythm shows you its variation the second time round. It is far cheaper than building the wrong thing.
- Watch one full cycle end to end, including the waiting. Handoffs and queues are usually where the time goes, not the tasks themselves.
- Count the re-keying. Every place a human reads a value from one system and types it into another is a candidate with an obvious, checkable output.
- Find the shadow tools. The spreadsheet, the personal folder, the WhatsApp thread. They exist because the official system does not do something, and that gap is part of the process whether it is documented or not.
- Log the exceptions, not just the happy path. Ask what happened the last five times it did not go normally. The exception rate decides whether a workflow can run unattended.
- Note who catches the mistakes today, and how. This is the single most important thing to know before automating anything, and it is never in the process documentation.
The four criteria that decide
With a list of real processes, four properties decide the order. This is the scoring we use across our own engagements, and the rest of our automation articles refer back to it rather than restating it. Score each one honestly — the fourth is the one teams skip and regret.
- Frequency. Daily beats monthly by an order of magnitude, because the payback compounds and because you will find the edge cases within a week instead of within a year.
- Predictability of the path. Where roughly nine runs in ten follow the same route — the ratio we use as a working threshold, not an industry figure — the tenth can be handed to a human. If the route changes every time, you are looking at a judgment task rather than a rule, and the automation will spend its life in exception handling. The line between the two decides how the step has to be built and checked.
- Cost of an undetected error. Not the cost of an error — the cost of one nobody notices for a month. A wrong invoice discovered immediately is an annoyance; the same error repeated silently across a quarter is a different category of problem.
- Visibility of the output. Something a person reads, sends or acts on shortly afterwards fails loudly. A background sync that quietly writes to a database fails silently, and silent failure is what turns a working automation into a liability nobody is watching.
Notice that none of these criteria is "how impressive is it". The most valuable first automation in a small company is usually an unglamorous handoff — a request that arrives in one place and has to be retyped somewhere else.
Sorting the list into four boxes
Scored honestly, every candidate lands in one of four boxes, and each box has a different next step.
- Automate now. Frequent, predictable path, visible output. Build it, keep it small, and put a person on the exception queue for the first month.
- Assist, do not automate. Frequent but genuinely judgment-heavy — drafting a reply, summarizing a file, preparing a recommendation. The tool produces the draft, a human decides. Most of the value in a small company sits here, and it is the box with the fewest failure modes.
- Fix first. Frequent and painful, but the process itself is unclear or contested. Redesign on paper, run it manually for one cycle, then reconsider.
- Leave alone. Rare, or so variable that every run is a new problem. Automating these costs more in maintenance than the work costs to do by hand, indefinitely.
A workflow that decides rather than executes belongs in the first box only when the decision is narrow and reversible — the trade-offs are set out in what AI agents actually do for a small business. For everything in the "automate now" box, the practical question of what to build it with is covered in automation without developers.
Never automate a broken process
This deserves its own section because it is the failure that costs the most and looks like success for about six weeks.
Every long-running manual process has a person absorbing its defects. They notice the address that looks wrong, chase the field somebody left empty, and quietly re-do the thing that failed. None of that is in the documentation, and much of it is invisible even to them — it has become reflex.
Automate around that person and two things happen at once. The correction stops, and the defect rate becomes visible for the first time — usually attributed to the automation that merely exposed it. The work now moves faster, so bad records propagate to more places before anyone notices.
The order that works: fix the process on paper, run the fixed version manually for one full cycle, confirm it still works without the informal corrections, and only then automate it. If the manual version cannot survive one clean cycle, the automated version will not either — it will just fail faster and more quietly.
What the first project has to prove
The first automation in a company is not chosen for its value. It is chosen for what it proves, because everything after it depends on whether people believe the last one worked.
- It runs without someone babysitting it for a full month, including the week when something upstream changes.
- It fails visibly. When it breaks — and it will — a named person finds out the same day, from an alert rather than from a customer.
- Its result is measurable against a number you recorded before starting. Cycle time, error rate, volume handled. Decide the metric first; the method for keeping that honest is in how to measure the ROI of AI automation honestly.
- The people whose work it touches would object if you switched it off. That is the only adoption metric that has ever meant anything.
Pick something whose success is undeniable within a month, even if a larger project would return more on paper. Organizational permission for the second and third project is bought with the first one, and a six-month build that is still being debugged buys nothing.
Frequently asked questions
What should a company automate first?
The task that happens most often, takes a predictable path, and produces an output someone would notice was wrong. High frequency makes the payback fast, predictability makes it buildable, and a visible output means failures surface before they compound. In most 10 to 100 person companies that describes a handoff between two teams — a request arriving in one inbox and being retyped into another system.
How long should a process audit take?
Two weeks of light observation beats a day of interviews. Ask people what they do and you get the official process; watch what actually happens and you get the real one, including the spreadsheet nobody mentions and the manual step someone added after an incident three years ago. Two weeks is usually enough to see every weekly cycle at least twice.
Should we automate a process that is already broken?
No, and this is the most common expensive mistake. Automation removes the human who was silently absorbing the defects — the person who noticed the wrong address, chased the missing field, and fixed it without telling anyone. Automating around them means those defects now travel downstream at speed. Fix the process on paper first, run it manually for a cycle, then automate what remains.
How do we know whether it was worth it?
Decide the measurement before you build, and measure the same thing after. The honest metrics are cycle time, error rate and volume handled — not hours saved. Anything you cannot measure today, you cannot claim an improvement on afterwards. Why hours saved is the wrong unit, and what survives a finance review instead, is the subject of our separate article on measuring the ROI of AI automation honestly.
If you want the observation done by someone who is not inside the process, that is where we usually start with a new client — two weeks, a scored list, and a first project chosen for what it proves. Book a call.
