What to Automate First With AI, and How to Score It

Every team that gets serious about automation hits the same wall in the first week. Not "can we build it" but "which one first". The list is long, everything on it looks plausible, and the person holding the budget has to choose without a way to compare the options.

Picking wrong is expensive in a specific way: you spend three weeks building something that works perfectly and saves nobody any time. The thing was automatable. It just was not worth automating.

Here is the scoring method we use, and it is deliberately crude, because a sophisticated model would require data you do not have yet.

Score every candidate on four properties

Give each one a mark out of five.

1. Repetition. How often does this actually happen? Not how annoying it is. Daily beats weekly, weekly beats monthly, and anything quarterly is almost certainly not a candidate.

2. Rule-shape. Could you write down what to do in a way a competent new starter could follow without asking follow-up questions? If your instructions keep needing "it depends", you are looking at judgement, and judgement is the expensive kind to automate.

3. Volume of items. Ten invoices a month is a person's job. Nine hundred is a machine's job. The same task changes category entirely with volume.

4. Recoverability. If it gets one wrong and nobody notices for a day, what is the cost? A misfiled email is recoverable. A wrong payment is not. Anything unrecoverable does not get automated end to end, it gets automated up to the point of decision and then handed to a person.

Total the four. Anything over fifteen is a strong first candidate. Under ten and you should probably leave it alone no matter how irritating it is.

The two questions the score does not ask

Can the automation reach the data? A job may score twenty and still be undeliverable because the information lives in a system with no API, or in a PDF that is a photograph of a table, or in somebody's head. Check this before you fall in love with a candidate. It is the single most common reason a promising automation quietly becomes a six-week integration project.

Who owns the exceptions? Every automated process produces cases it cannot handle. If nobody is named as the person who deals with those, the automation does not reduce work, it relocates it into a queue that grows silently until someone notices. Name the owner before you build.

A worked example

A finance team scored four candidates.

Chasing overdue invoices scored 4/5/4/5 = 18. High repetition, rule-shaped, decent volume, completely recoverable if a reminder goes to the wrong person. Strong candidate.

Approving supplier invoices scored 5/2/5/1 = 13. Constant and high volume, but the rules turned out to be full of exceptions and a wrong approval moves real money. This became a partial automation: everything gets prepared and checked automatically, a human presses the button.

Monthly board reporting scored 2/4/2/4 = 12. Once a month, fairly rule-shaped, small volume. Automatable, low payoff. Parked.

Answering "where is my order" emails scored 5/5/5/4 = 19. It won, and it was not on the list the team walked in with. They had brought "the reporting", because reporting is what people complain about in meetings.

That reordering is the normal outcome, not the exception. The winner is usually invisible work that nobody complains about precisely because it is distributed in small slices.

Do this before you talk to anybody who sells software

The scoring takes an hour and it changes what you buy. A team that arrives at a vendor with "we want to automate order-status replies, roughly nine hundred a month, here are the three cases it must never answer on its own" gets a fixed price and a working system.

A team that arrives with "we want to use AI" gets a discovery call.

We run this exercise on your real work in the half-day workshop, and everyone leaves with their own scored list. If you have already done it and know your winner, a paid pilot is the faster route.