The short answer
Follow one request from arrival to completion. Identify the person responsible for every decision and the information needed at each handoff. Automate only after you can explain how the work succeeds and how someone recovers when it fails.
Follow one ordinary request.
Begin with a routine example instead of an idealized diagram. Ask the people doing the work to describe what arrives, where they record it, and who decides what happens next. Use fictional or sanitized information when discussing the process outside your organization.
A request may pass between a form, an inbox, a spreadsheet, and a person who knows an unwritten exception. That exception is part of the process. Document it before treating the work as a sequence of interchangeable steps.
Separate the movement from the decision.
Moving information is different from deciding whether it is complete, appropriate, or ready for approval. A useful first automation can prepare a draft or organize a queue while a person retains the decision. Write down exactly what the automated step may do and what it must leave for review.
An illustrative example is an inquiry that arrives without a project description. A tool can flag the missing field and prepare a request for clarification. It should not invent a description so the record appears complete.
Give failure a visible destination.
A workflow needs an owner when a source is unavailable, an input is incomplete, or a request arrives twice. Describe where the item waits, how someone notices it, and how the owner retries or corrects it.
Distinguish an attempt from a completed action. Preparing an email does not mean sending it. Sending a request to another system does not mean that system completed the work. The status shown to a person should describe what has actually happened.
Test a small change against the same example.
Choose one handoff with an understandable input and output. Walk through the ordinary case, an incomplete case, and a repeated request. Check what is recorded and whether a person can find and correct a failed item.
Keep a way to return to the previous process while you learn how the change behaves. Expand the automation only after the owner can explain its boundary and the evidence that shows it worked.
Put the questions on paper.
- Who owns the decision at this handoff?
- What information is required before the next step?
- What happens when the same request appears twice?
- Where does failed work wait, and who notices?
- What evidence shows the intended action completed?
These questions are useful even when the answer is a clearer manual process. The purpose is to make the work understandable before adding another dependency.
Discuss the workflow