Operating processes: a clear guide with practical examples

There is a task in your business that only one person can do. When they are on holiday, it either waits or gets done badly. Nobody wrote it down because the person doing it does not experience it as a process: they experience it as their job.

That gap is what operating process work is for. Not diagrams. Not a documentation portal nobody opens. Just the ability to answer, for any recurring piece of work: what starts it, who owns it, what "done" means, and what happens when it goes wrong.

A process is four things, and only four

Most process documents fail because they describe activity instead of structure. A usable description of a process answers four questions and stops.

What triggers it. Not "monthly": what actual event puts this work in someone's queue. A customer signs. An invoice hits 30 days overdue. A shift ends. If you cannot name a trigger, you may be describing a habit rather than a process, and habits do not survive staff turnover.

Who owns the outcome. One name, not a department. The owner is the person you would ask if the output were wrong. Two owners means no owner. Nobody named means the work will be dropped the first week someone is busy.

What "finished" looks like. The acceptance condition, written so a second person could apply it without asking. "Invoice approved" is not a condition. "Approved by someone other than the person who raised it, with the PO number attached" is.

What happens when it fails. The exception path. This is the part almost everyone skips, and it is the part that gets used most.

Everything else (the step list, the screenshots, the tool names), is detail that sits underneath those four. Detail ages fast. The four stay stable for years.

Write the exceptions first

The standard way to document a process is to write the happy path and then, if there is time, note some edge cases. Reverse it.

Sit with the person who does the work and ask one question: "In the last month, how many of these went exactly the way they are supposed to?" The answer is rarely most of them. Then ask what happened to the rest.

You will get a list like: the customer sent the wrong file format, the approver was away, the system was down so we did it manually, the amount was over the limit so we had to ask, this one is a special case because of who the client is. That list is the real process. The happy path is the easy half.

Document the exceptions with the same four fields: trigger, owner, done, escalation. Then the happy path takes ten minutes to add, because it is what is left over.

This also tells you something useful. If the exception rate is high and stable, the process definition is wrong, not the people. A rule that gets overridden a third of the time is not a rule; it is a suggestion with paperwork attached.

Count the handoffs

Every point where work moves from one person to another is a place it can stop moving. Handoffs are where queues form, where context gets lost, and where nobody feels responsible for the delay because everyone is waiting for someone else.

Take a process you think is slow and count them. Not the steps: the handoffs. A five-step process with one handoff usually runs fine. A five-step process with four handoffs will have most of its elapsed time sitting in gaps between people, not in the work itself.

Two things to check at each handoff:

Does the receiver know it arrived? If the mechanism is "they'll see it in the shared folder," they will not. Something has to push, not wait to be pulled.

Does the receiver have everything they need? Rework caused by an incomplete handoff is invisible in most reporting, because it looks like the second person being slow.

Removing a handoff is usually a bigger improvement than speeding up a step. Combining two roles, giving one person authority to approve their own work up to a threshold, or letting the requester supply the missing field at the start: these change the shape of the process. Buying a faster tool for one step does not.

Go and watch, because asking is not enough

If you ask someone to describe how they do their job, you get the version they believe. It is not dishonest; it is that the practiced parts have become invisible to them, and the parts they improvise get remembered as the standard method.

Watching a few real cases end to end costs a couple of hours and consistently produces things nobody would have told you.

What to pay attention to:

Where they stop and wait. For information, for approval, for a system, for another person. Waiting is invisible in any description of a process and is usually most of the elapsed time.

What they open that is not part of the official system. The personal spreadsheet, the note file, the folder of past examples, the messages they search for a reference. Every one of these is a gap in the designed process that someone has patched privately.

What they check twice. Repeated checking means they do not trust something: an input, a system, their own earlier step. That mistrust is usually well-founded and worth tracing.

The questions they ask other people. Each one is a piece of information that should have arrived with the work and did not.

What they do differently from the last person you watched. Where two competent people diverge on the same task, one of the ways is probably better, and the difference is free improvement.

Do this with the person's agreement and be clear it is about the work, not about them. If it feels like surveillance you will get the performed version, which is the same as the described version and equally useless.

What to automate, and what to leave alone

The temptation is to automate whatever is most annoying. The better filter is what will still be true in two years.

Automation is a good bet when the process is stable, when the inputs are structured, when the volume is high enough that the build pays back, and when a failure is visible. That last one is the most neglected. An automation that silently does the wrong thing is worse than a manual step, because manual errors are irregular and get noticed, while an automated error is consistent and gets trusted.

Be more cautious when the rules change frequently, when the inputs arrive as free text or as whatever the customer felt like sending, when the volume is low, or when the current process is exception-heavy. Automating an exception-heavy process usually means encoding today's exceptions into something rigid, and the eleventh case will not fit.

Two rules worth holding to. Fix the process before automating it, otherwise you have made a bad process faster and much harder to change. And know how the automation fails: what happens when the input is malformed, when the other system is down, when nobody is watching. If the answer is "it stops and someone notices," fine. If it is "it keeps going with a default value," you have built a defect generator.

Keep a list of what you have automated and who understands it. The most common operational surprise in a small organization is an automation nobody knew existed, built by someone who left.

Processes that cross a team boundary

Within a team, a process with a vague owner still mostly works, because people can see each other and fix things informally. Across a boundary, the same vagueness produces work that sits.

Two things are worth doing explicitly for any process spanning teams.

Name one owner for the whole thing, not one per team. Otherwise each team optimizes its own segment, and the gaps between segments, which is where the delay is, belong to nobody. The end-to-end owner does not need authority over both teams; they need permission to ask why something is sitting.

Measure the whole elapsed time, not each team's portion. Each team can hit its internal target while the customer waits a fortnight, because the waiting happens between the measured segments. This is one of the most common reasons a set of green dashboards coexists with an unhappy customer.

The difference between a process, a rule, and a decision

These get muddled, and the confusion produces documents that are useless for all three purposes.

A process is a sequence someone follows. It can be improved, shortened, automated.

A rule is a constraint on outcomes: a spending limit, a segregation of duties, a required approval. Rules exist because of risk, and they usually cost time on purpose. Treating a rule as process inefficiency and "streamlining" it away is how controls quietly disappear.

A decision is judgment that cannot be reduced to steps. Whether to take on a difficult client. Whether this defect is bad enough to hold the shipment. You can support a decision with criteria and information, but if you write it as a flowchart you will produce either a bad decision or a flowchart everyone ignores.

Before you document anything, sort it. Processes get step lists. Rules get a stated reason and an owner who can grant exceptions. Decisions get a briefing note: what to consider, who decides, what to record afterward.

When not to document

Documentation has a maintenance cost, and stale documentation is worse than none: it makes people confident about something that is no longer true.

Reasonable tests for whether a process is worth writing down:

Frequency. Something done twice a year by one experienced person is often better handled by a short note to self than a maintained document.
Consequence. High-consequence work gets documented even if it is rare, because the cost of doing it from memory is too high.
Turnover exposure. If the person who knows it left tomorrow, how long would it take to reconstruct? Days is uncomfortable. Weeks is a real risk.
Volume of questions. If the same question reaches the same expert repeatedly, the answer belongs somewhere other than that person's head.

If a process fails all four, leave it alone. Discipline about what you do not document is what keeps the rest credible.

Make the document the thing people actually use

A process description that lives somewhere separate from the work will drift out of date within months. The version that stays accurate is the one embedded in the doing: a template with the fields already in it, a form that will not submit without the required attachment, a checklist attached to the ticket rather than filed in a wiki.

Where you cannot embed, do the next best thing: make the document short enough to read while working. One screen. If it runs to eight pages, the useful part is one screen and the rest is reference, split them.

And put a name and a date on it. Not as ceremony, but because the first question anyone has about a process document is "is this still true?" A name means there is someone to ask.

Measuring processes without gaming them

Three measures cover most of what you need, and they are chosen partly because they are hard to fake in isolation.

Elapsed time from trigger to done. Not the time worked: the time from when the clock started to when the customer or the next team got the output. This is what anyone downstream experiences.

Rework rate. How often the output comes back. Rework is the clearest signal that the acceptance condition is either wrong or not being applied.

Exception rate. How often the standard path is not taken. Rising exceptions mean the definition is drifting away from reality.

Watch them together. Elapsed time alone gets optimized by cutting checks, which shows up as rework a month later. Rework alone gets optimized by being fussier at the gate, which shows up as elapsed time. The pair is harder to distort than either one.

Be honest about what a number can tell you. A single month's figures on a low-volume process are noise. Look at the direction over enough cycles for the pattern to be more than luck, and if you cannot get enough cycles, stop measuring and go watch the work instead.

Improving a process without a project

Large process improvement programs tend to produce large documents. Smaller, faster changes usually beat them, if you keep two habits.

Change one thing and watch it. If you alter the approval threshold, the form, and the ownership at once, you will not know which change helped. You will also not know which one caused the new problem.

Decide in advance what would make you undo it. Write the condition down before the change goes in: "if rework goes up for two consecutive cycles, we revert." Without that, every change becomes permanent by default, because unwinding it feels like admitting a mistake.

The second habit matters more than it sounds. Most accumulated process bloat is not the result of bad decisions; it is the result of good decisions that were never reviewed.

What to do this week

Pick the process that generates the most complaints. Do these four things, in this order:

Sit with the person who does it and write down every exception from the last month. Not the ideal path: the actual ones.
Count the handoffs and mark which ones have no notification.
Name one owner for the outcome and write the acceptance condition in a sentence they agree with.
Change one thing and set a date to look at it again.

That is a couple of hours of work, and it will tell you more than a full process mapping exercise, because it starts from where the work is actually breaking rather than from where the diagram says it should be.

Common questions

How detailed should a written process be?

Detailed enough that someone competent but new to this specific task can complete it without interrupting anyone. Not detailed enough to survive as a training manual, that is a different document with a different maintenance budget. If you find yourself explaining how to use a menu in software, you are writing tool documentation, and the tool will change before your process does.

Should we map every process?

No. Comprehensive mapping projects produce a shelf of documents whose accuracy decays at the same rate whether anyone reads them or not. Map what is high-consequence, high-turnover-risk, or generating visible pain. Leave the rest until one of those becomes true.

Who should write it: the person doing the work or someone else?

The person doing the work supplies the content; someone else usually writes it. People are poor at noticing the steps they have automated in their own heads, and an outsider asks the naive questions that surface them. But the doer has to agree with the final text, or it describes a process nobody follows.

How do we stop process documents going stale?

Tie the review to an event rather than a calendar. "Review when the system changes, when the owner changes, or when the exception rate moves" beats "review annually," because annual reviews get done in a batch by someone with no context. Also, resist the urge to keep documents you no longer trust: deleting one is a legitimate outcome of a review.

The short version

Processes are worth writing down when the cost of getting them wrong, or of losing the person who knows them, is higher than the cost of maintaining the description. Write the exceptions before the happy path, because the exceptions are where the process really lives. Count handoffs rather than steps. Name one owner. Say what "done" means. Change one thing at a time and write down what would make you change it back.