Most organisations do not lack AI ideas. They have a list of twenty and no way to choose. The usual result is that the idea with the most enthusiastic sponsor gets funded, runs as a pilot for six months and ends without a decision. A short, structured evaluation before spending anything avoids most of that.
Question 1: what problem is this, in numbers?
Describe the problem without mentioning AI. How many times a week does it occur? How long does each instance take, and who does it? What does a delay or an error cost? If nobody can answer, the first task is to measure, not to build.
This step removes more ideas than any other, and that is its value. An idea that sounds very large sometimes turns out to concern four hours of work a month.
Question 2: how would we know it worked?
Name the number that should change and by how much. Handling time per request, share of documents processed without retyping, time to first reply. Also decide how it will be measured and what the current value is. A project with no agreed measure cannot succeed or fail. It can only continue.
Question 3: is the data there?
AI systems work from data: documents, records, past examples. Check four things.
- Does the information exist in digital form?
- Can it be accessed by a system, or is it scattered across inboxes and personal folders?
- Is it reasonably accurate and current?
- Are you allowed to use it for this purpose, given privacy rules and customer contracts?
A use case that depends on data nobody has collected is a data project first.
Question 4: what happens when it is wrong?
Every AI system makes errors. The question is whether the task can absorb them. Drafting a reply that a person reviews tolerates mistakes well. Approving a loan or giving medical guidance does not. For each use case, ask how an error would be noticed, by whom, and what it would cost before it was caught. If the honest answer is that errors would go unnoticed and be expensive, the design needs a human checkpoint or the idea should wait.
Question 5: is there a simpler way?
Ask whether a rule, a database query, a better form or an existing product would solve the problem. Often one does, at a fraction of the cost and with predictable behaviour. Recommending the simpler option is a successful outcome of an evaluation, not a failure of ambition.
The related question is build versus buy. If a product on the market already does this well, buying it is usually right. A custom build makes sense when your data, your process or your requirements for control are specific to you.
Rank the ideas
Place each idea on two scales: value if it works, and likelihood that it can be delivered. Start with the ones that are high on both. Ideas with high value and low feasibility need groundwork, usually on data. Ideas with low value should be dropped, however interesting they are technically.
Plan a small first step
For the chosen idea, define a first version that can be built in weeks and tested on real cases. Set in advance what result would justify continuing and what result would stop it. A stopping rule agreed at the start is what prevents a pilot from drifting for a year.
Warning signs
- The idea began with a technology and went looking for a problem.
- No one in the business will own the result.
- Success is described as "exploring" or "learning".
- The benefit depends on people changing how they work, and nobody has asked them.
Summary
Put a number on the problem, define the measure, check the data, plan for errors and look for the simpler alternative. Then rank, pick one and set a stopping rule. This evaluation is the core of our AI consulting service. If you have a list of ideas and need to choose, we can go through it with you.