Which AI use case should a team build first?

The use case that gets picked is almost always the one that would impress the most people in a meeting, which is a different question from the one that can be delivered. A team picks an ambitious, visible, ambiguous project and then discovers that nothing about it can be tested: there is no record of what a human would have answered, nobody agrees on what good looks like, and a mistake would be expensive.

I have come at this from the support side rather than the lab side. In customer support at a consumer finance app the task inventory is already written down, the escalation rules already exist, and the definition of a bad outcome is already legal and financial rather than aesthetic. That is an unusually honest place to start.

First: does a human already do this every day? If the task is not in someone's routine it is not a workflow, it is an idea. A daily task produces its own training material as a by-product — tickets, decisions, corrections, the notes people paste into each other's threads. You do not have to go and collect anything, which matters enormously for a first project that has no budget for data work.

Second: is the right answer easy to recognise? It does not need to be provable, it needs to be obvious to the person who currently does the job. "Is this customer's issue a card-blocking problem or a KYC problem?" is easy to recognise. "Is this customer at risk of churning?" is not, and the disagreement about the answer will surface after you have built something, not before.

Third: is a wrong answer cheap to undo? This is the condition teams skip. If the model routes a ticket to the wrong queue, a human picks it up five minutes later — cheap. If the model tells a customer their transaction failed when it succeeded, you have a support incident and a trust problem — expensive. Cheap-to-undo is what lets you launch an imperfect system on purpose, and the first system is always imperfect.

Put three to five candidates in rows and the three conditions in columns, and score each one zero to two. Two means the condition is met and you can show evidence for it. Anything that scores below four out of six does not belong in the first project, whatever else is true about it. The point of doing this on paper is that it turns a taste argument into a shared list of facts, and the person defending the ambitious project can see exactly which box is empty rather than being told their idea is bad.

Then write the acceptance criteria before anyone builds. "The draft it produces is used unchanged or lightly edited at least seven times in ten" is a criterion. "Accuracy above 91%" is usually not, because nobody has labelled enough examples to know what accuracy means here, and the number will be chosen to fit whatever comes out. The first criterion is a sentence an operations person can check next week with the work in front of them.

If you can name the person who will check the criterion, and the week they will check it, the use case is scoped. If you cannot, go back to the shortlist. In my own work at FINETIKS the projects that survived this filter were the ones where the human decision was still in the loop on day one — automation that removed the typing, not the judgement.