01Make the work visible
Consider a service request arriving by email. Someone copies the details, checks availability, asks for missing information, and updates a spreadsheet. To design a system, observe a sample of cases and record what comes in, who makes each decision, what changes, and when the request counts as resolved.
Exceptions deserve as much attention as the usual path. What happens when dates are missing, two identical requests arrive, or nobody replies? Each answer reveals a rule, a state, or a responsibility that the product will need to represent.
02Give each case an identity and a state
An initial version can assign each request an identifier and support clear states: received, awaiting information, ready for review, and closed. Each transition needs explicit conditions. The interface can then show what is missing and who owns the next action.
Retries also need a design. If the connection drops after a request has been created, resubmitting it could create a duplicate. An idempotent operation allows the same request to be repeated without additional effects. The service must recognise it through a stable key and enforce that guarantee; adding an identifier to the form is not enough on its own.
03Measure before expanding
A pilot can begin with one request type and a person responsible for exceptions. Measure time to resolution, required corrections, and cases that get stuck. Comparing those figures with the original process helps identify the next useful change and whether the added software is helping.
If interpreting free text becomes a bottleneck, evaluate a model that proposes structured fields while preserving the original message and validating the output. A specific need should justify that addition. An explicit rule remains a useful tool when the decision is already well defined.
| Status | What is needed next |
|---|---|
| Received | Check that the required details are present. |
| Awaiting information | Ask the requester for missing details. |
| In review | Confirm availability and the response. |
| Closed | Record the resolution and who handled it. |
Have a process that needs a different way to work?
Let’s talk