AI automation delivers on a narrow set of tasks and disappoints everywhere else. What actually works in 2026 for a small business or an online store: which processes to hand to a model, which to keep as plain rules, and how to measure the gain.
I'm Tommy Bordas, a full-stack developer in Nantes (10+ years, freelance via Sumotori). I build automations for small businesses and e-commerce merchants, with and without AI. For the past eighteen months, half the enquiries I get open with "we'd like to put AI somewhere". I usually answer with two questions of my own: which task eats the most time every week, and what kind of decision does it actually require?
Two different kinds of automation, constantly confused
Classic automation runs deterministic rules. If the order flips to "paid", then create the invoice, send it to the customer, push it to accounting. The result is predictable and testable like any other piece of code: you verify it once, then forget about it.
AI automation comes in when judgement on something ambiguous is required. Is this email a quote request, a complaint, or cold outreach? Where is the order number in this supplier PDF that changes layout every quarter? The result is probabilistic: often very good, sometimes wrong, never guaranteed.
| Classic automation | AI automation | |
|---|---|---|
| Nature of the decision | Explicit rule | Judgement on the ambiguous |
| Output | Deterministic, reproducible | Probabilistic, variable |
| Cost per run | Near zero | Per call, scales with volume |
| Debugging | Read the rule | Test, adjust the prompt, test again |
| Validation | Standard test cases | Example set and an acceptable error rate |
| Best for | Flows, calculations, syncs | Sorting, extraction, classification, summaries, drafts |
Both mistakes are expensive. Wiring a language model where three conditions would have done means paying for API calls and making something undebuggable that used to work perfectly well. I have also seen the reverse, weeks spent stacking regular expressions to read supplier invoices that change format every quarter, when a model handled it correctly on the first try.
A good workflow almost always contains both, with the model handling the fuzzy part and rules handling everything else.
The good candidates, concretely
Here are the cases where I have seen a real, measurable gain at companies under fifty people.
| Process | What the model does | Why it holds up |
|---|---|---|
| Sorting inbound email | Classifies into quote, support, billing, cold outreach, and extracts the customer name | Cheap error, instant correction, daily volume |
| Document extraction | Reads an invoice, purchase order or supplier PDF and returns structured fields | Every field is checkable against the source |
| First-line support replies | Drafts an answer from the internal knowledge base | A human validates before sending, the gain is on typing |
| E-commerce product copy | Writes a first draft from supplier specs | Output is reviewed before publishing, never shipped blind |
| Monitoring and summaries | Condenses a list of articles or tickets into key points | The reader keeps the links to the source |
What these cases have in common has nothing to do with model sophistication: in each of them the error is visible and cheap to undo. A misfiled email is refiled in two seconds, a rough product description is fixed before it goes live.
And the bad candidates, the ones that come back to haunt me when someone has forced the issue:
- Binding decisions without review. Sending a priced quote, granting a refund, approving a payment. The model can prepare them, the sign-off stays human.
- Exact calculations. A language model is not a calculator. Totals, VAT, discounts, stock levels: those are rules, code, a database.
- Regulated data without a framework. Health, HR, banking data. Nothing stops you touching it, but the legal framework goes in before the workflow, not after.
- Rare processes. Three occurrences a year never justify the design and maintenance cost.
The method I apply
Map before you tool up. One hour of conversation and a table: which task, who does it, how many times a week, how long, and what kind of decision it requires. The table picks the candidate on its own, and very often reveals two or three obvious classic automations that need no AI at all.
Pick a single quick win. Repetitive, measurable, low stakes. Sorting contact-form email is an ideal starting point: it runs every day, mistakes are harmless, and the gain is measured in minutes per day from the first week.
Keep a human in the loop at first. The model output lands in a Slack channel or a table, with a button to accept or correct, and nobody applies it unreviewed. This mode prevents the silent disaster, and it produces a set of corrections that becomes your quality measure. After two or three hundred runs, you know whether the error rate allows full automation on the simple cases.
Measure two things only. Time saved per week, and error rate. Without a before and after, all you have is an impression, and impressions always favour the new toy.
Only then expand. Wait until a process has run cleanly for a month before launching a second one.
The tooling, without the jargon
My orchestrator is self-hosted n8n. It is an open-source automation tool that chains steps together, where the model call is just one step among others. An AI workflow almost always has the same shape:
Trigger (email received, webhook, file dropped, cron)
→ Preparation: clean, truncate, strip anything that shouldn't leave
→ Model call: system prompt + data + enforced output format
→ Validation: does the output match the expected schema?
→ Deterministic post-processing: business rules, write to database
→ Human validation (at first) or direct action (once proven)
→ Logging: input, output, cost, duration
The step that separates a demo from production is the enforced output format. Rather than a free-form answer, you require a JSON object whose every field is checkable. Anything that does not fit the schema goes to human review instead of being consumed downstream.
You are a triage assistant for an online store's customer service.
You receive the raw text of an inbound email.
Reply ONLY with a valid JSON object, no surrounding text:
{
"category": "quote" | "support" | "billing" | "outreach" | "other",
"urgency": "high" | "normal" | "low",
"order_number": string | null,
"summary": string (25 words maximum),
"confidence": number between 0 and 1
}
Rules:
- Never invent an order number. If it does not appear literally
in the text, return null.
- If you hesitate between two categories, pick the more cautious
one and drop "confidence" below 0.6.
- Do not draft any reply to the customer at this stage.
Then a deterministic rule does the safety work: confidence < 0.6 or urgency = high goes to the human queue, and the rest flows through the automatic path. It is the combination of the model's judgement and that hard-coded guardrail that makes the whole thing usable in production.
On the model side, Claude, GPT and Mistral all handle this kind of task perfectly well. The choice comes down to three practical criteria: cost per million tokens at your volume, server location if your data is sensitive, and how stable the structured output is. Test on your own examples rather than on general leaderboards.
A word on agents, since the term is everywhere. An agent is a model given tools and some latitude: it decides the sequence of calls itself. That is powerful, and considerably harder to bound. For a small business I reserve it for tightly scoped processes, with read-only or reversible tools. An explicit workflow stays more predictable, cheaper, and easier to repair at three in the morning.
I covered the n8n mechanics on the store side in Automating WooCommerce with n8n: webhook signatures, idempotency, error workflows. Those practices do not change when you add a model to the chain, they matter more: a non-deterministic step now sits in the middle of it.
The numbers that matter, and what they leave out
Adoption is massive, measurable financial impact is still rare, and that is about all we can say with confidence about 2026.
On adoption, Stanford HAI's 2026 AI Index records 88 % of organisations using AI in at least one function, with generative AI present in at least one function at 70 % of them. On agents, PwC's AI agent survey, run in April 2025 among 308 US executives, finds 79 % of organisations already adopting agents, of which 66 % report measurable value through productivity gains.
Now the counterweight. McKinsey's State of AI survey, published in August 2026 across 1,719 respondents, shows that only 37 % attribute any EBIT impact at all to their use of AI, and that 6 % of organisations clear the bar of 5 % of EBIT attributable to AI with an impact they describe as significant. Agent deployment, meanwhile, remains in the single digits across nearly every business function according to the AI Index.
The most solid gains are measured at the task level, not the company level. The AI Index collects studies placing gains around 14 to 15 % on customer support and 26 % on software development. Those are credible orders of magnitude, a long way from the "10x" claims that circulate on LinkedIn.
My own field reading matches those numbers. A well-built AI automation saves something like an hour a day on a specific task, which adds up to a half-time position over a year without transforming anything else about the company. As for spectacular ROI figures, they almost always come from people selling the tool.
The traps, in the order they will hit you
Hallucinations. A model always produces a plausible answer, including when it does not know. The fix sits in the architecture of the workflow rather than in the choice of model: constrained output format, fields checkable against the source, a confidence threshold, human review on anything binding. The AI Index counts 362 documented AI incidents in 2025, up from 233 in 2024.
Runaway API costs. The prototype costs three euros a month, production costs three hundred because someone pointed the workflow at the full history instead of new items only. Log the cost per run from day one, set a cap, and truncate your inputs.
GDPR and the AI Act. Sending customer data to a model hosted outside Europe is a processing operation like any other: it needs a legal basis, a defined purpose, a retention period, and an entry in your records. France's data protection authority publishes practical AI fact sheets that walk through the reasoning step by step. In practice there are two routes: minimise what you send (anonymise, transmit only what is needed) or host the model yourself.
On the European AI Act, application is staged. Prohibited practices and the AI literacy obligation have applied since 2 February 2025, governance rules and general-purpose model obligations since 2 August 2025, and the bulk of the regulation since 2 August 2026, including the duty to tell a person they are talking to a machine. Obligations on high-risk systems were pushed back by the AI Omnibus, in force since 27 July 2026, to 2 December 2027 for Annex III systems and 2 August 2028 for systems embedded in products. For email triage or product copy generation you are not in high-risk territory. Check your own case anyway rather than taking my word for it.
Maintenance debt. A workflow is code. APIs change, models get deprecated, supplier formats evolve. Version your workflows in Git, wire an alert on failures, and keep a reference set of ten to twenty examples that you replay before every model or prompt change.
Over-promising. The most expensive trap, because it destroys internal trust. Announce a replacement, deliver an assistant. Announce an assistant instead, and let the measurement do the talking.
Where to start
In practice I suggest starting with a single process, two weeks of work and a quantified success criterion agreed up front. You pick the repetitive task that annoys your team the most, we wire it up keeping human validation in place, and we measure the time spent and the correction rate before and after. After two weeks, either the number is there and we expand, or it is not and you have learned something for a trivial cost.
That is the engagement format I offer, because it is the one that proves the value on a single case before committing to the next.
Going further
On flow direction and source of truth, questions that surface the moment a model writes into several systems, see Two-way ERP and website synchronisation.
Have a repetitive process eating your weeks, and no idea whether it calls for a simple workflow or a model? Let's talk, the diagnosis takes an hour.