Most first AI projects are chosen the wrong way round. Someone sees a demo, imagines it inside their business, and works backwards to a use case. The projects that survive contact with production start from the opposite end: a task that already costs real hours, every week, in a process someone can describe.
Score every candidate on four numbers
Write down every repetitive task your team does. For each one, collect four numbers before you argue about technology.
- 01Frequency: how many times a week does this happen?
- 02Duration: how long does one pass take, honestly measured rather than estimated?
- 03People: how many staff touch it, and at what salary band?
- 04Error cost: what does one mistake cost in rework, refunds or goodwill?
Frequency times duration gives hours per month. Hours times loaded salary gives the annual cost. That number is your budget ceiling and your patience limit. A task costing $9,000 a year does not justify a $40,000 build, no matter how satisfying the automation would be.
Prefer volume over sophistication
Teams reach for the hardest problem because it feels like the best use of AI. It is usually the worst first project. A high-volume, low-variance task gives you many chances to observe the system, catch failure modes cheaply and build trust. A rare, high-stakes task gives you neither volume to learn from nor room to be wrong.
A useful filter: if the task happens fewer than twenty times a month, it is rarely worth automating first, however painful it feels.
Check the process is worth automating at all
Automation makes a process faster, not better. If the exception rate is high, the handoffs are unclear or the rules live in one person's head, you will encode the mess and run it at speed. Practitioners writing about legacy integration make the same point repeatedly: a well-designed process with AI beats a broken process with AI every time.
The tell is simple. Ask two people to describe the process independently. If the descriptions differ materially, fix the process before you automate it, or scope the automation to the part everyone agrees on.
Name the person whose week changes
Every automation that sticks has an owner who feels the benefit personally. If nobody's Monday gets better, nobody will report the edge cases, nobody will defend it during a bad week, and it will quietly fall out of use. Pick a project with a name attached.
What a good first project looks like
- Happens daily or many times a day
- Takes minutes rather than seconds, so the saving is measurable
- Has a clear right answer that a person can verify quickly
- Touches systems you can read from, even if only by email or export
- Fails safely: a wrong output costs a correction, not a customer
That description is deliberately unglamorous. Invoice entry, ticket triage, appointment reminders, quote drafting, applicant screening. These are the projects that pay for the interesting ones later.