Most automation projects that fail did not fail technically. They automated the wrong thing, beautifully.
So before anything gets built, it is worth being deliberate about which job goes first. This is the method we use, and you can run it yourself on a sheet of paper in an afternoon without hiring anybody.
List the jobs, not the systems
Start by writing down the repetitive work your team actually does, in the words they would use. “Enter supplier bills.” “Chase overdue invoices.” “Copy orders from the website into the system.” “Send the weekly stock report.”
Resist the urge to write “integrate the CRM”. That is a solution with no problem attached to it, and projects described that way tend to produce software nobody uses.
Aim for fifteen to thirty items. If you cannot get past five, ask the people doing the work rather than the people managing it. The list is always longer at the desk than it is in the meeting.
Score each one on four things
For every job on the list, put a number from one to five against four questions.
How often does it happen? Daily scores five. Once a quarter scores one. Frequency compounds, and it is the single strongest predictor of whether automation pays.
How long does it take each time? Include the switching cost. A two minute task that requires opening three systems and losing your place in something else costs more than two minutes.
What does an error cost? A typo in an internal note scores one. A duplicate payment, a wrong VAT treatment or a message to the wrong customer scores five. This is where automation quietly earns most of its value, and it is the question people skip.
How stable is the process? Has it worked the same way for a year, or does it change every time a new client is onboarded? High score means stable. This is a scoring question, not a tiebreaker, and the next section explains why.
Multiply the four numbers. Not add. Multiplying is deliberate, because it punishes a low score on any single dimension, and a job that is unstable or harmless should not reach the top of the list by being frequent.
Read the result honestly
The top of the list is usually boring, and that is the point. Supplier invoice entry. Reconciling gateway payouts. Copying orders between a website and an ERP. Nobody writes a press release about any of it, and all of it runs every day.
The jobs people are excited to automate tend to score badly: the clever thing, the thing with AI in the name, the thing a competitor announced. Excitement is not a scoring dimension.
If the exercise produces nothing above a moderate score, the right answer is to do nothing yet, and that is a legitimate outcome. We would rather say so than sell a project.
The three things not to automate
A process that is about to change. Encoding an unstable workflow in software makes it permanent and expensive to alter. If you are mid way through changing how you quote, or you are about to switch accounting systems, wait. The automation will be rebuilt anyway, and it will be rebuilt by someone paid to do it twice.
A process that is broken. Automating a bad workflow produces bad output faster, with more confidence and less chance of anyone noticing. If supplier bills are entered inconsistently today, cleaning that up is the project and the automation is the easy part that follows. This is the most common reason a build disappoints.
A decision that carries real consequences. Anything that spends money, commits to a customer or is hard to reverse keeps a person in the loop. The automation gathers, checks and drafts. The decision stays with your team, which is also what keeps the system trusted enough to actually get used. The moment people stop trusting it, they start keeping their own parallel spreadsheet, and you are paying for two processes.
A worked example
A distributor runs the exercise and ends up with four candidates.
Entering supplier bills happens daily (5), takes four minutes each (4), an error means a duplicate payment (5), and the process has not changed in two years (5). Score: 500.
Chasing overdue invoices happens weekly (3), takes an hour (4), an error means annoying a good customer (3), and the process is consistent (4). Score: 144.
Producing the monthly board pack happens monthly (1), takes a full day (5), an error is embarrassing but caught (2), and the format changes often (2). Score: 20.
Onboarding a new client happens twice a month (2), takes half a day (5), an error means a bad first impression (4), and every client is slightly different (1). Score: 40.
Bill entry wins by a distance, and it wins on the two dimensions that are easy to underrate: it happens constantly and the errors are expensive. The board pack feels like the bigger job because it consumes a whole miserable day, but it happens twelve times a year and its shape keeps changing.
Client onboarding scores low only because of instability. Standardise it first, then it is a strong candidate.
Then do one thing, properly
Take the top item and automate only that. Resist bundling. A project that touches one process can be live in weeks and judged honestly on whether it helped. A project that touches six takes months, and when it underdelivers nobody can tell which part was the mistake.
Measure the thing you said you would improve. Time spent, errors caught, days to close the month. If you did not write the number down before starting, you will not be able to tell afterwards whether it worked, and the conversation becomes about opinion.
Then run the exercise again. The second item on the list is usually easier than the first, because the connections and the habits now exist.
Where this leaves AI
Notice that none of this started with AI. That is deliberate. The question is which job is costing you, and only then which tool fits.
AI earns its place when the input varies: reading supplier invoices that all look different, sorting an inbox, pulling an address out of a paragraph a customer typed badly. A plain rule wins when the answer must be exact: calculating VAT, matching a reference number, deciding whether an invoice is overdue. Most real automations are mostly rules with a model doing one specific job in the middle, and anyone selling you the reverse is selling the brochure rather than the system.
More on where we draw that line, and a worked example of the job that usually comes top of the list, automating supplier invoice entry.
Common questions
How long should the first automation take?
Weeks, not months. If the first one is scoped in months, it is too big, and the risk is not technical, it is that nobody can tell whether it worked.
What if everything scores about the same?
Then frequency breaks the tie. Do the one that happens most often, because it generates the most learning per week and the team feels the change soonest.
Should we automate before or after moving to a new system?
After. Automating a system you are about to leave means building it twice. If a migration is on the table, do that first and design the automation into the new setup.
Do we need to automate at all?
Often not yet. If your list produces nothing above a moderate score, your constraint is somewhere else, and spending on automation will not move it. That is a real answer and we give it regularly.