AI and Automation for Lean Teams: Where the Real Wins Are

Most of the AI projects we get asked about would be better served by a well-written spreadsheet macro, a scheduled script, or an hour spent removing a step from a workflow that has grown three of them.

This is not a case against AI. It is a case for spending your automation budget on the parts of the business where it will actually move something.

Ask the boring questions first

Before you ask what a language model could do, ask three duller ones.

How often does this task actually happen? A process that runs eleven times a year does not repay a two-month automation build, no matter how satisfying the final demo is. The ceiling on the value is the time you save, and eleven times a year is not much time.

Is the work the same each time? If a person doing it correctly makes the same six decisions in the same order, that is not an AI problem — it is a workflow problem, and a form with a few rules will beat a language model on cost, speed, and predictability.

What is the cost of a wrong answer? If a wrong output is caught in the next step by a human who is looking anyway, you can tolerate the model being wrong occasionally. If a wrong output goes straight to a customer, a bank, or a regulator, you cannot, and the cost of guardrails will dominate the project.

Answer those three honestly and half the ideas on the whiteboard fall off.

Where language models actually earn their keep

Three families of task are where we see LLMs genuinely pay for themselves in small teams.

Drafting. First versions of things a person will then edit. Product descriptions, follow-up emails, meeting summaries from a transcript, a plausible reply to a support ticket. The model does the blank-page work; a human does the last twenty percent that matters. This is the least glamorous use and the most reliable one.

Extraction. Pulling structured fields out of unstructured text. Names and amounts off an invoice photo, a shipping address out of a WhatsApp message, the intent behind a customer enquiry. Modern models are good at this and the failure mode — occasionally miscoding a field — is one you can design around with a review queue.

Classification. Sorting things into buckets you have defined. Is this email a complaint, a question, or a compliment? Is this product listing beauty or wellness? Boring, valuable, and the sort of work that used to require someone to sit and click for two hours a day.

Notice what these three have in common. The output is checkable in seconds, the cost of a wrong one is small, and the volume is high enough that even a modest time saving compounds.

Where they quietly fail

The failures are less obvious because the model still produces something confident-looking.

Precise calculation. Language models are not calculators. Ask one to reconcile a set of invoices to the rupiah and it will produce a number that looks right and is wrong in ways that are hard to spot. If arithmetic must be exact, do the arithmetic in code and let the model handle the words around it.

Novel judgement. Anything where the right answer depends on context the model does not have — your relationship with this supplier, why this customer is a special case, what your CEO said in a meeting last week. The model will guess, plausibly, and the guess will be wrong often enough to matter.

Anything with a long tail of edge cases you cannot list. A five-person e-commerce team asking a model to "handle returns" is really asking it to handle the thirty percent of returns that do not follow the rules, and those are the ones where a bad answer costs you a customer.

Multi-step workflows presented as an "agent". The current generation of agent frameworks compound errors: a five-step chain where each step is ninety percent reliable is a chain that works about sixty percent of the time. That is fine for exploration and terrible for a process that runs a thousand times a week.

When a spreadsheet macro wins

The unfashionable answer is often the right one.

If the input is already structured, the rules are stable, and you can write them down in a paragraph — a macro, a scheduled query, or a small script will be faster, cheaper, more reliable, and easier for the next person to modify. It will also still work in three years without a model upgrade breaking it.

We have shipped more real time savings in small businesses by removing a duplicated data-entry step than by any language model deployment. It is not a marketable answer, and it is the true one.

A framework you can actually use

When a candidate task comes up, walk it through four questions in this order.

Is the work necessary at all? The best automation is deletion. Half the reports being generated in most companies are opened by nobody.

Can a rule handle it? If the logic fits on an index card, use code. You will pay once and never again.

Is the input unstructured and the tolerance for error moderate? This is the LLM sweet spot. Drafting, extraction, classification, with a human in the loop for anything that matters.

Does it need judgement, arithmetic, or a chain of dependent decisions? Keep the human in the seat and use the model to do the parts around them — summarising the case, drafting the reply, pulling the numbers to look at.

Run every idea through those four before scoping a build.

The cost nobody quotes for

Automations, especially model-based ones, are not built once. They drift.

The upstream form changes a field name and the extractor breaks. The model provider ships a new version and outputs shift subtly. The edge case you did not think of shows up in month four. Someone has to notice, diagnose, and fix each of these, and if nobody owns the automation it will quietly rot until people are doing the work by hand again and pretending the system is still running.

Budget for maintenance from the start, or automate less than you could, so the surface area stays small enough for one person to look after. Ambition is cheap in the demo and expensive on Tuesday morning six months later.

If you are staring at a list of processes and trying to decide which are worth automating and which are not, a short conversation before scoping is usually the cheapest hour on the project.