The tools we have built that work were each asked to do one thing. Not “improve operations”, one specific job with a defined input, a defined output, and a way to measure whether it was correct. That constraint is not a limitation of the technology. It is the only way to know what you are actually building.
The single most reliable predictor of a successful AI build is whether the tool was asked to do one thing. Not “help with customer service.” One thing: classify incoming support tickets into four categories and route them to the right Slack channel. That level of specificity is what separates a tool that ships from one that stalls.
Why Broad AI Briefs Produce Nothing Useful
When a business owner says “we want AI to improve our onboarding,” that is not a scope. It is a wish. A vendor who accepts that brief has given themselves room to charge for six months of work, deliver something marginal, and blame “the complexity of the data.”
Vendors are not evil. But vague scope protects them. Every hour of ambiguity is a billable hour. The client who locks down inputs and outputs in writing before signing has something to enforce. The client who does not has handed over a blank check.
This is the same pattern seen in custom web projects for 20 years. The worst website builds start with “we want something modern and fresh.” The best ones start with “we need a checkout flow that converts mobile users on a 3G connection.” AI is identical.
What “One Job” Actually Means
One job does not mean one feature. It means one clearly bounded problem with a measurable outcome. A single job has:
- A trigger (what starts the process)
- A defined input (what the AI receives)
- A defined output (what it produces, format, destination, length)
- A success measure (how you know it worked)
“Summarise customer feedback from Typeform into a weekly Slack digest, grouped by theme” is one job. It has all four elements. “Help us understand our customers better” has none.
The Scoping Exercise That Takes 30 Minutes
Before writing a brief or talking to any vendor, complete this exercise in writing. It takes 30 minutes. If you cannot complete it, the project is not ready to build.
Write the Job in One Sentence
The sentence must name: what the AI receives, what it does with it, and where the output goes. If it takes more than one sentence, you have described more than one job.
Example that works: The tool reads every inbound sales inquiry from our contact form, classifies it as hot/warm/cold based on company size and budget signals, and posts a summary with classification to our #sales Slack channel.
Example that does not work: The tool helps our sales team be more efficient by using AI to prioritise leads and assist with follow-up.
Define What “Done” Looks Like
Most AI vendors will not define this for you, because it commits them to a deliverable. Write down a specific, measurable outcome before the first call.
Done looks like: “The tool correctly classifies 85% of inquiries, as measured by a human reviewer checking a random 20-inquiry sample each week.” Not “the team finds it useful.”
Write the Out-of-Scope List
This is the most underrated part of scoping. Write down three to five things the tool will explicitly not do. This prevents scope creep from either direction, vendor upselling or internal stakeholders adding requirements mid-build.
Out of scope for the example above: CRM integration, reply drafting, lead scoring by historical close rate, integration with LinkedIn. If those are needed later, they are a new project.
Where Most Builds Go Wrong
Asking the AI to Make Judgment Calls You Have Not Made Yourself
If your human team cannot agree on what a “hot lead” looks like, an AI cannot figure it out either. The AI is applying your rules at scale, not inventing rules you have not written. Before scoping any AI tool, document the decision logic a human currently uses to do the job. If that logic does not exist, the AI build will produce it through expensive trial and error.
Treating Integration as an Afterthought
The tool needs to read data from somewhere and write output to somewhere. Both of those need to be specified in the scope document before any build starts. “We’ll figure out the integrations in Phase 2” is a red flag. Integration is not a detail; it is often 40% of the build time.
A custom AI integration built into an existing custom WordPress development project, for example, requires knowing whether the AI will read from a database, a form plugin, or an API endpoint. Each path has different build complexity. Leaving this vague guarantees cost overruns.
Scoping for the Ideal Version Instead of the Minimum Useful Version
Build the smallest version that would be genuinely useful. Not impressive, useful. If the one-sentence job description can be delivered in a basic form in two weeks, start there. Add complexity only after you have confirmed the core job works.
This applies especially to SMBs that have never run an AI project before. The goal of the first build is to learn what the tool needs to do well, not to build the final version on the first attempt.
How to Evaluate a Vendor’s Scoping Process
You can assess a vendor’s quality before the first invoice by how they respond to your one-sentence job definition.
A competent vendor will immediately ask about inputs and outputs. They will ask what data sources are involved, what format the output needs to be in, and what happens when the AI is wrong. They will tell you what is out of scope before you ask.
A vendor who responds to your one-sentence job with a slide deck of AI capabilities is selling, not scoping. A vendor who says “that’s a great use case, we’ve done similar things for similar clients” without asking a single clarifying question is the same.
The right response to “here is the one job I want this tool to do” is a list of questions. Any other response is a red flag.
The Phase 2 Promise
Watch for proposals that acknowledge your defined scope in Phase 1 but promise a broader vision in Phase 2. Phase 2 rarely ships, and the vendor knows it. Phase 1 is the project. Scope it as if Phase 2 will never happen, because statistically, it will not.
Applying This to Common SMB Use Cases
Customer Support Triage
Job: read incoming support emails, classify by issue type (billing, technical, returns, other), and add a tag in the helpdesk system. No reply drafting, no sentiment analysis, just classification and tagging.
This is a 2-3 week build with a testable output. Measuring success is straightforward: compare AI tags to human tags on 50 tickets.
Internal Knowledge Retrieval
Job: answer employee questions using the company’s existing documentation. Input is a plain-language question. Output is a 2-4 sentence answer with a source link. The tool does not update the documentation and does not answer anything outside the document set.
The out-of-scope list here is critical. Without it, “what can I ask it?” becomes a source of constant scope expansion.
WooCommerce Product Descriptions
Job: take a product data CSV (name, SKU, dimensions, category, materials) and generate a 100-word product description in a defined brand voice. Output is a CSV with the new descriptions. A human reviews and approves before import.
This is one of the cleaner custom AI jobs for ecommerce businesses. It has defined inputs, a defined output format, a human-in-the-loop checkpoint, and a clear success measure (time saved per product vs. manually written copy). For businesses running a custom WooCommerce store, this kind of scoped AI integration can cut description-writing time by 60-80% per product batch, when the product data CSV is clean and consistently formatted. It breaks when product data is inconsistent, categories are undefined, or brand voice has never been documented in writing.
FAQ
How narrow does a custom AI tool’s scope actually need to be?
Narrow enough that a non-technical person can describe the full job in one sentence. If the description requires “and also” or “as well as,” split it into two jobs. Build the first one. In most failed AI projects we have seen, scope that sounded specific on paper actually contained multiple distinct tasks.
What if the job I want AI to do has never been done by a human first?
That is a significant risk. AI tools automate decision logic that already exists somewhere, either written down or in someone’s head. If no one has done the job before, there is no logic to automate. You will spend the build time figuring out the rules, which is expensive and often produces a mediocre result. Document the human process first, even roughly, before scoping the AI.
How do I know if a vendor’s proposal is scoped correctly?
The proposal should name: the data inputs, the output format and destination, what the tool will not do, and a measurable success criterion. If any of those four elements is missing, the scope is incomplete. Ask the vendor to add it. A vendor who refuses or deflects that request is telling you something important.
What does a minimum viable AI scope document include?
Six things: the one-sentence job description, the input data sources and formats, the output format and destination, the out-of-scope list, the success metric, and the human review checkpoint (who checks outputs, how often). One page is enough. A 20-page specification document is not more reliable than a rigorous one-pager.
How long should a scoped custom AI build take?
A correctly scoped single-job AI tool should take 2-6 weeks to build and test. If a vendor is quoting longer for a clearly defined, single-job brief, ask them to explain what is taking the time. Sometimes the answer is legitimate (complex data pipeline, unusual integration). Often it is a scope that is wider than you realised, which means you have more scoping work to do before agreeing to timelines or pricing.
Can I scope a custom AI tool without any technical knowledge?
Yes. The scoping exercise described here, one-sentence job, input/output definition, out-of-scope list, success metric, does not require technical knowledge. It requires knowing your own business process well enough to describe it clearly. The technical decisions (which model, what infrastructure, what integration method) are the vendor’s job. Your job is to define what needs to happen. If a vendor tells you that you need technical knowledge to scope the project, they are either wrong or they want the scope to stay vague.
Start with the Scope, Not the Tool
The worst question to start an AI project with is “what AI tool should we use?” The right question is “what is the exact job, and how will we know it is done?” The tool is a downstream decision.
If you want to talk through what this looks like for your operation, start a conversation. We scope custom AI builds before any commitment. See how we approach this at designodin.com/ai.