The step between "where" and "who"
Most small business owners who explore AI automation reach a natural sequence: identify where AI might help, decide whether the investment category is worth it, and then look for a vendor or consultant. The gap that trips up the most projects sits between those last two steps. You know where you want to apply AI. You have decided to spend. But you have not yet defined what the project actually needs to accomplish, what data it will use, or who in your business will own the result.
That missing scoping step is the difference between a project that delivers a measurable change and one that stalls after the first demo. This article covers the questions to answer about your own operation before you engage anyone outside your business.
If you are still working on identifying where AI fits, start with the identification step. If you are evaluating whether the investment is worth it, start with the cosct-worth-it).
Define the process, not the technology
Before talking to any vendor, you should be able to describe the current workflow in plain language. Who does what, in what order, using what tools, and where does it break? The description does not need technical language. It needs accuracy.
Write down the steps. Name the person who does each one. Name the tool they use. Identify the handoff points where work moves from one person or system to another. These handoffs are usually where the process breaks, and they are where automation has the most to offer.
A wholesale distributor scoping an automation project would not say "we want AI for our warehouse." They would say "the purchase order comes in on the phone, someone re-enters it into the order system, the pick ticket prints, and by the time the invoice goes out the pricing is wrong 8% of the time." That level of specificity is what the scoping step produces.
Know your numbers before the conversation
If you cannot quantify the problem, you cannot evaluate the solution. Before you talk to anyone, estimate what the current process costs in time, labor, errors, or missed work.
How many hours per week does someone spend on this task? How often do errors occur, and what does each error cost to fix? How much time goes into rework, verification, or reconciliation? These numbers do not need to be exact. They need to be honest.
The numbers serve two purposes. First, they give you a baseline to measure whether the project worked. Second, they prevent you from spending more on the solution than the problem costs. A process that consumes two hours a week does not justify a six-month build. A process that consumes two days a week and produces errors that cost you customers might.
Define what "working" looks like
What will change if the project succeeds? The answer should be specific and measurable, not "we want to use AI." Good answers sound like:
- Response time drops from four hours to under 30 minutes - Data entry errors fall below 2% per month - The reconciliation step that takes 10 hours a week takes two - Customer disputes related to pricing drop by half
Each of these is testable. You will know, within the first month of operation, whether the project delivered. If you cannot state what success looks like before the project starts, you will not be able to recognize it after.
Identify the data the project will need
Every AI project depends on data: customer records, transaction history, documents, communications, inventory counts, pricing tables. Before the build begins, the owner should know:
- Where that data lives (which system, which database, which spreadsheet, which email inbox) - What format it is in (structured database records, scanned PDFs, email threads, handwritten notes) - Whether it is accessible (can a tool read it, or does someone have to export it manually) - How clean it is (are records complete, consistent, and current, or are there gaps, duplicates, and outdated entries)
A project that depends on data locked inside a system nobody can export from will stall at integration. A project that depends on clean records will fail if the records are full of duplicates. Knowing this before the first conversation saves weeks of discovery.
Understand who will own the result
Someone in the business will maintain, monitor, and adjust whatever gets built. If that person is not identified before the project starts, adoption stalls. The tool works, but nobody watches it, nobody fixes it when inputs change, and nobody trains new staff on it.
The owner does not need to be a technician. They need to be the person who understands the workflow, notices when something is off, and has the authority to escalate. In a small business, this is often the same person who currently runs the process being automated.
Name that person before the project begins. Make sure they are part of the scoping conversation, not informed after the build is done.
Ask about integration before you ask about features
A common mistake is evaluating an AI tool by its feature list without asking how it connects to what you already use. The best tool in the world is useless if it cannot read from your order system, write to your CRM, or send alerts through the channel your team actually checks.
Before the first vendor conversation, list the systems the project will need to touch. Your CRM, your accounting software, your email, your phone system, your order entry tool. Then ask: can this connect, and how? The answer determines whether the project is a focused integration or a full infrastructure change. Those are very different budgets and timelines.
For more on the systems-connection problem, read about business software integration.
The scoping discipline you already have
If you run a business that buys product, hires subcontractors, or evaluates vendors, you already know how to scope a project. You write specifications. You request quotes. You evaluate capabilities against requirements. You define acceptance criteria before you sign a purchase order.
The same discipline applies to an AI project. Define the process. Quantify the problem. State what success looks like. Identify the data. Name the owner. Check the integrations. Then, and only then, start the vendor conversation.
When you are ready for that conversation, the next step is knowing how to choose the right AI consultant. And if you want help working through the scoping questions for your specific operation, Get Your Free AI Assessment and start with the process that costs the most to run manually.
This week's Industry Spotlight walks through a real-world example of document-chain complexity in wholesale distribution (link), where every one of these scoping questions applies to a specific document pair.
Frequently asked questions
What information should I gather before talking to an AI vendor?
Document the current workflow step by step, estimate the time and error cost of the process, define what a successful outcome looks like in measurable terms, list the systems involved, and identify who in your business will own the result.
How do I define the scope of an AI project for my business?
Start with one process, not the entire operation. Describe every step, handoff, and tool involved. Quantify the current cost in hours, errors, or missed work. State the specific improvement you expect. That description is your scope.
What is the difference between scoping an AI project and choosing a vendor?
Scoping defines what you need. Vendor selection evaluates who can deliver it. Scoping happens first and should be done internally before any external conversation. A clear scope makes vendor evaluation faster and more accurate.
How long does it take to scope a small business AI project?
For a focused, single-process project, most small business owners can work through the scoping questions in a few hours spread over a week. The time goes into documenting the current process, pulling the cost numbers, and confirming where the data lives.
What questions should I ask my own team before starting an AI implementation?
Ask them to walk you through the process exactly as they do it, including the workarounds. Ask where they spend the most time on rework. Ask what information they re-enter from one system to another. Ask what breaks most often. Their answers are the raw material for a clear project scope.
