Validate The AI Opportunity Before You Promise It
A workflow can look like a great AI pilot while the proof is still scattered across people's inboxes.
That is the gap I think many SMB operators will run into as AI moves from demos into real business process. The discovery conversation sounds strong. The pain is real. The spreadsheet is messy. The team can describe the manual work clearly enough that an AI solution feels obvious.
Then the work hits the operating details.
The system owner has not approved access. The sample files are incomplete. The team agrees the workflow is painful, but nobody has measured the current cycle time. The person who knows the exception rules is on vacation. The software vendor allows exports, but only through a report that does not include the field everyone assumed would be available.
At that point, the AI opportunity is not bad. It is just not validated yet.
Take a small brewery trying to clean up packaging invoices. The supplier invoice does not match the purchase order because quantities changed after artwork approval, receiving happened in partial shipments, and production still needed cans on time. AI can help reconcile that mess. It can compare the invoice, PO, receiving notes, and approval trail faster than a person jumping between folders.
But the operator should not let "AI can read the documents" turn into "this workflow is ready to automate." Someone still has to confirm which variances are acceptable, who can release a supplier hold, which evidence counts as receiving proof, and what dollar threshold needs human review. The value case also needs a baseline: how often does this happen, how long does it take, and what does a delayed packaging supply actually cost?
A mortgage broker has a similar version of the problem. A borrower responds to a condition request, but the statements are outdated. The processor may mark the item as responded, while underwriting still considers it unsatisfied. AI can help catch the stale statement, route the right follow-up, and keep the file moving.
The unsafe move is to promise "condition automation" before proving the difference between a reply, a valid document, an underwriting-ready condition, and an exception that needs a licensed human to decide. The workflow does not need more confidence theater. It needs validation.
For operators, I would treat this as a separate stage between identifying an AI use case and committing to the project.
Opportunity validation should answer a few plain questions:
Do we have permission to touch the systems and data involved?
Do we have representative examples, not just the clean ones?
Can the current workflow owner explain the exception rules?
Can we run a narrow feasibility test without disrupting the business?
Do we know the baseline cost, delay, error rate, or rework we are trying to improve?
Do we know which output is a recommendation, which is a draft, and which is allowed to trigger action?
This stage is not bureaucracy. It is how you make AI safer and more useful at the same time.
Most AI resistance inside small businesses is not philosophical. People resist because they can see the unspoken details that the demo skipped. They know the customer who always emails instead of using the portal. They know the supplier whose invoice never matches the PO but is usually right. They know the document that looks complete until a regulator or underwriter asks for the specific attachment.
Opportunity validation turns that judgment into visible operating knowledge. It gives the team a place to record dependencies, access status, example files, stop conditions, review owners, and the first measurable win. It also gives the business permission to say "not ready yet" without killing the idea.
That is the practical reframe: do not ask whether an AI idea is exciting enough to propose.
Ask whether the opportunity has been validated enough for the business to trust the next commitment.