The first project determines whether there is a second one. Choose badly and the programme stops there, regardless of how good the technology was.
Here is the selection method we use, which is deliberately conservative.
Score every candidate on four things
Frequency. How often does this happen? Daily beats weekly beats monthly. Volume is what turns a small time saving into a real one, and it is also what gives you enough instances to notice when something goes wrong.
Definability. Can you state what a correct outcome looks like, in a sentence, before you build anything? If you cannot, stop. This single criterion eliminates most bad projects.
Blast radius. What happens if it gets one wrong? A misfiled document is recoverable. A payment to the wrong account is not. Start where mistakes are cheap.
Ownership. Is there someone other than you who will notice if it stops working? Systems nobody owns degrade silently.
A candidate that scores well on all four is a good first project even if the time saving is modest. A candidate that scores badly on definability is a bad project regardless of how much time it would save.
Deliberately choose something boring
The instinct is to start with the most painful, most complex problem, because that is where the frustration is. This is exactly backwards.
The first project's job is not to solve your biggest problem. It is to teach you how these systems fail in your business, with something small enough that failure is survivable. You want the lesson, cheap.
Do not start with anything customer-facing
Internal first. The output goes to someone who works for you and will tell you when it is wrong, rather than to a client who will simply think less of you and say nothing.
We ran our own systems internally for a considerable time before anything touched a client interaction, and that sequencing was not caution — it was how we found the failure modes.
Write down the current process first
Not the process as it is documented. The process as it actually happens, including the workarounds and the person who checks the thing nobody mentions.
Most first projects fail here rather than in the technology. The automation is built for the official process, which is not the one running the business, and the gap only surfaces once it is live.
Set the success measure before you start
"It saves time" is not a measure. Hours per week, error rate, turnaround time, cost per item — pick one, record the number now, and check it in ninety days.
Without a pre-recorded baseline you cannot tell whether it worked, and you will end up defending the decision with anecdote. That is also, as it happens, the same evidence a buyer would want if you ever sell the business.
What to expect
The first attempt will need rework. Budget for it, and do not treat it as failure — it is how the requirement gets discovered.
More on that in Why AI Projects Stall at 80% Complete.