Automate the steps, not the job.

Start with a workflow, not a tool

Most disappointing AI projects in small teams begin the same way: somebody evaluates a tool, likes it, and then goes looking for something to point it at. The order is backwards, and the cost is not the license — it is the six weeks spent making a general capability fit a process nobody ever wrote down.

The alternative is dull and it works. Pick one workflow that runs often enough to matter, has a beginning and an end you can name, and currently annoys someone. Frequency matters more than duration. A fifteen-minute task done forty times a week is a better first target than a two-day task done quarterly, because the second will not produce enough repetitions to learn anything from before the quarter is over.

Map it before you change it

Write the workflow out as steps, one line each, in the order they happen. For every step record four things: who does it, what they need in hand before they can start, how long it takes, and how you would know it had been done wrong. The fourth column is the one teams skip, and it is the one that decides everything else.

• A step with an obvious failure mode you can check cheaply is a candidate to automate.
• A step whose failure surfaces weeks later, inside a customer relationship, is not.
• A step that takes an hour because the information is scattered is an information problem wearing a labor problem’s clothes.
• A step everybody does slightly differently is not yet a process, and automating it standardizes on whichever version happened to get described.

This exercise often ends the project early, in the good way. A third of the workflows worth mapping turn out to contain a step that exists only because two systems do not talk to each other. The fix is an integration. It costs less, it needs no supervision, and nobody has to trust it.

What the machine is reliably good at

One pattern holds across the steps worth handing over: high volume, tolerant of a second pass, and judged against something checkable.

• Turning unstructured input into structured fields — an email, a form, a transcript, a scanned document — where a person confirms the result instead of typing it.
• Drafting the first version of something with a house format: a summary, a reply, a brief, a set of release notes.
• Retrieval and assembly: finding the five relevant items among four thousand and putting them in one place.
• Classification and routing, where the categories are stable and a wrong answer is visible straight away.
• Checking work against a list — whether this document included the four things it always has to include.

Notice what these have in common. Each produces something a person can inspect in less time than it would have taken to make. That ratio is the entire economics of the thing: if verifying an output costs as much as producing it, the automation has moved the work rather than removed it, and the team will quietly stop using it within a month.

What still needs a person

• Anything where the cost of being confidently wrong is carried by a customer and discovered late.
• Decisions that trade one stakeholder’s interest against another’s — pricing exceptions, prioritization, whose escalation goes first.
• Work whose real output is a relationship, where the document is a by-product of it.
• Judgments that depend on context living in somebody’s head rather than in any system — until that context has been written down.
• Anything a regulator, an auditor or a contract requires a named person to have decided.

The fourth is worth dwelling on, because it is usually temporary. A judgment that cannot be automated today because its inputs are undocumented becomes a candidate once they are documented — and writing them down improves the human version immediately, before any system is built. That is the most dependable return available in this work, and it looks nothing like buying a tool.

The seam between them

Almost every workflow worth changing ends up a mixture, and the design work is the handover rather than either half. Three things make it hold.

Confidence has to be explicit. A system that returns an answer together with a measure of how sure it is can route the uncertain cases to a person and let the rest through. One that returns only an answer forces the team to check all of it, which is the same amount of work plus a subscription.

Review has to be cheaper than doing, and has to stay that way as volume grows. Review that means reading the whole input again is not review. Design the output so a person checks the three fields that are usually wrong rather than the thirty that are usually right, and make the three obvious on the page.

Escalation needs a name on it. The most common failure is not a wrong output; it is a wrong output nobody owned, sitting in a queue that was nobody’s queue, because the workflow was mapped up to the point of automation and no further.

How to tell whether it worked

Measure the same thing before and after, and pick something the team already feels. Time per item is the obvious one. Rework rate — how often the output has to be redone — is the better one, because an automation that halves the time and triples the rework has made things worse in a way a stopwatch will flatter. Add queue age if the work arrives in batches, since the complaint is usually latency rather than effort.

Set that baseline before anything changes. It takes an afternoon, and it is not recoverable afterwards: once a workflow has changed, nobody can reconstruct what it used to cost, and every later claim about the improvement becomes an argument instead of a measurement.