Map one real case from arrival to completion before discussing tools. The map should expose the people, records, waiting and exceptions that an automation proposal must handle.
Follow a case, not a department chart
Choose a recent, representative request and ask the people who handled it to reconstruct what actually happened. A policy document may describe the intended route while the work moves through email, calls and a shared spreadsheet. Record both where they differ.
Give the case a clear starting event and an end condition. “Someone sends an email” is a trigger. “The request has an approved outcome and the requester has been informed” is a more useful completion definition than “the system ran”. Keep the first map small enough for one accountable owner to explain.
Use a handoff record
| At each step | Record |
|---|---|
| Input | What information arrives, from where, and in which format? |
| Person | Who performs the work and who has decision authority? |
| Action | What is read, checked, changed or communicated? |
| Wait | What is the case waiting for, and who can move it forward? |
| Output | Which record proves the step completed? |
| Exception | What happens when the expected input or person is unavailable? |
Use roles in a broadly shared map and keep private records in their authorised location. The purpose is to understand the process, not to collect unnecessary customer or employee data.
Separate handling from waiting
An invoice might take several days to finish while only a small part of that time involves active work. If most delay comes from a disputed approval rule, faster data entry will not resolve the underlying decision. Ask the team to identify observed handling, queue time and rework separately.
Do not present a few remembered cases as a precise baseline. Label estimates and record what period or sample would make them more dependable. Process-mining tools can assist where suitable event data exists, but a carefully documented workshop is still useful for a bounded first project.
Look for a process fix before a software purchase
Compare the actual route with the agreed route. Missing required fields may call for a better intake form. Repeated approval disputes may call for a responsibility decision. Duplicate records may call for a stable identifier. Write these changes into the brief before choosing an integration platform.
An illustrative equipment-request process might need a budget owner and a replacement policy before any automation. That finding is progress: it turns an ambiguous build request into decisions the business can make.
End with a reviewable brief
- Name the process owner and the completion condition.
- Attach the handoff map and the known exceptions.
- Identify authoritative records and permitted access.
- Mark disputed rules and unmeasured assumptions.
- List the smallest candidate improvement and its acceptance evidence.
Sources and further reading
Put the decision into practice
Bring one process map and a difficult exception to a workflow-scoping discussion.
Explore Workflow Automation Discuss the requirement by email