01
Choose one traceable unit and boundary
Start with one unit that can be followed from beginning to end: a claim, batch, payment, denial, or information request. A map called simply ‘billing’ is too broad to show who owns a decision or where work waits.
Write a specific start event and end condition, then record what is included and excluded. The boundary should be narrow enough that the team can trace real examples without changing the subject halfway through the exercise.
- 1Name the unit of work being followed.
- 2Write the observable start event and completed end state.
- 3Record the teams, systems, and scenarios that are in or out of scope.
02
Walk the real work, not only the policy
Observe how people complete the work in the systems they actually use. Compare that path with the written procedure, because undocumented workarounds, duplicate entry, and personal tracking files often explain delays that a policy-only map misses.
For every step, capture the owner, information received, system used, action performed, output created, next receiver, expected timing, and evidence of completion. Keep the wording concrete enough that another person could recognize the event in a work queue or audit trail.
03
Add decisions, handoffs, and exception paths
Map the normal path first, then add the exceptions that materially change ownership, timing, or evidence. At each decision, record the criteria, the role with authority, the reason captured, and the next owner and deadline.
Do not treat sent, received, accepted, and completed as the same state. A clean handoff states what the receiver must acknowledge and what happens when the item is incomplete, rejected, or not accepted on time.
- 1Mark every point where the work can branch or stop.
- 2Name who decides and what evidence supports the decision.
- 3Add an owner and deadline for every exception route.
04
Place controls where failure could stay invisible
A useful control detects missing, late, duplicate, or incorrect work before the failure becomes an aged balance or compliance issue. Define its owner, criteria, frequency, evidence, and resolution route instead of labeling a box only as ‘quality check.’
Use independent reconciliation where a downstream total must agree with an upstream source. A dashboard can show volume, but the process still needs a named owner who investigates differences and records their disposition.
05
Test the map and assign its owner
Trace at least one normal example and one exception through the completed map. If the team cannot identify a current owner, system state, or completion record at any point, the map has exposed an operating gap that needs a decision.
Assign one owner for maintaining the map, define review triggers, and link the approved map to the procedures, training, and control evidence it governs. Update it when systems, payer requirements, roles, or escalation paths change.
- 1Validate the map with the people who send and receive the work.
- 2Agree on unresolved ownership and control decisions.
- 3Publish the approved version with linked procedures.
- 4Set event-based and scheduled review triggers.
