Most AI projects don’t fail because the technology didn’t work. They fail because nobody agreed on what the thing was supposed to do before the build started. The scope document, or the absence of one, determines the outcome before a line of code is written. What follows is what we check before we touch anything.
Vague Scope Is a Vendor’s Best Friend
A well-scoped AI project limits what a vendor can charge. A poorly scoped one gives them room to expand, delay, and bill for rework that was always going to be needed, they just didn’t mention it.
The 50–200% budget overrun pattern in AI projects isn’t a technology problem. It’s a scope problem. When the deliverable is defined as “an AI that helps with customer service” instead of “an AI that classifies inbound support emails into four categories and routes them to the correct queue within 30 seconds, with a human review step for any email with confidence below 85%,” the vendor has room to interpret, expand, and redefine what done looks like.
The phrase “it depends on the data” is not an answer during scoping. It’s a hedge. Good vendors run a data readiness assessment before quoting. If your vendor won’t commit to anything until they “see the data,” that’s a signal they’re pricing in unlimited rework, at your expense.
What Inputs and Outputs Actually Mean
Most scoping guides are written for data scientists. This one is written for the person signing the cheque.
Inputs: What Your AI Needs to Function
Inputs are every piece of data, trigger, or context your AI system needs to produce a result. For a content generation workflow, inputs might be: a product SKU, a title, a target keyword, and a word count. For an invoice processing tool, inputs are: a scanned PDF, a vendor lookup table, and an approved expense category list.
Define inputs explicitly, format, source, frequency, who maintains them. If inputs aren’t ready or reliable, the project will stall. Most stalls happen here. The AI was fine; the data pipeline wasn’t.
Outputs: What Gets Produced, in What Format, Delivered Where
An output definition answers four questions: What is produced? In what format? Delivered to which system or person? Within what timeframe? “A summary” is not an output definition. “A 3–5 sentence plain-text summary, written to the inbox of the assigned sales rep, within 10 minutes of a form submission” is.
Write the output definition before any build work starts. If the vendor can’t confirm it, the scope isn’t tight enough.
The Human-in-the-Loop Question
Most AI systems that work in production include a point where a human reviews, approves, or corrects output before it acts on anything consequential. Define that checkpoint upfront. Who reviews? On what schedule? What triggers an escalation? What happens when the AI gets it wrong?
Not defining this is how AI tools quietly make expensive mistakes for months before anyone notices.
The Pre-Contract Scoping Checklist
Before signing anything, work through these five items. If you can’t complete them, the scope isn’t ready, regardless of what the vendor says.
1. Define the Problem in One Sentence
If you can’t describe the problem your AI will solve in one sentence, you don’t have a problem definition, you have a wish. “We want to use AI to improve efficiency” is not a problem. “Our support team spends 4 hours per day manually sorting inbound emails into queues” is a problem. That sentence determines whether AI is the right solution, what the AI actually needs to do, and how you’ll know it worked.
2. List Every Data Source Your AI Will Touch
Name every data source. Note whether it’s clean, structured, and accessible, or whether it needs work. If a data source needs cleaning or transformation before the AI can use it, that’s a separate workstream. It should be scoped, quoted, and scheduled separately, not buried in the AI build line item.
3. Write the Output Definition Before You Build Anything
Described above, but the checklist version is: format, destination, timing, volume, edge cases. What does a successful output look like? What does a failure look like? Who decides?
4. Establish Measurable Success Criteria
“The AI works well” is not a success criterion. “The AI correctly classifies 90% of inbound emails with no human correction, measured over 30 days in production” is. Success criteria should be measurable before launch, not defined after. If your vendor won’t commit to criteria in the contract, ask why.
5. Name What Is Explicitly Out of Scope
The out-of-scope list is as important as the in-scope list. If the contract doesn’t say the AI won’t integrate with your legacy ERP system in Phase 1, the vendor can claim that was always implied when you ask about it in month 3. Every “we’ll figure that out later” from a vendor should become a line in the out-of-scope section, or a priced item.
Red Flags in an AI Vendor’s Scoping Process
These aren’t edge cases. They show up in most SMB AI proposals.
Proposals That Skip the Inputs Section
If a vendor’s proposal doesn’t name the data sources the AI will use, they haven’t scoped the project, they’ve priced a concept. The data pipeline is usually 40–50% of the actual effort in an AI project. A proposal that ignores it is either incomplete or hiding future costs.
Success Metrics That Cannot Be Measured
Watch for metrics like “improved customer experience,” “more efficient workflows,” or “smarter decision-making.” These cannot be measured. They exist to give the vendor an exit ramp when outcomes disappoint. Require a success definition that includes a number, a timeframe, and a measurement method.
”We’ll Figure That Out in Phase 2”
Phase 2 is where budget goes to die. If a vendor can’t tell you what’s in Phase 2, what it costs, or whether it’s optional, then Phase 1 is incomplete. Legitimate vendors can tell you everything that’s out of scope for Phase 1 and give you a fixed or estimated cost for Phase 2 upfront. If they can’t, the project isn’t properly scoped.
A $20,000–$50,000 discovery phase that produces only a requirements document, no working code, no proof of concept, no milestone gates, is a red flag regardless of how it’s framed. A scoping engagement should have a tangible output, not just a longer document that justifies more spend.
Applying This to Common SMB AI Use Cases
AI for eCommerce or WooCommerce Workflows
The most common AI integration on WooCommerce stores involves product data: auto-generating descriptions, classifying products, or processing customer queries. For any of these, the inputs are your product catalogue data, which is often inconsistently formatted, partially complete, or duplicated across systems. Scope the data clean-up before you scope the AI. A custom WooCommerce store with clean, structured product data has fewer integration blockers than one built on spreadsheet imports and manual entries, but the data work is still a separate line item, not something absorbed into the AI build cost.
AI Content Generation Workflows
Input: a content brief, a target keyword, a URL. Output: a 1,500-word draft in a defined format, written to a named style guide, delivered to a staging WordPress environment. That’s a scopeable workflow. “Use AI to create more content faster” is not; it will expand to cover everything and deliver nothing measurable.
AI for Lead Qualification or CRM Automation
Define the qualifier logic before you build anything. What data points determine whether a lead is qualified? What happens to qualified leads, immediate notification, added to a sequence, flagged in the CRM? What happens to disqualified ones? If the business logic isn’t agreed before build, the AI will be built around assumptions that don’t match reality.
Frequently Asked Questions
What is the difference between AI project scope and a traditional software scope?
Traditional software scope defines features and functions. AI project scope also defines data requirements, acceptable output quality, confidence thresholds, and human review points. AI systems degrade over time as inputs change, so scope should include a maintenance and monitoring plan, not just a build definition. The data preparation phase, often skipped in traditional software projects, is usually the largest single effort category.
How detailed does an AI scope document need to be before hiring a vendor?
Detailed enough to define inputs, outputs, success criteria, out-of-scope items, and milestone gates. It doesn’t need to be technical, it needs to be specific. If you can read the scope document and know exactly what will be built, what data it will use, what it will produce, and how you’ll know it worked, it’s detailed enough. If any of those questions are unanswered, the document isn’t ready.
What should I do if a vendor refuses to commit to defined outputs?
Don’t sign. A vendor who won’t define what they’re delivering is protecting themselves from accountability. Legitimate vendors can commit to output definitions because they’ve done the work before and know what’s achievable. “AI is inherently uncertain” is sometimes true at the research frontier, it is not true for a support email classifier or a product description generator. Push for specifics; if they won’t give them, find someone who will.
How do I define “done” for an AI project?
Done is defined by your success criteria, the measurable threshold you agreed on before work started. An AI integration is done when it meets the agreed accuracy rate, handles the agreed volume, runs without manual intervention for the agreed period, and has been reviewed by the agreed human-in-the-loop process. Any vendor who says “done” means “deployed” is defining done too early.
What does a minimum viable AI scope document include?
Six things: (1) a one-sentence problem statement, (2) a list of all data inputs with format and source, (3) a written output definition covering format, destination, and timing, (4) measurable success criteria with a timeframe, (5) an explicit out-of-scope list, and (6) a named human review process for edge cases. With these six items agreed in writing, you have something to hold a vendor accountable to.
Is it normal for AI project costs to run over budget?
Budget overruns of 50–200% are common on poorly scoped AI projects. They are not inevitable. Projects that complete a data readiness audit before quoting, define outputs before building, and lock milestone gates in the contract have better cost outcomes, the overruns aren’t a technology problem, they’re a contracting problem that starts in the scoping phase.
A good scope document is a buyer protection document, not a project management formality. It’s how you hold a vendor accountable when the project drifts, costs climb, or outputs don’t match expectations.
If you want to talk through what this looks like for your operation, start a conversation. See how we scope and build this at designodin.com/ai.