Choosing your first automation

Teams that get value from AI rarely start with the most ambitious idea on the whiteboard. They start with something small that works, earn trust with it, and widen from there. Picking that first project is the most important decision in the whole program.

The four questions

We score every candidate on four questions. You can do this on a whiteboard in an hour.

How often does it happen? Count it. Tasks that happen hundreds of times a week pay back quickly; tasks that happen twice a month rarely do, however annoying they are.

Can you measure it today? If you can’t say how long the task takes now, or how often it goes wrong, you won’t be able to say whether the automation helped. Pick something with a number attached — handling time, response time, error rate.

What does a mistake cost? A wrong answer about opening hours costs nothing. A wrong refund costs money and trust. Start where mistakes are cheap and reversible, and add approval steps where they aren’t.

Who owns it? Every automation needs a person who cares whether it works: who reviews hand-offs in the first weeks, who notices when a tool changes. No owner, no project.

Candidates that usually win

• Answering order-status and policy questions in support.

• Replying to and qualifying inbound leads outside office hours.

• Reading invoices and matching them to purchase orders.

• Assembling a weekly report from three systems.

• Routing incoming requests to the right person with a summary.

They’re not glamorous. They’re frequent, measurable and forgiving — and each one makes the next project easier, because the integrations, logging and approval patterns carry over.

Candidates that usually lose

• “An assistant that can answer anything about the company.” Too broad to test, too vague to own.

• Anything that depends on a tool without an API. It’ll work in the demo and break in month two.

• A process the team is about to change. Automate the new process, not the old one.

Run it in shadow mode first

Whatever you pick, run it next to the manual process for a week or two before switching over. The automation produces its output; a person does the work as usual; you compare. It’s the cheapest way to find edge cases, and it gives the team evidence instead of promises.

Write down the stop rule

Before you launch, agree what would make you switch it off: “if more than 5% of refunds need correcting”, “if any clinical question gets an automated answer”. It sounds pessimistic. In practice it makes people comfortable saying yes, because the downside has a ceiling.

When to do the second one

When the first automation has run for a month, its numbers are stable and its owner stopped checking every run — not before. The second project goes faster, and by the third you’ll have a backlog sorted by payback rather than by who asked loudest.