Process Discovery
Part of Process discovery and mapping
Mapping a process from trigger to business result
Define a process trigger and verifiable result, trace one case through handoffs, and check that the endpoint reflects the recipient’s outcome.
Mapping a process from trigger to business result means choosing one case type, defining the event that starts it, and stating the result that proves it finished. Follow that case through every decision and handoff. Do not end at an internal milestone while the recipient still waits for the outcome.
Mapping a Process from Trigger to Business Result
- TriggerObservable event: request received, order accepted, or change approved
- Start ConditionRequired information must be present at trigger point
- HandoffsRecord input, output, responsible role, receiving role, and system state changes
- Decision PointsUse clear questions (e.g., 'Is the information sufficient?') with labelled outcomes
- FinishVerifiable outcome: usable response delivered, declined with reason, or withdrawal recorded
Fix the start and finish first
Write the start as an observable event: a request received, an order accepted, or a change approved. Specify the information that must exist at that point. If incomplete requests enter the process, show their correction route; do not redefine the trigger after seeing how long they take.
Describe the finish in terms the recipient can verify. For a hypothetical customer enquiry, an acknowledgement shows receipt. A usable answer delivered to the customer and recorded by the business is a different endpoint. An unsuccessful or withdrawn enquiry also needs a recorded outcome rather than disappearing from the map.
A possible boundary statement: Starts when the team receives an enquiry; ends when the customer receives a usable response, the request is declined with a reason, or the customer withdraws it. Set the exact terms for the process being mapped.
Steps to Map a Process from Trigger to Business Result
- Define the triggerUse an observable event such as 'enquiry received' or 'order accepted'
- Specify required inputs at triggerEnsure all necessary information is available; show correction path for incomplete requests
- Define the finishOutcome must be verifiable by recipient—e.g., acknowledged, responded to, declined, or withdrawn
- Set boundary statementExample: 'Starts when the team receives an enquiry; ends when the customer receives a usable response, the request is declined with a reason, or the customer withdraws it.'
Trace one case through the handoffs
Choose a recent case. Ask each participant to describe their next action, then build the route in plain verbs: receive, check, assign, decide, respond, confirm.
For every step, record its input, output, responsible role and receiving role. If a step changes a system record, note which record and what state it should show.
Pay particular attention to handoffs. The map should answer who sends the item, who accepts it, what information moves, and what happens when it is missing.
A request in a shared inbox is not necessarily assigned work. A task marked complete may mean the sender finished, even though the receiving team has not acted.
Where the route changes, use a decision question. For example, Is the information sufficient to decide? leads either to a decision route or to a request for correction. Label both outcomes. If the decision depends on a rule nobody can state consistently, mark that uncertainty; a neat diamond does not resolve it.
Key Elements to Verify in Process Mapping
- Trace one real case through each stepUse plain verbs: receive, check, assign, decide, respond, confirm
- Document inputs and outputsInclude responsible role, receiving role, and system record changes
- Clarify handoff conditionsWho sends? Who accepts? What data moves? What happens if missing?
- Handle ambiguous decisionsMark uncertainty where rules aren't consistently applied—even if the diagram shows a decision diamond
Check the endpoint with a second case
Walk another case through the draft map, preferably one with a different legitimate outcome. Ask whether it enters at the same trigger, where it diverges, and what proves its final state. If it needs a fundamentally different start or result, consider a separate map rather than forcing it into a crowded branch.
Check the endpoint with the person or team that uses the output. Can they act on it without another clarification? Is a notification followed by a wait, fulfilment or correction outside the first team? Extend the boundary if that work is part of achieving the stated result.
The finished map should let a reader identify the case's current owner and next action at any point. It should distinguish a completed result, a declined result and an item still open. Once those states are clear, the team can use the same boundary for a baseline and for any later process change.
Valid vs Invalid Endpoints in Process Mapping
- Valid EndpointCustomer receives a usable response, request is declined with reason, or withdrawal is recorded
- Invalid EndpointRequest disappears without trace, task marked complete but no action taken by recipient
