Foundation · 7 min
What you will learn
- Why choosing the first use case is its own decision
- How to go from a list of problems to a shortlist worth scoring
- Seven dimensions to score candidates on, and the patterns they produce
- What to write down before handing a chosen use case to a trial
Picking the first one is its own decision
It is not the same as deciding whether you need AI. That question comes first and is answered elsewhere in this series. This page assumes you have decided to try something and are choosing what.
It is also not build versus buy, or which vendor. Those follow, once you know what you are solving. Running them together is how a store ends up choosing a tool and then looking for a problem it fits.
And it ends before the trial begins. This page finishes when you have a candidate and the facts that justify it. Designing and running the trial is the next step and keeping the two separate stops; the selection being bent to suit a trial someone already planned.
Start from the problem, not the feature
List the tasks in your store that are expensive, slow, repetitive, or genuinely ambiguous, and describe each one without naming a solution. Poor recovery when search finds nothing. Support classifying the same question all day. Product copy that takes an hour per listing. Forecasts that miss.
Then strike out everything caused by a foundation defect. If the real problem is missing attributes, inventory you cannot trust, unwritten policies or confusing navigation, that is the work, and AI placed on top of it will hide the defect rather than fix it.
Then ask, for each survivor, whether AI actually beats the simpler option. Rules handle known logic. Automation handles predictable sequences. AI earns its place where the answer varies with context, where language or content is the output, or where the volume makes manual review impractical.
Score what is left
Seven dimensions. The first candidate does not need to score well on all of them, but it needs a credible answer to each.
- Business value. Would solving this measurably improve revenue, cost, experience or capacity?
- Data readiness. Are the facts and events it needs available, accurate and owned by someone?
- AI advantage. Does AI handle this better than a rule or a workflow would?
- Risk. What happens when it is wrong, and who absorbs that?
- Operational readiness. Can the team integrate, review, monitor, and support it?
- Measurability. Is there a baseline today and a number that would show improvement?
- Reversibility. Can it be narrowed, rolled back or removed without a project?
Measurability is the one most often waved through. If you are not already recording the number, you cannot prove the feature helped, and the conversation six months later becomes an argument about impressions.
What the combinations tell you
| What the scores look like | Verdict | What to do |
|---|---|---|
| Real value, sound data, failure you can absorb | Strong first candidate | Take it to a bounded trial |
| Real value, but the data is thin | Not ready yet | Fix the data. It is cheaper and you need it anyway |
| Easy to build, limited value | Not first | Novelty is not a reason. It teaches you little |
| High consequence, weak controls | Poor first candidate | Strengthen the controls or pick something safer |
| The right answer is known and fixed | Not an AI problem | Use a rule. It is cheaper and predictable |
| Ambiguous task, and you measure it today | Promising | Compare AI against the current method honestly |
The second row is where most stores land, and it is good news rather than bad. The data work it points to is cheaper than the AI project, you needed it anyway, and it usually makes several other candidates viable at the same time.
Make the first one small on purpose
A narrow workflow with clear inputs, a clear output and a fallback is easier to judge than a programme. Limit the population it touches, the permissions it holds and the consequence of its mistakes while the team learns how it behaves in your store rather than in a demonstration.
The useful test of scope: could you stop it on a Friday afternoon without calling a meeting? If not, it is too big for a first attempt.
Write down five things before you start
Once the use case is chosen, record the baseline you measure today, what you expect to happen, the threshold that counts as success, the level of error you will not accept, and the condition under which you stop. Five short lines.
That hands the next stage something to test against. Without them, a trial produces opinions, and whoever argues hardest decides what the result was.
Key takeaways
- Choosing the first use case is a separate decision from whether to use AI at all.
- Describe problems without naming solutions, then remove the ones caused by foundation defects.
- Score on value, data, AI advantage, risk, readiness, measurability, and reversibility.
- The highest-value problem often has the worst data. That combination is not a first candidate.
- Agree the baseline, the threshold and the stop condition before the trial starts.