Most SMBs we meet have already had the AI conversation. Someone tried a chatbot, someone pasted a customer email into a chat window and was impressed, someone read that their competitors are "leveraging AI" and felt behind. What they usually lack is not enthusiasm — it is a method. The gap between an impressive demo and a workflow you can trust in production is almost entirely process: choosing the right first candidate, measuring before you change anything, designing humans into the right places, testing against real data, and being honest about the results.
This is the playbook we use with clients adding an AI step to an existing workflow for the first time. It assumes no data science team, no custom model training, and tools you can rent by the month. It assumes something else too: that the goal is a workflow your business can depend on, not a demo that impresses at a meeting. Those are different goals, and confusing them is how first AI projects die.
Step 1: Pick the right first candidate
The best first AI workflow sits at the intersection of four properties:
- High volume. The task happens daily, ideally many times a day. Volume is what makes the savings meaningful and what gives you enough examples to test against.
- Low risk. When the AI gets it wrong — and it will, some percentage of the time — the consequence is a small delay or a minor correction, not a lost client or a wrong payment.
- Text-heavy. Language models read and write text. Classification, extraction, summarisation, and drafting are their home ground.
- Clear right and wrong answers. A person reviewing the output can tell in seconds whether it is correct. "Is this email a billing question?" has an answer. "Is this reply empathetic enough?" does not, at least not one two reviewers will agree on.
Good first candidates we have deployed at this stage: triaging inbound emails by type and urgency, classifying documents by kind, extracting fields from invoices and forms, summarising long email threads for handover, drafting routine internal status updates.
Bad first candidates: anything client-facing and autonomous (a wrong reply sent in your name is a reputation event, not a rounding error), anything that moves money or makes a financial judgement, anything where the input is ambiguous and the cost of a wrong guess is high. Those can come later, with humans firmly in the loop, once the organisation has learned to trust and verify. Your first project should be one where a mistake is boring.
Step 2: Measure the baseline before touching anything
You cannot know whether the automation worked unless you know what the manual process costs. Before building anything, measure three numbers over two typical weeks:
- Time per item. Have the person doing the task time themselves honestly on a sample — thirty items is enough. Include the reading, deciding, doing, and any fixing.
- Volume. Items per week, including the peaks. Monday-morning inboxes and month-end surges are part of the design load.
- Error rate. Sample recent completed items and check them. How often is an email routed to the wrong person, a field mis-keyed, a document misfiled? Humans are less accurate than they believe; we typically find 3 to 8 percent error rates on routine classification and keying work. This matters because the AI will be compared against a fantasy of human perfection unless you write the real number down.
Write the baseline somewhere shared. It is the yardstick for step 7, and it is also the business case: time per item multiplied by volume is the hours at stake, and hours multiplied by loaded cost is the money.
Step 3: Design the workflow with AI in the middle, humans at the edges
The pattern that works, almost without variation:
- A human or a simple rule controls what enters the pipeline.
- The AI step does the judgement work: classify, extract, summarise, draft.
- Validation checks the AI output against structured rules.
- Confident, valid output proceeds; everything else routes to a human review queue.
- A human approves anything that leaves the business or moves money — at first, everything; later, a sample.
Humans at the edges, AI in the middle. The edges are where accountability lives: what goes in, and what goes out. The middle is where the volume lives, which is where the hours are saved.
Concretely, the plumbing for most first projects is the same toolset we use everywhere else: the inbox or intake form watched by Make.com or n8n, a call to a language model API as one step in the scenario, results written to Airtable, and a review queue surfaced in an Airtable view or a simple Softr interface. Nothing exotic. The novelty is one step in the middle of a pipeline you already understand.
Step 4: Write the instructions and test against 50 real examples
The prompt — the instructions you give the model — is the specification of your AI step, and it deserves the same rigour as any other specification. Three practices matter.
Be concrete about the task and the output. "Classify this email" is a bad instruction. "Classify the email below into exactly one of: billing, new-enquiry, support, spam, other. Use billing when the message mentions an invoice, payment, quote, or account charge, even if it also asks a question" is a good one. Every category needs a definition and a boundary, because the boundary cases are where accuracy is decided.
Give it examples. Include three to six short real examples in the instructions — one per important category, plus one deliberate edge case. This single change typically moves accuracy more than any amount of clever wording.
Test against fifty real examples before anyone trusts it. Pull fifty actual items from the last month, have a human label the correct answers, and run the AI step against all fifty. Count the errors. Then fix the instructions — tighten a definition, add an example for the case it got wrong — and run the fifty again. Two or three rounds of this and you will know the step's real accuracy on your data, not on a vendor's marketing data. If accuracy plateaus below about 85 percent after a few rounds, the task is probably harder than it looked: narrow the categories, split the task into two steps, or pick a different first candidate.
Fifty is not an arbitrary number. It is small enough to label in an afternoon and large enough that 90 percent accuracy means something — you have seen roughly five failures and can say what kind they are.
Step 5: Build the guardrails
Guardrails are what make an imperfect model safe to run. Four of them do most of the work.
Structured output. Never let the AI step return free prose for a machine to interpret. Ask for a fixed shape and validate that you got it. For a triage step, something like:
category: one of billing, new-enquiry, support, spam, other
urgency: one of high, normal, low
summary: one sentence
draft_reply: text, or empty if category is spam
confidence: high or low, by the rules below
If the response does not parse into that shape — wrong field, a category not on the list — the item goes straight to the review queue. Malformed output is not an error to retry silently; it is information that the input was unusual.
Deterministic validation. Check everything a rule can check before a human has to. An extracted date must be a real date; an extracted total must be a number; a category must be on the list; a draft reply must not contain a placeholder. Rules are cheap and never hallucinate — push every check you can express as a rule into this layer.
Confidence thresholds. Ask the model to flag its own uncertainty, and give it concrete rules for doing so — "mark confidence low if the email fits two categories, mentions no identifiable topic, or is under ten words." Low-confidence items route to review regardless of their answer. Self-reported confidence is imperfect, but combined with validation it catches a large share of the wrong answers.
A review queue with teeth. Exceptions must land somewhere a specific person looks daily, showing the original input beside the AI output, with a one-click way to correct and proceed. Corrections get logged. The log is how you find the systematic failures — the category boundary everyone argues about, the supplier format that always breaks — and fix the instructions instead of fixing items one by one.
Step 6: Pilot the rollout in two phases
Do not switch the manual process off on day one. Run in parallel.
Phase one: one person reviews everything. For the first two to four weeks, every AI output is reviewed by one designated person before it has any effect — the triage label is checked before routing, the draft is read before sending. Yes, this means the pilot saves little time. That is the price of finding out what the system does wrong while the cost of wrong is zero. Keep a tally: total items, items corrected, and the kind of correction. Two weeks of clean tallies — correction rate at or below your human baseline error rate — is the signal to move on.
Phase two: sampling. The AI output now acts by default — emails route themselves, drafts send for routine categories — and the reviewer checks a random sample, starting at one in five and tapering toward one in twenty as the tallies stay clean. Anything that fails validation or confidence rules still goes to the queue automatically; sampling exists to catch the errors the guardrails did not.
The pilot ends when the sampled error rate has sat at or below the human baseline for a month, and the team has stopped checking the queue nervously and started checking it as routine. That behavioural change is the real go-live.
Step 7: Measure the result honestly
Go back to the baseline from step 2 and measure the same three numbers.
Time per item now means time per reviewed item plus queue time, not zero — the work shrank, it did not vanish. Volume may have grown; measure what the pipeline actually processed. Error rate comes from your sampling tallies, compared against the human baseline you wrote down, not against zero.
Honest results usually look like this: 70 to 85 percent of items flowing through untouched, the rest in the review queue at a fraction of the original handling time, and an error rate at or modestly better than the manual baseline. A typical invoice of the outcome at a client: a task that took six minutes per item at 40 items a day becomes ninety seconds per item on the 20 percent that need review plus a twenty-minute daily queue pass — roughly twenty hours a week down to under three. That is the honest win. Anyone promising you 100 percent straight-through processing on a first project is selling a demo.
Report the numbers to the team, including the failures found and fixed. The next AI project starts the moment people trust the first one, and trust is built by showing the measurement, not by declaring success.
Step 8: Know when to expand and when to stop
Expand when three things are true: the sampled error rate has been at or below baseline for a month or more, the review queue is a routine rather than a burden, and the team is asking for the next workflow. Adjacent expansions are the cheapest — a new category on the triage step, a second document type through the same extraction pipeline — because the guardrails, the queue, and the review habit all transfer.
Stop — or at least pause — when the remaining manual share is the genuinely hard cases. If the 20 percent in the queue are items that take a senior person ten minutes each of real judgement, automating them is a different, riskier project, and the ROI case is weak precisely because they are rare. The right end state for many workflows is exactly that: machines handling the routine, experienced people spending their time on the exceptions. Resist the urge to chase the last 10 percent of volume; it is where the model is least reliable and the business risk is highest.
Step 9: Cost expectations at SMB volumes
For a first workflow at typical SMB volumes — say 1,000 to 5,000 items a month — the running costs are modest and predictable. Model API costs for a triage or extraction step of a page of text run in the low cents per item at current pricing; at those volumes, that is tens of dollars a month, not hundreds. The automation platform — a Make.com or n8n plan sized for the volume — adds a comparable amount. The real costs are elsewhere: the build itself, the two to four weeks of a reviewer's time during the pilot, and an hour or so a month of maintenance thereafter. As a planning number for a first project of this kind, expect the total first-year cost to land in the low thousands, against a saving that, at four hours a week of loaded staff time, pays that back within a quarter or two. If the maths does not work at those rates for your candidate workflow, the volume is too low — pick a busier process.
A worked example: inbound request triage and drafting
Here is the playbook applied end to end, condensed from a real engagement with a fifteen-person services firm.
The candidate. Their shared inbox took about 60 emails a day: new enquiries, support requests from existing clients, billing questions, and noise. Two people shared the triage, spending roughly ninety minutes a day between them reading, forwarding, and writing first replies. High volume, text-heavy, clear right answers, low risk — a textbook first candidate.
The baseline. Two weeks of measurement: 4.5 minutes average per email including the reply drafting, about 11 hours a week across the two staff, and a misroute rate of about 6 percent — emails forwarded to the wrong person and bounced back, usually billing sent to the support lead.
The design. Make.com watches the inbox. Each email goes to the model with instructions defining the five categories, the urgency rules, and the confidence rule — low confidence if the email fits two categories or is too short to tell. Output is structured: category, urgency, one-sentence summary, a draft reply for new-enquiry and support categories, empty otherwise. Deterministic checks follow: category on the list, all fields present. Anything failing validation or flagged low-confidence goes to an Airtable review queue; everything else routes itself — label applied, forwarded to the right person's queue, draft reply attached ready to send — and logs to Airtable.
The testing. Fifty emails from the prior month, labelled by the office manager. First run: 82 percent correct, with nearly all errors on the billing-versus-support boundary — clients asking "why was I charged" read as both. The fix was one extra definition sentence and two boundary examples in the instructions. Second run: 94 percent. Good enough to pilot.
The pilot. Three weeks of the office manager reviewing every routed email and every draft before anything went out. Correction rate settled at about 5 percent, below the 6 percent human baseline — and the corrections were faster than doing the triage by hand. Then sampling: drafts for new enquiries and billing questions stayed human-approved (they touch money and first impressions), while routing and support drafts went automatic at one-in-five sampling, tapering to one-in-twenty.
The result, measured honestly. Eleven hours a week became roughly three: the daily queue pass plus review of the draft categories that stayed human-approved. Routing accuracy landed slightly better than the manual baseline. Total running cost: under a hundred dollars a month. The two staff got their mornings back, and the firm's second AI project — extracting fields from signed engagement letters — started the following quarter with the review queue and guardrail pattern reused almost unchanged.
Notice what made this work: not a clever prompt, but the baseline, the fifty examples, the guardrails, the phased pilot, and the willingness to keep humans on the categories where being wrong mattered. That is the whole playbook.
Where to start
Pick one workflow this week and run step 2 on it — just the measurement. Time thirty items, count the weekly volume, check a sample for errors. That single afternoon tells you whether you have a good first candidate, sizes the prize, and gives you the yardstick every later decision will be measured against. If the numbers say the task is worth automating, the rest of this playbook is the path.
If you would like help choosing the candidate or pressure-testing the design before you build, book a 30-minute audit — we will look at the workflow with you, tell you plainly whether an AI step is the right tool for it, and sketch what a safe first pilot would look like in your operation.