Every company has a list of things that "should be automated". The list is usually long, and the first item picked is often the one that annoys the most senior person. A more reliable way is to score the candidates on a few plain questions and start with the highest total.
List the work as it is really done
Ask the people who do the work to describe a normal week. Not the official procedure, the real one: which files they open, what they copy from where, who they wait for. Write each repeated activity as one line with a rough count of how often it happens and how long it takes. Most teams find fifteen to thirty candidates in an hour or two.
Score each candidate
Four questions separate good candidates from poor ones.
- How often does it happen? Daily work repays automation quickly. Something done once a quarter rarely does.
- How stable are the steps? If the procedure changed three times this year, automating it now means rebuilding it three times.
- Can the data be reached? Systems with an API or a clean export are easy. Information that exists only in email threads and phone calls is not.
- What does an error cost? A wrong internal label is cheap. A wrong payment is not. Costly errors are not excluded, but they need a review step, which adds work.
Give each a score from one to five and add them up. The exact numbers matter less than doing the comparison at all.
What usually ends up at the top
The winners are often unglamorous. Copying new customer details from a form into the CRM and the accounting system. Sending a standard document when a deal reaches a certain stage. Building the same weekly report from three exports. Matching payments to invoices. Each takes minutes, happens constantly, follows fixed rules and touches systems that can be connected.
What to leave for later
Leave out processes that are still being designed, that depend on negotiation or judgement at every step, or that only one person understands and cannot yet explain. Automating an unclear process produces unclear results faster. Fix the process first, on paper, and automate once it has been stable for a while.
Where AI fits
Many good candidates need no AI at all. Moving structured data between two systems is a job for ordinary integration code, which is cheaper and fully predictable.
AI earns its place when a step involves unstructured input: reading an email to decide what it is about, pulling fields out of a scanned invoice, summarising a long request. Even then, the surrounding steps stay as plain rules. A useful design question for each step is "could a fixed rule do this?" If yes, use the rule.
Start with one, finish it properly
Pick the top candidate and take it all the way: error handling, alerts when it fails, a way to see what ran, and a short written description of how it works. A finished small automation teaches the team what the next ones need. Five half-built ones teach nothing and create five things to worry about.
Measure before and after
Record how long the task takes and how often errors occur before you automate. Check again a month after. This shows whether the work paid off, and it gives you real figures for deciding what to do next, instead of impressions.
Summary
Write down the real work, score each activity on frequency, stability, data access and error cost, and automate the top one completely before starting the second. This assessment is the first step of our AI automation service. If you would like help building your list, get in touch.