Start with recurring workflows, not with AI products. Create a longlist of business problems, remove ideas that fail basic evidence or safety checks, score the remaining candidates on value, feasibility and risk, and select a balanced pilot portfolio. The first pilot should not be the most futuristic idea. It should be the smallest credible test that can change a real business decision.
1. Build the longlist from work, not from technology
“Where can we use AI?” usually produces a collection of fashionable ideas. A better question is: “Where does recurring work become slow, expensive, inconsistent or dependent on people assembling context by hand?”
In strategy and workshop sessions, I look for five signals:
Interview the people who perform and receive the work. Ask what arrives, what they do next, which systems they touch, where exceptions appear, what requires judgment and what a good result looks like. That produces use cases grounded in an actual workflow.
2. Apply kill filters before scoring
A scorecard creates false precision if obviously weak ideas are allowed into it. Remove or redesign a candidate before scoring when one of these conditions is true:
- No process owner is willing to own the result.
- No meaningful baseline can be measured or reconstructed.
- The required data is unavailable, unusable or not permitted for the proposed system.
- The workflow is so unstable that automating it would lock in confusion.
- The expected volume is too low to justify integration and operating cost.
- An error could create serious legal, financial, safety or customer harm and no reliable approval boundary is possible.
- A simpler process change or deterministic automation would solve the problem better.
Capability is only one condition. A use case also needs a valuable outcome, an owner, acceptable failure modes, usable data and a path into the real workflow.
3. Score value, feasibility and risk separately
Use a 1–5 scale and require a short evidence note for every score. The note matters more than the number: it exposes assumptions that the team needs to test.
| Dimension | Questions | Evidence to collect |
|---|---|---|
| Business value | Does this affect revenue, cost, cycle time, capacity, customer experience, quality or strategic speed? | Volume, time per case, rework, missed opportunities, service level, conversion or other current baseline. |
| Workflow fit | Is the task repeated? Are inputs and desired outputs clear? Is there a bounded definition of done? | Process map, example cases, exception types, owner and downstream user. |
| Data readiness | Can the system access representative, current and permitted information? | Sample documents, system access, data-quality review, privacy and retention requirements. |
| Technical feasibility | Can current models and integrations perform the task at the required quality, speed and cost? | Prototype results, integration constraints, latency, unit economics and fallback path. |
| Adoption readiness | Will the people in the process use it, and does it make their work easier? | User interviews, incentive alignment, training need and operating ownership. |
| Risk and consequence | What happens when the system is wrong, unavailable or manipulated? | Failure-mode review, permission model, human checkpoints, reversibility, logging and escalation. |
Priority = Value × Feasibility × Confidence ÷ RiskUse the formula as a discussion aid, not as mathematics that makes the decision for you. “Confidence” reflects how much of the score is supported by evidence rather than optimism.
4. Distinguish automation, AI assistance and agents
Architecture affects feasibility, cost and risk. If fixed rules can move structured data between systems, use deterministic automation. If a person mainly needs a draft, classification or summary, an AI assistant may be enough. Use an agent when the system must interpret context, choose tools and coordinate several steps toward a goal.
Do not add autonomy merely to make the project sound advanced. More autonomy means more permissions, states, failure modes, evaluation and operational ownership. See the AI Agents for Business guide for the fuller decision model.
5. Select a portfolio, not a single winner
A company should not bet its entire AI program on one difficult transformation. Select a small mix that teaches the organization different things.
This avoids two common traps: a portfolio of trivial productivity demos that never changes the business, or one ambitious platform project that takes months before anyone learns whether users need it.
6. Turn the top candidate into a pilot brief
The pilot should answer a decision: should we scale, redesign or stop? Write the brief before selecting a vendor or building an integration.
- Business outcome: the result the workflow should improve.
- Current baseline: time, cost, quality, conversion, backlog or another measure.
- Workflow boundary: where the pilot starts and ends.
- Users and owner: who uses it and who is accountable.
- Representative test set: normal cases, difficult cases and known exceptions.
- Permissions: what the system can read, write or execute.
- Human checkpoints: which outputs or actions require approval.
- Success criteria: the evidence that would justify the next investment.
- Stop conditions: the result that means the idea should be paused or rejected.
7. Measure the operating result, not the demo
A polished output in a controlled demonstration is not proof of a working system. Evaluate the full workflow on representative tasks. Useful measures can include task-completion rate, error and escalation rate, time to completion, review time, cost per completed case, rework, conversion or customer satisfaction.
Also measure recovery. When the system fails, how quickly can a person understand what happened and complete the work? A less autonomous system with clear escalation can outperform a more impressive system that creates silent errors.
A 90-minute prioritization session
| Time | Activity | Output |
|---|---|---|
| 0–15 min | Confirm business goals, constraints and decision owners. | Shared definition of value. |
| 15–35 min | Map workflows and collect friction signals. | Use-case longlist. |
| 35–50 min | Apply kill filters and merge duplicates. | Shortlist worth scoring. |
| 50–70 min | Score value, feasibility, confidence and risk with evidence notes. | Ranked candidates and assumptions. |
| 70–85 min | Select a pilot portfolio and identify missing evidence. | 1–3 candidates. |
| 85–90 min | Assign owners and the next validation step. | Immediate action, not another idea list. |
Common prioritization mistakes
- Ranking ideas by executive enthusiasm instead of business evidence.
- Using one generic ROI estimate for very different workflows.
- Ignoring integration, change management and ongoing evaluation cost.
- Calling broad employee access to a tool a pilot.
- Choosing a use case with no process owner.
- Optimizing for maximum autonomy instead of reliable performance.
- Scaling before measuring the baseline and the review burden.
Frequently asked questions
How many AI use cases should a company prioritize?
Keep the active portfolio small enough to learn. For many organizations, three to five well-defined candidates and one to three focused pilots create more value than dozens of disconnected experiments.
Which AI use case should be first?
Choose a recurring, measurable workflow with a committed owner, accessible data, controlled failure consequences and enough volume to matter. The best first use case is often important but not existential.
Should expected ROI be calculated before the pilot?
Estimate the value range, but label assumptions. The pilot should replace the weakest assumptions with observed evidence about quality, review time, operating cost and adoption.
What if the highest-value use case is also the highest-risk?
Reduce the scope or autonomy. Start with decision support, a read-only workflow, a limited user group or mandatory human approval before moving toward higher-consequence actions.
Alex Kap works with leadership teams on opportunity mapping, use-case prioritization, pilot design and implementation planning.