How to document a business process before you automate it.

A workflow tool executes the process it is given, at speed, without hesitating at the parts that were never settled. If two people in the business handle the same enquiry differently and both believe they are right, automation does not resolve that disagreement. It picks one of them by accident, at the moment somebody configures the rule, and then applies it a thousand times.

This is why "document it first" sounds like bureaucratic throat-clearing and is not. Documentation is where the disagreements surface while they are still cheap to fix. The cost of discovering them afterwards is not just rework: it is rework on top of a system that people have already started trusting.

There is a narrower version of this that matters even more. A process can be perfectly consistent and still be undocumented in the only sense that counts — nobody has written down the decisions inside it. Two people can perform identical steps and apply completely different judgement at the point where the process branches.

The test is not whether somebody could follow the steps. It is whether two people, given the same unusual case, would independently reach the same decision.

Most internal documentation describes activity. Open the enquiry, check the details, send the quote, follow up. That is a summary of what a competent person does, which is useful for training and nearly useless for automation, because it contains no decisions, no conditions and no owners.

A process is documented when someone who has never done it can tell, at every point, what happens next and who is responsible when it does not. That requires four things the activity list leaves out: the trigger that starts it, the decision made at each branch, the owner of each state, and the definition of finished.

The word "owner" is doing real work there. An unowned step is not a slow step; it is a step that stops. Writing the owner down is frequently the moment a business discovers that a stage everybody assumed was handled belongs to nobody at all.

This is deliberately short. A documentation exercise that tries to capture everything produces a document nobody maintains, and an unmaintained document is worse than none because people still trust it.

For each step in the process, record:

• TRIGGER

  What causes this step to begin. A form submission, a date, a status change, a person noticing something. If the trigger is "someone remembers", write that down honestly — it is the most common failure point and it cannot be automated until it is replaced.

• INPUT

  What has to exist before the step can start, and where it lives. Half of automation delays are a field that is theoretically required and practically often empty.

• DECISION

  The question this step answers, and the rule used to answer it. If the rule is judgement rather than criteria, say so explicitly rather than inventing a rule that nobody actually follows.

• OWNER

  The role accountable for the step. Not the team — the role. "Operations" is not an owner.

• OUTPUT

  What exists afterwards that did not exist before. A record updated, a message sent, a decision recorded. If nothing changed, the step is ceremony.

• EXCEPTION

  What happens when the step cannot complete, and where the work goes. This is the part that is almost always missing, and it is the part automation most needs.

Ask a team to describe their process and you will get the version that works. The customer provides the information, the quote goes out, the customer replies. Automating that version produces a system that handles the easy cases, which were never the expensive ones.

The process that actually consumes the week is the exception path: the missing detail, the customer who replies to the wrong thread, the job that needs re-quoting, the approval that arrives after the deadline. Those are not edge cases. In most small businesses they are a substantial share of the work, and they are where the time goes.

So the documentation question worth asking is not "what do you do" but "what happened the last five times this did not go cleanly, and what did you do then". The answers tend to be specific, remembered and immediately useful.

The order matters, because asking first anchors everyone to the tidy version. Watching the work happen produces the real one.

1. 01

   Pick one process with a real boundary

   Decides

   Where does this process start and stop?

   Output

   A named process with an agreed trigger and an agreed definition of finished.

2. 02

   Watch it happen, without correcting it

   Decides

   What actually occurs, including the parts people work around?

   Output

   Notes on real cases rather than a description of intent.

3. 03

   Collect the last handful of exceptions

   Decides

   How does this process behave when it does not go cleanly?

   Output

   A list of real exception paths and what was done about each.

4. 04

   Draft the six fields per step

   Decides

   For each step: trigger, input, decision, owner, output, exception?

   Output

   A draft that can be disagreed with specifically.

5. 05

   Walk it through with the people who do it

   Decides

   Where is this wrong, and where do two of you disagree?

   Output

   Disagreements surfaced and settled by a decision, not an average.

6. 06

   Decide the unowned steps

   Decides

   Who owns each step that currently has no owner?

   Output

   Every state has a named role accountable for it.

Documentation does not usually become wrong in one event. It drifts: a step changes, nobody updates the page, and the page keeps being technically present while gradually becoming fiction. The danger is that it still looks authoritative.

The practical defence is not a review schedule that nobody honours. It is to tie the document to something that already changes — the system it describes. When the workflow changes, the document changes in the same piece of work, or the change is not finished.

1. 01

   Drafted

   Owner

   The person who ran the documentation exercise

   Advances when

   Reviewed by the people who perform the work

   Ends when

   Abandoned if nobody reviews it

2. 02

   Agreed

   Owner

   The process owner

   Advances when

   Disagreements resolved and decisions recorded

3. 03

   In use

   Owner

   The process owner

   Advances when

   Referenced when the work is performed or handed over

   Ends when

   Becomes stale when the process changes without it

4. 04

   Stale

   Owner

   Nobody

   Advances when

   Rediscovered during the next change and repaired

   Ends when

   Quietly ignored, which is the usual outcome

Readiness is not about document length. It is about whether the ambiguity that automation would freeze in place has been removed.

A process is ready to automate when all of these are true:

• THE TRIGGER IS AN EVENT

  Something observable starts it, rather than a person remembering. If the trigger is memory, that is the first thing to fix, and fixing it is often most of the benefit.

• EVERY BRANCH HAS A RULE

  At each decision point there is a stated rule, or an explicit acknowledgement that a human decides and why.

• EVERY STATE HAS AN OWNER

  Including the exception states. An automated process with an unowned exception queue creates a place for work to disappear faster than before.

• FINISHED IS DEFINED

  There is an agreed condition under which the process ends, including the unsuccessful ending.

• THE DATA EXISTS

  The inputs the automation will read are actually populated in practice, not merely present as fields.

• THE PROCESS IS STABLE

  It has not changed materially in recent weeks. Automating a process that is still being redesigned means building twice.

If several of these are false, that is useful information rather than a delay. It usually means the valuable work is process design, and automation is the second half of it.

1. Automation executes the process it is given; it does not settle disagreements inside that process, it freezes one version of them.
2. A list of activities is not documentation. A documented process states the trigger, the decision at each branch, the owner of each state, and what finished means.
3. The exception paths are where the week actually goes, and they are the part most commonly left out of both documentation and automation.
4. An unowned step does not run slowly, it stops. Naming owners routinely reveals stages that belong to nobody.
5. Readiness is measurable: event-based trigger, a rule at every branch, an owner for every state including exceptions, a defined ending, populated data, and a process that has stopped changing.