Map a Workflow in 30 Minutes

A booking may look simple to the customer, yet the business may copy the request into two systems, wait for a missing detail, assign the wrong person and correct the job after completion. A quick map of the actual route from request to finished service makes the waits and handoffs visible. You do not need specialist software or an elaborate diagram. Give one real case thirty minutes, involve the people who do the work and show what happened rather than what the procedure says should happen.

Choose a clear starting and finishing point

Pick a frequent process with a result you can observe. For a car repair garage, it might start when a customer requests a service booking and end when the completed car and invoice are handed over. Include only the steps within that boundary. A wider map covering every activity from marketing to annual accounts is difficult to finish and less useful for a first test. Choose a recent typical case and, if possible, one case that required a correction. Ask the receptionist, mechanic and person who invoices what each actually received and passed on.

Write each action on a separate card or line: receive request, confirm vehicle and symptoms, agree appointment, inspect, authorise extra work, order parts if needed, perform repair, check completion, tell customer and invoice. Put the cards in the order the case followed. Show any decision where the route splits, such as whether the customer approved a new part. Mark who owns each step and how the next person knows it is ready. An arrow is enough; you do not need a formal notation. ASQ describes a process map as a way of showing actions, decisions, people and time in sequence.

Use a thirty-minute timetable

For the first five minutes, agree on the start, finish and specific case. In the next ten, ask the person doing each step to place it on the map, including unofficial messages and workarounds. For the following ten, mark waits, handoffs, information requested more than once and corrections. Use the last five to choose one question to measure on the next few cases. If discussion turns into deciding who is to blame, return to what the customer needed and what information was available at each handoff. Keep a parking list for issues outside the chosen boundary.

Measure elapsed time from first request to completion, not merely minutes of hands-on work. A two-day delay waiting for customer authorisation may be more important than a two-minute data entry step. Count how often a case changes owner and how often information or work must be corrected. Record both the starting and finishing timestamps in a consistent way. A weekend, parts shortage or different job type can make two cases incomparable; add a short note when it happens. The map is a hypothesis about where time is lost until several real cases support it.

A small garage example

Assume the garage completes five similar maintenance jobs. One customer's booking was taken by phone, written on a sheet, copied into a scheduling system and then repeated to the mechanic. Two of the five jobs were paused because the vehicle details did not reach the mechanic; each pause added approximately one working hour of elapsed time. The average request-to-completion interval for the five jobs was two business days. These figures are illustrative assumptions, not a benchmark for garages. A single unusual repair could change the average substantially.

The team decides that the receptionist will capture the vehicle identifier and the customer's main concern once, in a shared job record, then read those details back before confirming the booking. The mechanic will still perform the independent safety and completion checks. For the next five comparable jobs, the team counts missing-detail pauses, corrections and time from request to handover. If the missing-detail pauses disappear but elapsed time does not change, another wait may be more important. If the new capture step slows bookings or yields inaccurate details, revise it. A map gives a place to test a change, not proof that the proposed fix will work.

Identify handoffs that need attention

At each handoff ask: what must be present before the next person can work, how is the transfer signalled, and who resolves an exception? A booking may be sent but never acknowledged. A completed repair may wait for a final quality check because nobody owns it. A customer may have approved one part but not a second. Make the status visible in one agreed place, with a clear owner for unresolved questions. Do not remove an approval merely because it takes time if it protects the customer or satisfies a safety or legal requirement.

A map can expose duplicate work as well as missing steps. If two people type the same address, ask why: one may be correcting unreliable information, or both may be required to verify something important. Separate copying from independent verification. A quality, identity or payment check should stay until its purpose and replacement control are understood. For persistent duplicate entry, see Find and Remove Double Work. If the team needs a recurring place to review tests, see Run a 15-Minute Weekly Improvement Meeting.

Turn the map into one test

Choose a change small enough to reverse. For example, add a mandatory confirmation of vehicle details at booking for five similar jobs. Record the baseline for five earlier cases, then the same measures for five new cases: elapsed time, handoffs and corrections. Keep an eye on customer wait time and staff workload as safeguards. Decide in advance what would count as a useful change and what would make you stop. If cases vary widely, use a rough range and inspect each case rather than relying on an average alone.

The Institute for Healthcare Improvement describes small tests as a way to plan a change, try it, study the result and act on what was learned. That approach transfers well to a small business, but it does not mean every process needs a formal programme. One owner, a few cases and a dated note about what changed are sufficient for a first cycle. If a bottleneck depends on regulated approvals, personal data, vehicle safety or specialist technical judgment, involve the appropriate professional before simplifying it. Local rules and contract requirements vary.

Avoid mapping from memory alone, drawing an idealised sequence, or redesigning the whole business at the first meeting. The map should reflect exceptions and workarounds that people use under pressure. Avoid blaming the person who catches errors: the map may reveal that the information reaching them is incomplete. If the proposed fix moves work to someone else, measure total effort across the team, not just the time saved by one role.

Next step: take one recently completed service, draw the route from request to handover in thirty minutes, and circle the longest wait. Over the next five similar cases, record elapsed time and the number of handoffs or corrections before testing one change.

Sources

• ASQ: What is a flowchart?. Process mapping, decisions, handoffs and opportunities for improvement.
• Institute for Healthcare Improvement: Testing changes. Guidance on small tests and learning from results.