
Process Discovery
Process discovery and mapping
Learn how to discover the current process, map handoffs and exceptions, and check the route against real cases before proposing changes.
Process discovery establishes how work actually reaches a business result. Mapping makes the route visible: trigger, people, decisions, handoffs, exceptions and endpoint. Start with a current-state map built from real cases. Use it to identify what needs clarification or repair before drawing a proposed route.
A useful map lets someone follow a work item across teams and judge whether the recipient got the intended result. It need not show every click or use specialist notation.
Set a boundary people can recognise
Name one process and the result it should produce. Agree the event that starts a case and the evidence that closes it. For a service request, receipt might start the work; a recorded, usable response might end it. An acknowledgement or closed internal task may occur earlier.
State which requests are in scope, which are excluded, and what happens at the boundary with another process. Record the process owner and the people who provide or receive its output. This keeps the map focused while making cross-team work visible.
Define before mapping / Question to settle
- Trigger
- What event creates a case, and where is it recorded?
- Result
- What can the recipient do when the work is complete?
- Boundary
- Which related work belongs on a different map?
- Owner
- Who can resolve a disagreement across teams?
Discover the current route
Start with recent cases that show ordinary work and different outcomes. Ask the people who receive, perform and depend on the work to walk through what happened. Inspect the forms, messages or system records they use, subject to appropriate access. Include the team receiving the final output; it may see corrections the originating team does not.
For each case, note who held the next action, what information they needed, which rule guided the decision, and where the item went next. Mark waits and returns for missing information. If two people describe different routes, record the variation and the conditions that explain it. Do not settle the disagreement by drawing only the procedure-manual route.
A small set of cases can reveal a route without establishing how often it occurs. Label uncertain steps for follow-up and use available records to check frequency when that matters to a decision.
Pros and Cons of Using AI for 24/7 Business Monitoring
- ProsContinuous tracking of process performance; detects delays and bottlenecks in real time
- ConsMay miss context behind human decisions; risks over-reliance if not paired with stakeholder input
Draw a map that can be checked
Put the trigger on the left and the business result on the right. Add main activities in order, with a lane or clear label for each responsible role. Show decisions as questions with named outcomes. At every handoff, identify what is passed, who accepts it, and how the sender knows it arrived.
Keep the first view readable. Put detailed rules, fields or system actions in notes when they would crowd the main route. Use the same terms for a case, status and outcome throughout.
Beside the normal path, mark where work can be returned, stopped, escalated or completed by another route. Record what happens to the case after each departure. A line ending at an exception box leaves an important question unanswered.
Check the map against cases and people
Walk a completed case through the map from start to finish. Then try a case that was returned, delayed or still open. Ask each role whether the map shows the action they actually took and the information they received. Check that a downstream team agrees with the stated endpoint.
Keep the current-state map distinct from a proposed change. When someone suggests removing a step or automating a handoff, capture it as an improvement idea. First establish why the step exists and what would replace any decision or record it provides.
Turn discovery into a decision
The map should leave the team with observable problems and open questions. A repeated return may point to an unclear intake requirement; an unowned wait may call for a named decision maker; two parallel records may need reconciliation. These are hypotheses to investigate, not conclusions proved by the drawing.
Choose a measure whose start and end match the map, such as elapsed time from a valid request to a confirmed result. Keep returns, unresolved cases and work passed to other teams visible. Assign an owner to each proposed change, and update the map when the route changes.
Discovery is complete enough to support a decision when the people involved can explain the route, its important variations and what remains uncertain.
In this guide
- Mapping a process from trigger to business resultDefine a process trigger and verifiable result, trace one case through handoffs, and check that the endpoint reflects the recipient’s outcome.
- Recording exceptions alongside the normal pathShow where cases leave the normal process, who owns them, and how they return or close without crowding the main map.
- Identifying workarounds that hide a broken processFind undocumented workarounds, trace the obstacle each one solves, and decide whether the process needs repair before removing a local fix.


