What a Small Business AI Consultant Actually Does

Search for an AI consultant for a small business and every result is a landing page. Logos, a list of industries served, a paragraph about transformation, and a button to book a call. None of them describe what happens between signing and shipping, which is the one thing you would need in order to compare two of them.

That gap is not an accident. An engagement described in specifics can be judged, and one described as a partnership cannot. So here is the specific version: what the first piece of work contains, what is left running afterwards, and what to ask before you sign anything.

The first engagement is a scoping job, not a build

The most expensive mistake a small business makes with AI is buying a build before anyone has decided what is being built. The first engagement should therefore produce decisions rather than software, and it should be short enough that the decisions are still cheap to change.

What it should hand you at the end is a shortlist of candidate workflows with an honest note on each about why it is or is not a fit, one chosen workflow, and a written definition of what working means for it. That last item is the one that gets skipped, and it is the one that later decides whether anybody can tell if the thing succeeded.

A proposal that names a model, a framework or a vendor before it names a workflow has the order backwards. The model is close to the last decision, not the first, and it is the decision most likely to be revised after launch anyway.

Three properties decide whether a task should be automated at all

Most back office work sorts quickly on three questions, and the sort is worth doing yourself before anybody quotes you for it.

Does the task have a stable input? Invoices in a consistent format, support tickets in one queue, a form somebody fills in. Work that arrives in an unpredictable shape needs a person deciding what it even is before any model gets a turn.

Can the output be checked? Not checked by a human every time, necessarily, but checkable in principle by someone who did not do the work. If the only way to know the answer is wrong is to redo the whole task, you have not saved anything.

Is the failure mode tolerable? A wrong answer that is caught and corrected costs a few minutes. A wrong answer that reaches a customer, a regulator or an accounting system costs a great deal more, and the difference is not about model quality, it is about what sits between the output and the outside world.

Tasks that fail the third question are not off the table, they simply need a review step, and a review step changes the economics. Automation that still requires a person to read every output is worth having when reading is much faster than writing, and worth nothing when it is not.

The bill has two halves and only one of them gets quoted

Every proposal quotes the build. Almost none of them quote the running cost, and the running cost is the half that lasts.

Usage of a hosted model is billed per token, and the text going in and the text coming out are priced on separate lines rather than pooled. So the question to ask about any proposed feature is not how much text is involved, it is which direction the text is travelling, and the current rate card for whichever model you land on is what turns that into money. We set out the full structure of what you are billed on, and where to read the live rates, in a piece on how this pricing is put together.

Rather than accepting an estimate, compute it. Take one realistic request from the workflow you are considering, count what it actually sends with a token counter, and put that through the LLM cost calculator at the volume you genuinely expect. That takes a few minutes and it is the number that decides whether the whole idea makes sense, so it should not be a number somebody else supplies.

What to ask before you sign

Six questions, all of which a competent consultant can answer immediately and a vague one cannot.

• Which single workflow are we starting with, and why that one rather than the others?
• What does working mean for it, stated so that we could both agree afterwards whether it happened?
• Who or what checks the output, and how often?
• What happens when the model is wrong, and where does the wrong answer stop?
• What does this cost per month to run at our current volume, and at twice it?
• What do we own at the end, and can somebody else maintain it?

The last one matters more than it sounds. A workflow that only its author can change is a dependency you have bought rather than a capability you have gained.

You can do the first part without hiring anybody

The honest answer for a lot of small businesses is that the readiness is not there yet, and that is a real answer rather than a failure. Data spread across systems nobody can query, no agreement on which process is the painful one, or a workload too small to repay any build.

Our AI readiness assessment walks the same questions a scoping engagement opens with, across data, use cases, skills and infrastructure, and it costs nothing but a few minutes. If the result is that one workflow stands out and the running cost pencils, you are ready to have a much shorter and much better conversation with whoever you hire. If it is that nothing does, you have saved yourself the engagement.