AI for Small Businesses: A Realistic Starting Point

A small business has no machine learning engineer, no labelled dataset, no evaluation harness and no tolerance for a project that takes a quarter. Those are not limitations to work around. They are the criteria that select which workflows are worth touching at all.

The constraint that picks the workflow

The determining question is not what a model can do. It is who checks the output, and whether that person was going to do the work anyway. Where the answer is yes, a wrong output costs a moment of correction and the system is safe by construction — no evaluation infrastructure required, because the human in the loop is the evaluation. Where the answer is no, a small business has no mechanism to discover it was wrong, and that is the version that quietly does damage.

Three further filters narrow it usefully. The work must already exist in a system with an inbox or an export, or nobody will do the integration. It must recur often enough for the setup to pay back within weeks. And it must fail visibly — a wrong draft is obvious, a wrong figure buried in a report is not.

Three that fit

Quote and estimate drafting

A trade or service business turns a site visit into a written quote, and the writing is the part that happens at nine in the evening. Photographs plus a few spoken notes go in; a structured draft comes out with line items, quantities and a scope description in the business’s own wording. Prices come from the business’s own price list by lookup, never from the model — that is the whole trick, and it is the same extract-then-compute split as finance. The tradesperson checks the line items, which they were going to write anyway, and sends it the same evening rather than three days later.

Inbox triage with a draft reply

Classify incoming mail into a handful of categories the business actually has — new enquiry, existing job, supplier, invoice, noise — and attach a suggested reply for the routine categories, drafted from the business’s own previous replies. Nothing is sent automatically. Ever. The value is that the eleven emails needing a two-line answer take four minutes instead of forty, and the two that need thought are visible immediately instead of buried.

Supplier invoices into the books

Extract supplier, date, net, tax, total and line items from the PDF or photo, propose a category, and — critically — check that the line items sum to the stated total before proposing anything. A mismatch goes to the human with the difference shown. This is the smallest possible version of the reconciliation architecture, and it works for the same reason: the document contains its own check.

The two-week shadow run

The obstacle to evaluating any of this is that a small business has no labelled test set and will never build one. It does not need to, because it has something better: the work is being done correctly right now by a person.

• Run both, decide with the human. For two weeks, do the work exactly as usual and run the assistant alongside on the same inputs. The human’s output is the ground truth, produced as a by-product of the business operating.
• Count disagreements, not scores. Each day, note the items where the assistant differed and whether the difference mattered. Thirty items over two weeks is enough to see the pattern.
• Write down the bad ones. Three or four categories will account for nearly all the failures — one supplier’s invoice layout, one type of enquiry. Those become either a fix or a documented exclusion, and the exclusion is a perfectly good outcome.
• Time both. The comparison is not accuracy. It is minutes, including the checking, which is the number that actually decides.

The arithmetic, including the check

per item:
  saving = t_manual − (t_check + t_fix × p_wrong)

  t_manual  minutes to do it yourself, today
  t_check   minutes to read and verify the draft
  t_fix     minutes to correct a bad one
  p_wrong   share needing correction — from the shadow run, not a guess

monthly:
  items_per_month × saving × hourly_rate/60      ← the benefit
  items_per_month × tokens_per_item × price      ← the token cost
  setup_hours × rate, amortised                  ← the honest part

Token cost is usually the smallest term by a wide margin at small-business
volumes. The term that decides the answer is t_check.

That last line is the trap this whole page is built around. An assistant that saves ten minutes of writing but requires twelve minutes of careful verification is a net loss that feels like progress, and it is the most common outcome of an unmeasured pilot. The design work that matters is therefore whatever reduces t_check: structure the output so it can be scanned, show the source alongside, flag the fields the system was unsure about. If the arithmetic itself is unfamiliar, cost per request works through the token side and whether a small model is enough usually applies here, because these tasks are short and formulaic.

Your customer list is the whole business

A large company sending data to a provider is sending a slice. A small business sending its inbox is sending the entire customer relationship, the pricing, and often health or financial details of named individuals who never contemplated it. The asymmetry is worth stating because the mitigations are cheap and skipped.

Read what the tier you are on says about using your inputs for training, and prefer a paid tier if the free one is ambiguous — the questions to ask are in do providers train on your data. Keep the assistant off anything that is not needed for the task: triage does not require the attachment, quoting does not require the customer’s previous invoices. And be aware that if you hold personal data about customers, using a processor to handle it is a decision with obligations attached in most jurisdictions — data processing agreements explains what those documents are for. This is not legal advice, and a business in a regulated trade should ask someone who knows the rules in its market.