Processes: what to automate and what to leave to people

At a company I know, approving an ordinary purchase order under ten thousand crowns took nine days on average. When we asked everyone involved where the problem was, they all gave the same answer: "It takes me five minutes." And they were right. The total of actual work was a bit over half an hour. The rest — eight and a half days — was waiting. The order sat in someone else's inbox, someone else's head, in a queue behind twenty more important things.

This is the most typical company story there is. Nobody's working slowly, and yet everything takes forever. Nobody complains about their own part, and yet the whole thing grinds. The explanation is simple and uncomfortable: a company doesn't lose time to work, it loses time to the gaps between work. And because the gaps have no owner, nobody sees them and nobody fixes them.

This chapter is about processes — about how work actually flows through a company, how to sketch that path, and where to look for losses in it. Automation comes only after that, because automation isn't a fix for chaos, it's a chaos amplifier. The previous chapter in this series was about knowledge that doesn't walk out the door with an employee — that is, what stays in a company. This one is about the path work travels between people; the broader view of collaboration is in the chapter Team productivity.

A process is the path work travels through a company

The word "process" has an unfortunate connotation. It smells of policies, ISO standards, and binders nobody's ever opened. In reality, a process is something much more down-to-earth: a recurring path a given type of work follows from a trigger to a result.

A new order. Onboarding a new colleague. A complaint. Monthly invoicing. Drafting a proposal. Publishing an article. Approving vacation time. Each of these has happened many times at a company and will happen again. Each time it passes through roughly the same hands, roughly in the same order, with roughly the same outputs. That "roughly" is the core of the problem — the process exists, but nobody wrote it down, so it varies slightly each time depending on who's running it and how much of a hurry they're in.

A key distinction: a process is not the same as a project. A project is one-off, with a start, an end, and its own plan. A process is recurring, has no end, and its value is that it doesn't need to be reinvented every time. Most of a company's time doesn't go into projects — it goes into processes. That's exactly why it's worth knowing them.

A second distinction, even more important: a process is not the org chart. An org chart shows who reports to whom. A process shows where work travels. And these two maps almost never overlap. Work moves across departments, jumps over hierarchy, comes back, waits on someone who doesn't appear on any chart. The most expensive spots in a company are usually exactly where work crosses from one department to another — because at that spot, neither side owns it.

How to map a process (and why most companies never have)

Mapping a process sounds like a three-month project with a consultant and a color-coded diagram on the wall. It isn't. A basic version can be done in an hour, on paper. You need to answer four questions for each step.

The last question is the reason to bother mapping at all. Most people only estimate processing time, because that's what's visible. Wait time is invisible — it goes on nobody's timesheet, nobody gets called out for it, and yet it makes up most of the total duration.

Practical approach: don't draw the ideal process. Draw the real one, workarounds included. If it turns out three out of five people send materials outside the official system, into a private chat, that belongs on the map. Working around the rules isn't a failure of the people — it's information about where the official path doesn't work. A map showing how things are supposed to work is useless. A map showing how they actually work is gold.

Who draws the map? Not a manager alone in their office. The best result comes from a half-hour conversation with the people who actually do the process, with one simple question: "Walk me through the last case that came through your hands, step by step." A concrete case always reveals more than a general description. In general terms, people describe how it's supposed to work. With a concrete case, they remember they had to chase it three times and once had to redo the whole thing.

Why most companies have never done this

Three reasons, and all of them are understandable.

First, everyone knows their own piece and nobody knows the whole. Accounting knows exactly what it does with an invoice. Sales knows what it does with an order. Neither has seen the whole path from inquiry to payment. The whole is only visible from a distance, and nobody takes that distance, because there's always something more pressing to do.

Second, mapping has no immediate payback. An hour spent drawing a diagram earns nothing, and in the moment nothing feels more urgent than the fires already burning. Process work is a classic resident of the "important, not urgent" quadrant — and that loses to everything urgent until someone deliberately blocks time for it.

Third, the map reveals uncomfortable things. It shows that a certain step is unnecessary and someone's been doing it for five years. It shows an approval loop that serves one person's peace of mind more than it serves the company. It shows two departments running the same check. Those are findings that trigger defensiveness, and plenty of companies would rather avoid them.

A tip: map processes at the moment something's bothering you. When someone complains about the same delay three times in a month, you have both the mandate and the reason. Trying to map everything at once is a sure way for nobody to ever read the diagrams.

Bottlenecks: waiting is almost always a bigger loss than slow processing

When a company looks to speed things up, it instinctively looks at the slowest step and tries to speed that up. That's usually the wrong spot. The slowest step tends to be slow because real work is happening there — and you want that done properly.

The real loss is elsewhere: in the places where work sits and nothing happens to it. In a typical approval loop, the ratio often looks like this.

Total work: under two hours. Total waiting: nearly four days. If you cut every processing step in half, you'd save under an hour out of a total of a hundred. If you cut one wait in half, you'd save a day.

The bottleneck in a process isn't the slowest person. It's the spot where work piles up. You spot it by the queue: work bunches up in front of a bottleneck, and it's calm right after it. When you're hunting for bottlenecks, don't look at who's busiest — look at where the piles are biggest.

Typical causes of waiting are surprisingly mundane and almost all fixable:

• A single approver with no backup. They go on vacation and the process stalls. The fix isn't more approvers, but less approval — for small amounts, follow-up checks work fine instead of prior approval.
• Work gets sent, but nobody knows it. An email lands in an inbox with forty other unread messages. A queue with no visibility is a queue nobody looks at.
• An incomplete request. A step can't be done, because a piece of data is missing. A question follows, a day waiting for the answer, another day for it to come back. One missing field in a form costs two days.

That last point deserves emphasis. The most expensive mistake in a process is the one that shows up late. When a request is incomplete right at the start and it only gets noticed at the end, the whole path repeats. That's why it's worth investing disproportionate attention in the first step — a form, a template, a checklist that makes sure the work enters the process complete. The tool here is banal; the tip A checklist for anything you do more than once shows how to build one.

Simplify first, only then automate

This is the one rule in the whole chapter worth remembering even if you forget everything else: automated nonsense is just faster nonsense.

Automation locks a process into the shape it had when you automated it. If you automate an approval loop with four unnecessary steps, you'll have four unnecessary steps forever — and they'll be harder to remove, because someone's already invested work into them and nobody wants to switch off something that "works." A pointless thing done by a human can be cancelled with a decision. A pointless thing wired into a system outlives three managers.

So before you reach for a tool, run the process through five questions, in this order:

1. Can this step be eliminated? Ask concretely: who looks at its output, and what would happen if it disappeared? If nobody can answer, you have your answer.
2. Can it be merged with another? Two people doing the same check twice is one check too many.
3. Can it be moved earlier? A completeness check at the start is ten times cheaper than one at the end.
4. Can it be done in parallel? Plenty of steps run in sequence out of habit, not necessity.
5. Can the decision be pushed down a level? Approving small amounts costs more managerial time than it protects in money.

Only what survives this process is worth automating. And usually you'll find that after simplifying, half the automation ideas have already disappeared, because a simplified process can be handled by a person in no time.

Three levels of automation: template, rule, agent

The word automation today, in most companies, means almost exclusively "something with AI," which is misleading. Automation has three levels, and the cheapest one is also the most underrated.

Template. A pre-built shape a person fills in. A form instead of a free-form email. A ready-made proposal structure. A checklist for onboarding a new colleague. A template doesn't remove a single human step — but it removes thinking about the form, cuts down on errors, and above all ensures work enters the next step complete. The ratio of benefit to effort is the best of all three levels, and most companies skip templates because they don't sound modern enough.

Rule. Deterministic "if A happens, do B." An email with a certain subject arrives, a task gets created. An invoice gets paid, the client gets a confirmation. A deadline passes, a reminder goes out. Rules are predictable, cheap to run, and easy to tune. Their limit is clear: they only work where the input is structured and the decision is unambiguous. The moment you start adding exceptions to a rule, you're approaching the point where it's cheaper to leave it to a person.

Agent. A step where a model assesses, drafts, or proposes something — summarizes a long thread, categorizes a request, prepares a draft reply, pulls data out of a document. An agent handles what a rule never will: unstructured input and a decision that can't be enumerated. In exchange, it pays in unpredictability — it may not answer the same input the same way twice, and it occasionally gets things wrong with total confidence.

The practical order matches the order of cost: try a template, then a rule, then only an agent. The best company automations are usually hybrids — a rule detects an event and kicks off a chain, an agent prepares a draft, a person approves it with one click. The tip Your first AI automation without coding walks through exactly this shape, and the broader framework for rollout, including data and measurement, is in the guide AI at the company. A more general look at automating personal work is in the chapter AI and automation.

Where the line for human oversight sits

There's a simple question that decides whether an automation's output can go out without human approval: how much does it cost to fix if it's wrong?

When the fix is cheap and fast — a task got miscategorized and gets moved, a wrong tag gets changed — the output can go straight out. When the fix is expensive, slow, or impossible, a human belongs between the step and the world. That's the entire principle behind "AI proposes, the human approves," and it rests on cold economics, not caution for its own sake.

Four areas where the line should almost always sit:

Money. Outgoing payments, bank detail changes, price settings, discounts, refunds. A wrong outgoing transfer doesn't reverse with one click. Automation can prepare everything up to the button here — matching, checking, flagging anomalies — but sending stays human.

Legal matters and obligations. Anything that binds the company: a contract, an order above a limit, a deadline promised to a customer, a reply to a complaint with a legal dimension, a filing with an authority. A model can write the text; the person who signed off on it carries the responsibility.

People. Anything about employees — evaluation, hiring, pay, termination, staffing a role. It's not just about the risk of error, it's about legitimacy. A decision about a person that no human actually thought through loses all its weight the moment you try to explain it. And watch the data: personal and sensitive information belongs exclusively in a paid company account with contractually secured data protection, never in a general consumer interface.

External communication. Everything that goes out under the company's name and can't be taken back: a reply to a customer, a social media post, a press release, a proposal. An internal meeting summary can be generated automatically. An email to a client gets read by a person first.

Inside these boundaries, there's a wide-open space: preparing materials, sorting, summarizing, drafting, searching documents, checking completeness, flagging anomalies. All of that saves hours and none of it can cause harm on its own.

Two operational details that get forgotten. First, approval has to be faster than the work itself, or people will learn to click through blindly and the check becomes theater. When approving means one click on a well-prepared draft, it works. When a person has to open three systems to approve something, they stop reading. Second, every automation needs a kill switch that at least two people know about. An automation only its author can stop is a risk waiting for a vacation.

Measuring a process and the hidden cost of upkeep

A process you don't measure doesn't improve — people just talk about it. Measuring doesn't have to be complicated, though. Three numbers are enough, and all three can be collected by hand.

Measure lead time from the moment the trigger occurred, not from when someone picked it up. The gap between "the invoice arrived" and "accounting opened it" is exactly the loss you're looking for. The ratio of work to total time is the fastest diagnostic there is: the lower it is, the clearer it is that the fix isn't pushing people harder, it's fixing the queues. And the number of returns tells you whether the process starts with a complete request.

Measure before the change, not just after. Without a baseline number, you'll never know whether automation actually helped or just moved the work elsewhere. Two weeks of manual logging into a spreadsheet is enough.

Upkeep as a hidden cost

Automations aren't furniture you buy once and it just sits there. They're small employees who need supervision. A system they're connected to changes its interface. A model gets updated and starts answering differently. An invoice template changes and the parsing stops matching. The person whose account powered the whole chain leaves. The company switches to a different tool and nobody remembers three automations were hanging off the old one.

The worst kind of failure isn't the loud one, where everything stops. It's the quiet one, where the automation keeps running but does the wrong thing — forwards to an empty folder, assigns to a colleague who's left, checks against an outdated price list. That gets discovered a month later, and does quiet damage in the meantime.

The minimum that holds this together is four things. Every automation has a named owner — not a department, a person. There's one list of all running automations describing what they do and what they depend on. Critical automations report that they ran, not just that they crashed — silence must never be mistaken for success. And once a quarter, someone goes through the list and switches off what's not being used.

Plan for upkeep to consume roughly a fifth of the time you invested in building it, every year. When an automation saves you twenty minutes a month and its upkeep eats two hours a year, that's a losing deal — and surprisingly many like it get built at companies, because building is fun and upkeep isn't. The best automation, therefore, is the one you didn't have to build, because you cancelled the step instead.

Key takeaways

• A process is a recurring path work travels through a company, not a policy in a binder. The most expensive spots are where work crosses between departments and has no owner.
• Map the real process, not the ideal one. For every step: what happens, who owns it, what goes in and out, how long the wait is. A concrete case reveals more than a general description.
• Look for queues, not slow people. Waiting is usually a much bigger loss than processing time, and it never shows up on anyone's timesheet.
• Simplify first, only then automate. Eliminate, merge, move earlier, do in parallel, lower the approval threshold — and only automate what's left.
• Three levels: template, rule, agent. Try them in this order. The best chains are hybrids ending in one-click human approval.
• The line for human oversight holds where a mistake is expensive: money, legal matters and obligations, decisions about people, outbound communication. Sensitive data only in a paid account with contractual protection.
• Measure lead time, the ratio of work to total time, and the number of returns — and measure them before the change, not just after.
• Plan for upkeep. Every automation needs an owner, a spot on the list, a signal that it ran, and a quarterly review. The cheapest one is the one you didn't have to build.