AI built into your workflow

The short version

Everyone tells you to be using AI. Almost nobody tells you what for. The honest answer for a small business is narrower and duller than the headlines: language models are very good at the repetitive reading and writing your team already does, and mediocre at nearly everything else you have been sold.

• The wins are narrow: reading documents, drafting from precedent, sorting and summarizing, answering from your own files.

• Scope AI to one task, measure what that task costs you in hours today, and build only if the arithmetic works.

• Design for being wrong. A model that is right 95% of the time needs a workflow that survives the other 5%.

• A first AI feature inside an existing system is usually a $3,000 to $8,000 piece of work, not a platform project.

• Attaching a chatbot to your website is not a strategy.

What AI actually does well in a small business

It does the jobs where the input is messy text and the output is structured, and where a human currently does it by reading carefully and typing carefully. That is a smaller category than "anything" and a much bigger one than most owners realize.

The four that come up again and again:

• Pulling line items off supplier invoices, purchase orders and delivery notes — the ones that arrive as PDFs, photos and scans in five different layouts.

• Drafting a first-pass quote from your own past jobs, so an estimator edits instead of starting from a blank page.

• Sorting and summarizing inbound email — what is this, who should see it, what does it need, and is it urgent.

• Answering staff questions out of your own manuals, policies and job history, with a link to the page it came from.

What these have in common is that a person is already doing them, the volume is known, and being wrong is recoverable because a human sees the output before it matters. That combination is what makes a use case buildable.

Telling a good use case from an expensive one

Run the arithmetic before you run a pilot. It is four numbers, and you can usually get them in an afternoon.

• Volume — how many times a week does this task happen? Under about twenty, automation rarely pays for itself.

• Time — how long does one take a person now, honestly, including the interruption cost?

• Cost of being wrong — what happens if the answer is wrong and nobody catches it? If the answer is "we wire money", a human stays in the loop permanently.

• Checkability — can a person confirm the output in seconds? If verifying takes as long as doing, you have saved nothing.

That last one quietly kills more AI projects than accuracy does. Extracting fourteen fields from an invoice is a win because a human can eyeball fourteen fields against the original in five seconds. Generating a long report is often a loss, because checking it properly means writing it yourself.

If the numbers work, the next question is where the feature lives. Almost always the answer is inside the system your team already uses — not in a separate tool they have to remember to open.

What it costs to build, and to run

There are two costs, and they behave very differently. The build is a one-off; the running cost is per document, per email, per question, and it scales with your volume, not your headcount.

For the running cost we do not guess. During scoping we run a sample of your real documents through the model and measure it, then show you the per-item number next to what the task costs you in wages today. If that comparison does not clearly favor building, the discovery work is the cheapest part of any project to walk away from.

Worth knowing: the per-item price of these models has fallen sharply and repeatedly, which means a use case that failed the arithmetic two years ago may pass it now. It is worth re-running the numbers instead of trusting an old answer.

Designing for the model being wrong

It will, so the workflow is designed around it from the start. The engineering that separates a demo from a system in production is almost entirely about handling the wrong answers gracefully.

What that looks like in practice:

• A confidence threshold — anything the model is unsure of goes to a person instead of straight through.

• A review queue where a human confirms or corrects, with the original document side by side.

• Citations — every answer points at the document and page it came from, so it can be checked in seconds.

• Never letting the model take the irreversible action. It drafts the payment; a person approves it.

• Logging every input and output, so when something odd happens you can see exactly what was asked and answered.

One more thing that matters over time: the models themselves change underneath you. A prompt that worked perfectly in March can behave differently after a provider updates a model. If you are on the Care Plan, keeping AI features accurate through those changes is part of it — that is exactly the kind of maintenance nobody warns you about when they sell you a pilot.

Where we say no

AI is a specialty here, which is exactly why we will tell you when it is not the answer. The ones we would turn down or redirect:

• A chatbot on the website because competitors have one. If your customers' questions are answerable by a good FAQ page, build the FAQ page.

• Anything where the output goes to a customer unreviewed and being wrong is a liability — medical, legal, financial or safety advice.

• Replacing a deterministic rule with a model. If the calculation is "if order is over $500, shipping is free", write the rule. It is cheaper, faster and always right.

• Projects whose real problem is that the data is a mess. Clean the data first; a model reading bad records produces confident bad answers.

• "AI strategy" engagements with no named task attached. One thing that works beats a roadmap.

The counter-intuitive part is that the boring uses pay best. Automatically categorizing three hundred emails a week is unglamorous and saves a genuine day of work. A conversational assistant is a great demo and often saves nobody anything.

Where your data goes

Your documents and customer records are yours, and how they are handled is part of the scope, not an afterthought. We build against the Claude and OpenAI APIs, on the commercial terms where submitted content is not used to train the underlying models, and we tell you exactly which provider processes what before you sign anything.

Where your data cannot leave your control at all — a genuine constraint in some regulated and contracted work — that changes the design rather than ending the conversation. It usually means a smaller model running in infrastructure you own, with a different cost and accuracy profile, and we will scope that honestly including the trade-offs.

The useful first conversation is about one task, not a strategy: a single thing somebody on your payroll does over and over, how many times a week, and how long it takes them. If the arithmetic works we will scope it. If it does not, you will have found that out without paying for a pilot.