Map the Work That Actually Happens

Why this matters

Official process diagrams are usually fiction. They show what people told HR or what someone hoped would happen. Real work has triggers, handoffs, waits, exceptions, rework loops, and quiet judgment calls that never appear on the slide. Before you change anything, map the current state as it is actually performed. If you get the trigger wrong, the rest of the map will be wrong.

What you will be able to decide after this

Where the workflow really starts — the actual trigger, not the one in the procedure.
Who really does each part, and where the waits and rework actually sit.
What baseline numbers any change will be measured against.

Core lesson

Start with the real triggers

A trigger is the event that actually starts the work — not the one written in the procedure.

Real triggers look like this:

A customer email lands in a shared inbox
A form is submitted with a specific field completed
A threshold is crossed in a system
Someone forwards a message with "can you handle this?"
A calendar event or SLA timer expires
A person notices something is wrong and starts an informal process

If the map starts one step too early (at a schedule, a dashboard, a monthly meeting), you will map motion, not work. If it starts one step too late, you will miss the queue that the whole cycle waits on.

How to see the real work

Do not rely only on interviews or the official documentation. Combine:

Direct observation or shadowing — the fastest correction to the official story.
Event logs and timestamps where they exist — actual start times, wait times, done times.
Simple process mining or event-log analysis when the systems support it. Many workflow, ticket, or CRM systems already record enough data to show actual paths, loops, and waits. Process mining tools are useful when available. They are not required. The goal is accurate visibility, not a specific product.
Artifact review — what tickets, messages, or documents actually get created, in what order.
Exception and rework samples — the runs that went wrong are the ones that show where the design breaks.

What to capture:

Real trigger(s) that start the work
Inputs required
Steps and decisions in the real order
Who actually does each part
Systems and tools touched
Handoffs and waits
Common exceptions and workarounds
What "done" looks like in practice
Baseline time, volume, error/rework rate, and pain points

Keep the map simple enough that someone who does the work recognizes it. Detail that the worker does not recognize is not detail; it is decoration.

Worked example

A support team's official flow chart shows a ticket entering a triage queue, being routed by priority, and closing after resolution. The actual map, built from logs and shadowing, shows three different real triggers: an email to the shared inbox (60% of starts), a form submission with the "escalation" field completed (30%), and a direct message from a senior person (10%). The queue never empties because the senior-person path bypasses triage entirely and skips the tracking system. The waits are not in triage; they sit between first reply and the specialist's assignment, averaging 14 hours — invisible on the official chart. The baseline: 38 cases a week, 14-hour specialist wait, 11% first-touch resolution. The trigger was an email; the real trigger is three of them, and one of those three explains the biggest wait.

Practice

Pick one recurring workflow you care about. List its possible triggers — including the informal ones. Then check the official documentation for this workflow and write down what it claims the start is. Note the gap.

Apply — produce the artifact

Produce a current-state map for that one recurring workflow. State the real trigger(s) explicitly. Capture the steps in real order, who does each part, the systems touched, the handoffs and waits, the common exceptions, what "done" looks like in practice, and the baseline numbers: time, volume, error/rework rate, pain points.

Verify

Show the map to at least one person who performs the work. Ask them specifically: "Is this how it actually starts, and is this the path it usually takes?" If they say no, revise until they agree it matches reality.

Sources

This module is original practice guidance based on the authoring standard and does not depend on a specific external factual claim. Editorial review is still required.