From the email thread to a flow with states

The problem it solves

Ask where a live request stands and watch what happens. One person says it is with administration, another that it went for approval on Tuesday, a third that it is waiting on something from the client. All three answers are sincere and none is verifiable, because the status of that request exists nowhere: it is spread across several email threads and the memories of three people.

A process without states produces its own recognisable symptoms. Nobody can say how many requests are open right now or which one has been waiting longest. Things get lost at handovers, almost never inside a task. Whoever asks most persistently moves first, so the order of attention ends up set by volume of voice. And when something falls through, reconstructing what happened means reading email backwards until you find the message nobody answered.

The cumulative effect is an operation that runs on vigilance: somebody has to remember every case so that no case stops. That has a ceiling, and the ceiling makes itself felt at exactly two moments, when volume grows and when that person is away.

What it covers

The workshop builds the design before any tool enters the conversation, working on a real process the group picks at the start: a service request, a work order, an authorisation, a complaint. The first task is documenting it as it happens today, waits and backward steps included, which is what separates this from a textbook diagram. Then the states get named, and they are named for what the case is waiting on rather than for the department it is sitting in, because a state named after a department says nothing about what is missing.

Each state then receives three things: an owner, a written condition for leaving it, and a window within which it ought to move. That exit condition is the heart of the design, because it forces a definition of the word pending, which in practice covers wildly different situations. Pending a decision, pending a client's reply and pending somebody remembering are three separate conditions that call for three separate responses.

The demanding part is exceptions, which is where every diagram fails. The urgent case that skips two states, the one that goes backwards because new information arrived, the one that fits no category at all. The group designs an explicit route for them, naming who authorises the jump and where the case rejoins the normal path, instead of leaving them to improvisation, which is how they run today. Alongside that, the group decides what gets recorded without anyone touching it and what requires a person to look, by judgement or by risk.

The close is a test. Participants run several real cases from recent weeks through the designed flow, including the ones that went wrong, and adjust whatever does not survive contact with them. Only at the end does the conversation turn to which parts of the flow deserve a tool behind them and which will keep working well enough on what already exists.

What participants learn

• Document a real process with its states, waits and backward steps as they happen today.
• Give each state an owner, a written exit condition and a window for moving.
• Define what gets recorded without intervention and what requires a person to look.
• Design an explicit route for exceptions, naming who authorises and where the case rejoins.
• Test the flow against real cases from recent weeks before rolling it out.

Agenda

1. 01States, transitions and conditions for moving on
2. 02One owner per state, and what pending actually means
3. 03Approvals: who approves, with what information, within what window
4. 04Exceptions and the cases that do not follow the path
5. 05Automatic record-keeping versus human intervention
6. 06Testing on real cases before rollout
7. 07What gets measured once the flow exists

What the organisation leaves with

• A real process documented with its states, conditions for moving on, and backward steps.
• An owner and a written exit condition for each state, agreed with the people involved.
• A written treatment of exceptions: what triggers them, who authorises, and where the case rejoins the flow.
• A short set of flow measures: how many cases sit in each state and which has waited longest.