Most small business AI projects do not fail during the build. They fail in week two of discovery, when someone asks where the customer data actually lives and the answer is “partly in the CRM, partly in a spreadsheet, partly in email.” The vendor keeps working. The invoice keeps running. The project is already in trouble, and nobody says so for another six weeks.
This is a self-assessment, not an implementation guide. Work through the four sections and answer honestly. One point for every clear yes. A “sort of” is a no. At the end you have a score out of 28 and a read on whether to start now, fix something first, or hold off. The point is not to talk you out of anything. It is to find what would sink the project before you sign for it.
Dimension 1: Data Infrastructure
Almost every AI use case a small business wants involves feeding it your own information. Invoices, tickets, product catalog, call notes. If that information is hard to reach or unreliable, the output will be unreliable in the same way, and you will have paid to find out.
Where your data lives and whether you can reach it
The first question is not whether you have data. You do. It is whether a system other than a human being can get to it. Data that only appears when someone runs a report and emails a CSV is not accessible. It is a manual process with a spreadsheet at the end.
Check the systems that would feed your intended use case. Does each have an API, a database you control, or at minimum a scheduled export that runs without a person? A no on a core system is not a dealbreaker, but it is a line item that usually costs more than people expect.
Whether it is structured or trapped
There is a real difference between records in a table and information sitting inside PDFs, scans, and email threads. Unstructured sources are workable, and modern AI handles them far better than earlier tools did. They also add extraction, validation, and error handling a clean table does not require.
Accuracy, currency, and history
Accuracy matters more than volume. A customer table with duplicates, inconsistent naming, and dead addresses produces confidently wrong output. Currency matters too. If inventory data refreshes nightly but the use case needs the current number, you have a mismatch no model will fix.
History matters when you want prediction. Forecasting demand, flagging churn risk, or spotting anomalies all need enough past data to establish what normal looks like. Summarizing, drafting, classifying, and routing need far less. Know which kind you have before worrying about this.
A single source of truth and an owner
Name the system of record for each core entity: customers, orders, inventory, jobs or tickets. If two systems both claim to be authoritative for customers, someone has to decide which wins, and that decision belongs to you, not your vendor.
Then name the person responsible for data quality. Not whoever built the spreadsheet. The person whose job it is to notice when data goes bad.
Score this dimension, one point each:
- ☐ Your core data lives in systems with API or database access, not just exports
- ☐ Data for the target use case can be retrieved without a person manually pulling it
- ☐ The data is accurate enough that your own team trusts it for decisions
- ☐ The data is current at the frequency the use case actually requires
- ☐ Most of what the use case needs is structured, or you have accepted the extraction work
- ☐ You have one clear system of record for each core entity
- ☐ A specific named person owns data quality
Dimension 2: Budget
The budget question is not “can you afford AI.” It is whether you have budgeted the shape of the spend rather than a single number. Projects get into trouble when the pilot is treated as the price and everything after it arrives as a surprise.
The four buckets you are actually funding
Discovery comes first: confirming the use case, mapping the data, producing a scoped plan. It is the cheapest phase and the one most worth doing properly, because it catches a bad idea before it becomes a build.
Pilot comes second. A narrow version of the solution: limited scope, real data, real users. It exists to prove the thing works and to price production.
Production comes third, and it is usually a multiple of the pilot, not a small increment. It means error handling, permissions, monitoring, integration with the systems people already use, and the unglamorous work of making something reliable rather than impressive.
Ongoing cost comes fourth and never stops. Platform fees, model or API usage that scales with volume, hosting, maintenance. Usage-based costs are the ones small businesses underestimate most, because they look trivial at pilot volume and are not at full scale.
The cost that never appears on an invoice
Your team’s time. Discovery sessions, reviewing outputs, correcting mistakes during tuning, training everyone else. If the person who knows the process best is also your busiest operator, that time is expensive whether you write it down or not.
How to think about the commitment
Do not budget a project. Budget a sequence with a decision point after each stage. Fund discovery, then decide. Fund a pilot, then decide. Treat the ability to stop after the pilot as a feature, not a failure. Set aside a recurring annual line for maintenance before you start, because a solution nobody maintains quietly degrades and then gets abandoned.
Score this dimension, one point each:
- ☐ You have a budget range in mind rather than a hope
- ☐ You have separated discovery, pilot, and production in your thinking
- ☐ You understand production will cost more than the pilot
- ☐ You have accounted for recurring platform and usage costs
- ☐ You have budgeted for maintenance beyond year one
- ☐ You have accounted for internal staff time as a real cost
- ☐ You can fund a pilot without needing it to pay back immediately
For a sense of how firms structure staged commitments, comparing AI consultants who work with small businesses is a reasonable next step once you have a score.
Dimension 3: Internal Capacity
This is the dimension people score highest and are most often wrong about. Capacity is not enthusiasm. It is calendar time from named individuals who have other jobs.
The owner
One person internally has to own this. Not a committee. Someone who answers questions, chases down access, makes small calls without escalating, and cares whether it works. Without one, a vendor spends the engagement waiting on email replies and the timeline stretches for reasons nobody can name.
The people who do the work today
Discovery requires the people who actually perform the task, not their manager’s description of it, which is always cleaner than reality. Testing needs those same people, on real work, giving real feedback. If they cannot spare a few hours a week, the project gets built against an imagined process.
The decision maker and the sponsor
Someone has to say yes, spend the money, and mean it. In a small business that is often the owner, which is fine. What is not fine is a decision relitigated at every stage with someone who was never in the room. Sponsorship matters most at adoption, when people are asked to change.
Willingness to change how work gets done
Ask the uncomfortable version. If this works exactly as promised, does anyone’s daily routine change? If the honest answer is that everyone keeps working as they do today and checks the tool occasionally, you have not found a use case. You have found a dashboard.
Access and the busy-season test
You need admin access to your own systems. Small businesses often discover mid-project that the CRM was set up by a contractor who left, or that nobody has credentials for the accounting integration. Sort that out before discovery, not during it.
Then run the busy-season test. When your busiest month arrives and your owner disappears for four weeks, does the project pause cleanly or die? If it dies, schedule around your peak or cut scope until it survives an interruption.
Score this dimension, one point each:
- ☐ One named internal owner with real time allocated
- ☐ The people who do the work today are available for discovery and testing
- ☐ A single decision maker who can approve spend
- ☐ Genuine executive or owner sponsorship, not passive permission
- ☐ Someone’s workflow will actually change if this works
- ☐ You have admin access and credentials for the relevant systems
- ☐ The project can survive your internal owner being unavailable for a month
Dimension 4: Use Case Clarity
Vagueness here is expensive. “We want to use AI for customer service” is a category, not a use case. It cannot be scoped, priced, or tested.
Name the task
Say it as one sentence about one task with a start and an end. Draft the first reply to inbound service emails. Extract line items from supplier invoices into accounting. Summarize sales calls into CRM notes. If you cannot compress it that far, you have more than one project.
Describe a good output
Take five real examples from last month and write out, by hand, what a correct result looks like for each. This separates ready projects from unready ones faster than anything else. If your team cannot agree on what good looks like, nothing can be built to produce it.
Measure whether it worked
Pick the measure before the build. Hours returned, turnaround time, error rate, backlog cleared. It does not need to be sophisticated. It needs a baseline you can record today and has to be something you would actually check in three months.
Stability, cost of the pain, and the 80 percent question
A process that changes every quarter means rebuilding every quarter. Stable processes make better first candidates.
The pain also has to be worth the work. If the task takes a few minutes a week, the return will not cover the effort no matter how well it goes. Look for work that is frequent, repetitive, and eating real hours.
Then ask the 80 percent question. If the system handled most cases well and still needed a human for the rest, would you want it? If yes, the use case is realistic. If the value only appears at near perfection, pick something else first.
Score this dimension, one point each:
- ☐ You can name the specific task in one sentence
- ☐ You can show real examples of correct output
- ☐ You have a measure and a current baseline for it
- ☐ The process is stable enough that it will not be redesigned mid-build
- ☐ The task is frequent and consumes meaningful hours
- ☐ The cost of the pain justifies the cost of solving it
- ☐ You would still want it at 80 percent accuracy with human review
Reading Your Score
Add up all four dimensions for a total out of 28.
22 to 28: start now
Move to a scoped discovery with a defined use case, a named owner, and a decision point at the end. Keep the first project deliberately narrow. Winning once on something small buys more internal credibility than an ambitious build delivered late.
14 to 21: fix the gap first, not the AI project
A mixed score almost always concentrates in one dimension. Find your lowest section and treat that as the actual project. If data infrastructure is weak, a consolidation effort is your real first step, and it pays off with or without AI. If capacity is weak, resolve ownership before you talk to a vendor. Do not start the build hoping the gap closes itself. It will not.
Below 14: two things, in this order
Fix use case clarity first. It costs a few hours of honest conversation, and it may reveal that the thing you wanted is not the thing worth doing. Fix data accessibility second, only for the systems that use case needs. Ignore everything else until those two are solid. Budget and capacity get much easier once you can say precisely what you are buying and prove the inputs exist.
The Most Common Reason Small Businesses Stall
It is not money and it is not technology. It is that nobody owns it.
The project starts with real enthusiasm, usually from the owner or one motivated manager. Then quarter end arrives. The person who was going to review outputs has a customer crisis. The vendor asks a question and waits nine days. The pilot technically works but nobody uses it, because using it means changing a habit and no one is held to it. Six months later the subscription is still being paid and the tool is a browser tab nobody opens.
The fix is unglamorous. Name one owner, give them explicit time, and put a recurring review on the calendar with the decision maker in the room. Projects with that survive interruptions. Projects without it do not.
If your score says you are ready, the next question is who does the work. Reviewing AI consultants who specialize in small business engagements will show you which firms scope in stages and which expect a full build commitment before anyone has proven the use case works.
