The 5 questions that disqualify an AI use case in 10 minutes

The most expensive AI projects we see weren’t the ones that failed. They were the ones that should never have started. Six months of work, real money spent, a deployment that technically works — and a business outcome nobody can defend in a board meeting.

The good news: most of these were disqualifiable in under 10 minutes of honest questioning at the kickoff. Here are the five questions we ask before any engagement crosses the line from exploration to build. If a use case can’t clear all five, we don’t build it — and neither should you.

Disqualifying early is the highest-leverage skill in AI consulting. Every hour spent killing a bad idea in week 1 saves twenty hours of rework in month 4.

1. Can you draw the "before" on one page?

If the current state of the workflow can’t fit on a single page — boxes, arrows, decision points, owners — you don’t understand the process well enough to automate any part of it. AI applied to an unmapped workflow doesn’t fix the workflow; it encodes the confusion.

We ask this question in the first 10 minutes of every discovery call. About one in three use cases fails right here. The fix is not to start an AI project — it’s to spend two weeks doing process mapping with the actual operators and come back with a one-pager. Often, once the map exists, the operators themselves spot the fix without any AI.

2. What "wrong" looks like — can you describe it concretely?

AI systems are probabilistic. They get things wrong. Before you build, you need to know — exactly — what the failure modes are and who carries the consequence.

The disqualifying signals:

• Nobody can describe a wrong answer. Means the success criteria are too vague to evaluate. Build will fail acceptance because acceptance isn’t defined.
• Wrong is catastrophic and ungoverned. If the AI gets it wrong and a patient is harmed / a contract is misfiled / a refund is wrongly issued, and there’s no human checkpoint, you’re shipping liability not productivity.
• Wrong is undetectable. If you can’t tell the AI is wrong without doing the underlying work anyway, you haven’t saved any time.

The pattern we look for: wrong is recoverable, detectable, and bounded. A draft email a human reviews is recoverable. A categorisation that gets re-checked weekly is detectable. A summary that points back to the source documents is bounded. Each of those passes the question. An autonomous trade execution with no human approval doesn’t.

3. Does the value land on a single P&L line you can name?

"Improve productivity" is not a value statement. "Reduce AR collection cycle from 47 days to 32 days, freeing $180K of working capital" is a value statement. If the sponsor can’t name the P&L line and the magnitude, the ROI conversation will degenerate the moment the project hits its first obstacle.

The three shapes of clean value land:

1. Time recovered → headcount avoided or redeployed. 12 hours/week × 50 weeks × $60/hour = $36,000/yr. Multiply by the number of people doing the task. Defensible.
2. Cycle time compressed → working capital freed or revenue accelerated. Faster proposal turnaround → higher win rate. Faster AR → less DSO. Clean.
3. Error rate dropped → cost-of-defect avoided. Fewer rebills / fewer chargebacks / fewer clinical re-tests. Each defect has a dollar value; multiply by the rate reduction. Defensible.

If the use case doesn’t land on one of these three shapes, you’re building something cool, not something the business will fund a second phase of.

4. Do you have the data, today, in a form you can use?

The most common reason AI proofs-of-concept don’t make it to production is data — and not in the way most people think. The problem is rarely "not enough data." The problem is access, quality, or governance.

The four data-readiness checks:

• Is it accessible? If the source system is a legacy ERP nobody can get API access to without a 6-week change request, the project timeline just doubled.
• Is it labelled or labellable? Supervised use cases need ground truth. If you have 50,000 documents but no examples of the categorisation you want the model to learn, you have a data-labelling project, not an AI project. Price it accordingly.
• Is it allowed? PII / PHI / contractual restrictions on data use. Vendor MSAs that prohibit sub-processing. Customer data that needs explicit consent before AI processing. Resolve before you start, not after legal asks.
• Is it representative? Six months of data from before the business pivot doesn’t reflect the world the model will operate in.

5. Who owns it on day 91?

AI systems are not deploy-and-forget. Models drift. Source systems change schemas. Prompts that worked in March stop working in September because OpenAI updated the underlying model. Someone has to own the thing.

The disqualifying answers:

• "The consultant." Then you’re renting capability indefinitely, which is fine if priced honestly and acceptable to the sponsor — but most clients haven’t budgeted for that ongoing cost when they think they’re buying a project.
• "IT, I guess." Means nobody. IT has no time and no domain knowledge of why the prompt is the way it is. The system will degrade silently until business users stop trusting it.
• "We’ll figure it out." Translation: nobody. Same outcome as above, slower.

The good answer is a named human, ideally in the business function that benefits, with a documented playbook for monitoring, escalation, and decommissioning. If they don’t exist, the use case is premature. Build the operating model before the model.

How to apply this

Walk through any AI candidate use case you have on the backlog. Answer all five questions out loud, in front of the sponsor and the actual operators. If any question gets a wobbly answer, mark the use case yellow. If two get wobbly answers, it’s red — park it until you can answer them.

Three or more wobbles? Kill it. The hardest part of this framework is killing things you’re emotionally invested in. The opportunity cost of a bad AI project isn’t the project cost — it’s the better one you didn’t start because the team was busy.

What a green-light use case actually looks like

For contrast, a use case that clears all five looks like this:

• Before: "Account managers spend 3-4 hours a week building client status reports by copy-pasting from three systems. Map fits on one page; we sat with two AMs for a morning to draw it."
• Wrong looks like: "The draft includes the wrong client name or mis-quotes a number. AMs review every draft before sending. Failure is detectable in the review step and recoverable by editing."
• P&L land: "12 AMs × 3 hours/week × 48 weeks × $75/hour fully loaded = $130K/yr. Soft upside on capacity to onboard more accounts without hiring."
• Data: "All three systems already have APIs. We have access today. No PII issues — this is internal account-status data."
• Day 91 owner: "Sarah, Head of Client Success. She’ll own the prompt library and a weekly 30-min review with one of our AMs."

That’s a use case worth building. It will ship in 4-6 weeks, recover its cost in under a quarter, and the operating model is real. Most use cases we’re shown don’t look like this on day one. The job is to either get them there — or stop.

Bottom line

AI strategy is mostly disqualification. The 80% of energy that goes into picking what to do has to include serious energy on what not to do. The five questions above are the cheapest way we know to spend that energy.

If you want to walk a candidate use case through the five questions with us, the free 8-minute AI Readiness Assessment is the cleanest place to start. It’s built around exactly this disqualification logic.