Most AI projects fail before anyone writes a line of code. Not because the technology doesn’t work, because nobody defined what “working” would actually mean for their operation. We see this consistently: a proposal gets approved, a vendor gets hired, and the first hard question about whose decision changes gets deferred to Phase 2. By then the budget is committed and the ambiguity is baked in. There is one question that cuts this off early.
The Question
“What decision will change, and who will make it, when this AI tool produces its output?”
Not “what will the AI do.” Not “what data will we feed it.” Those are engineering questions. This is a business question. And it cuts through more inflated proposals and wishful thinking than any requirements framework.
If you can answer it, specifically, with a named decision and a named person, you have a viable project. If the answer is “it’ll surface insights for the team,” you do not have a project. You have a hypothesis wearing a budget.
Why This Question Cuts to the Core
Most AI projects die in the space between output and action. The tool works. It produces something. Nobody knows what to do with it.
A Midlands-based e-commerce business paid £22,000 for an AI product recommendation engine in 2024. The tool ran. It generated recommendations. Their merchandising team continued to make buying decisions the same way they always had, by gut instinct and supplier relationships. The AI output never changed a single purchasing call. That is not a technology failure. That is a scoping failure. Nobody asked whose decision changes when the AI speaks.
The question forces clarity on three things at once:
- The output has to be actionable, not “interesting,” not “informative.” It has to feed directly into a decision that someone is currently making without it.
- The decision-maker has to be real, a named person or role, not “the team.” Teams don’t make decisions. People do.
- The change has to be verifiable, you need to be able to look back in 90 days and confirm the decision-making process is different. If you can’t, you have no success criterion.
What Bad Answers Look Like
An AI vendor pitches a customer support automation tool. You ask the question. The answer is: “It will help the team understand sentiment and reduce ticket volume.”
That answer contains no decision, no decision-maker, and no measurable change. It is a description of a feature, not a business outcome. The project is not ready to scope.
Another example: a law firm wants AI to summarize case documents. You ask the question. The answer is: “Our senior partners will still review everything, but it might save some time.”
“Might save some time” is not a decision that changes. The project might still have value, but it needs to be reframed. What specific review step does the summary replace? Who approves the summary as sufficient before escalating to a partner? When those questions have answers, you have a project worth scoping.
The most dangerous answer of all: “We’ll define KPIs in Phase 2.” If a vendor says this, the project is not ready, and the vendor knows it. They are asking you to fund a discovery phase that protects their margin while you absorb the ambiguity risk.
How to Use the Question Before You Sign Anything
Run this as a pre-scoping filter, before any proposal, before any vendor conversation, before you allocate budget.
Write the answer to the question in one sentence. It should have: a subject (the decision-maker), a verb (the decision they will make differently), and an object (the specific output of the AI that enables that change).
Acceptable: “Our operations manager will approve or reject supplier invoices faster because the AI flags discrepancies against our purchase order database before they hit her queue.”
Not acceptable: “Finance will have better visibility into invoice processing.”
If you can’t write the acceptable version, the project is not a technology problem yet. It is a process problem. Fix the process first. AI automation layered onto a broken or undefined process produces expensive broken-process output, faster and in larger volume.
One practical test: describe the AI’s output to the decision-maker and ask, “Would this change how you make this call?” If they hesitate, or qualify it heavily, you have your answer. The tool is not ready to build. The workflow is not ready to automate.
The Connection to Scope Overruns
Projects without a clear answer to this question balloon. A 2025 industry analysis found that AI projects with vague scope routinely exceed budgets by 50–200%. The mechanism is simple: when nobody can define “done” in terms of a changed decision, every iteration feels like progress. The vendor keeps building. The client keeps hoping the next sprint will produce something actionable. Nobody calls it.
Defining the decision and decision-maker upfront creates a natural stopping condition. When the output reliably changes that decision the way you specified, the project is done. That is not a theoretical milestone, it is a testable condition. You can run it in a controlled sprint before committing to a full build. If it works, you scope the production version. If it doesn’t, you’ve spent four weeks, not four months.
This is exactly why we scope custom AI builds before any commitment. Price certainty follows scope certainty. You cannot fix a price on a project that doesn’t know what “done” means. If you want to talk through what this looks like for your operation, start a conversation.
Applying the Filter to Common AI Use Cases
AI Chatbots
Bad framing: “The chatbot will handle customer queries and reduce support load.” Good framing: “The support lead will escalate only tickets the chatbot cannot resolve with 85% confidence, reducing her daily escalation queue from 40 to under 10.”
One has a decision-maker and a measurable threshold. The other has a hope.
AI Content Workflows
Bad framing: “AI will help the marketing team create content faster.” Good framing: “The content manager will publish two additional product pages per week by approving AI-drafted outlines rather than writing them from scratch.”
The second version has a named role, a specific output, and a frequency that can be measured.
AI for Lead Qualification
Bad framing: “The AI will score leads and improve sales efficiency.” Good framing: “The sales director will only assign leads to reps that the AI scores above 70, she currently spends 3 hours per week on triage that this replaces.”
Concrete. Verifiable. A real decision, made by a real person, that changes in a specific and observable way.
If you’re building AI into a custom WordPress development or WooCommerce development project, the same filter applies. Which page does the AI update, under what trigger, approved by whom? If the answer involves a human approving every output indefinitely with no defined escalation path, you have a workflow to redesign before you have a build to scope.
FAQ
Why is this one question more useful than a full scoping checklist?
A checklist answers “what.” This question answers “why it matters.” Most scoping checklists confirm that a vendor has thought through implementation. This question confirms that the client has thought through adoption. An AI tool that nobody uses differently than they worked before, regardless of how well it was built, is a failed project.
What if the AI project is exploratory, like a proof of concept?
Exploratory projects are legitimate, but they still need this question answered at the hypothesis level. What decision are you trying to learn whether AI can change? If you don’t know, you won’t know when the exploration is complete, and you’ll keep spending. Define the hypothesis decision before the first sprint, even if the answer may shift.
Can one AI tool serve multiple decision-makers?
Yes, but scope them separately. Each decision-maker should have their own output definition and their own success criterion. “Multiple stakeholders benefit” is not a scope, it’s a description of a roadmap. Build the version for one decision-maker first. Prove it changes that decision. Then expand.
What does this look like when hiring an AI vendor?
Ask the vendor to answer the question on your behalf, based on what they’ve built. If they can describe a past client, a specific decision that changed, and how they measured it, you have evidence of a credible process. If they give you case study language about “improving efficiency” or “driving insights,” you have marketing copy, not proof.
How early in a project conversation should this question come up?
Before the vendor shows you a demo. Demos are designed to generate excitement about capability. You need to evaluate fit before capability. The question anchors the conversation in your business context, not their technology. Any vendor who resists answering it, or pivots to their tech stack before your decision structure, is telling you something about their process.
Is this question enough on its own, or do I need a full scoping document?
It’s a filter, not a complete spec. Once you’ve answered it and confirmed the project is worth pursuing, you’ll still need to define inputs, data sources, output formats, human checkpoints, and success thresholds. But none of that work has any value if the foundational question isn’t answered first. Start here.