Your Process Map Has a Waiting-Time Problem

A customer sends the requested information on Tuesday morning. The team starts the next step on Thursday afternoon. The process map shows one arrow between them, so the gap disappears.

That gap is where a lot of customer frustration lives. To find it, map the time between steps as carefully as the steps themselves. Record when work arrived, when someone picked it up, what it waited for, and who could move it forward. A clean-looking flowchart can hide days of waiting.

This matters before you add an AI tool. A tool may help summarize an intake, draft a reply, or create a task. It cannot resolve a handoff that has no owner or a decision nobody has made.

The arrow is not the whole process

A process map usually names actions: request received, information checked, work assigned, response sent. Record arrival, start, every blocked/resume pair, and finish for each handoff:

• Arrived: when the next person or system had enough information to act.

• Started: when someone began the work.

• Blocked and resumed: record every pause and restart separately, with the reason if it is known.

• Finished: when the promised result or next handoff is complete.

The gap between arrival and start is waiting time. The time spent doing the work is touch time. They answer different questions. A task can take ten minutes to complete and still keep a customer waiting for two days. Calendar elapsed time is not the same as working hours, and timestamps alone do not tell you how much active effort the task took.

The American Society for Quality’s value-stream mapping guidance asks teams to examine the current state and distinguish processing from lead time. That is useful for service work too: follow a real item, include the pauses, and check the map with the people who handle it.

A fictional onboarding trail, with the quiet gap exposed

Consider a fictional small service firm onboarding a new customer. The team has a checklist, but handoffs cross email and a work tracker.

• Tue, 9:10 a.m. — Intake received: customer sends the signed form.

• Tue, 9:25 a.m. — Ready to review: coordinator confirms required files are present.

• Wed, 3:40 p.m. — Review starts: account lead opens the packet.

• Wed, 3:55 p.m. — Blocked: one answer conflicts with the signed form.

• Thu, 10:05 a.m. — Clarification requested: coordinator asks the customer to confirm.

• Thu, 1:20 p.m. — Clarification received: customer replies.

• Fri, 11:15 a.m. — Review resumes: account lead checks the update.

• Fri, 11:40 a.m. — Kickoff confirmed: team records and sends the agreed next step.

The timestamps show 74 hours and 30 minutes from intake to kickoff in calendar time. They do not tell us the team’s total active work time, and they do not prove the whole delay was avoidable: the customer needed time to answer, and the account lead may have other priorities. They do show two queues worth investigating: 30 hours and 15 minutes from ready-to-review to review start, then 21 hours and 55 minutes from the customer reply to review resuming. These are fictional elapsed gaps, not measured performance claims.

The team could sort each gap into four buckets:

1. Waiting for the customer: Was the request clear, and did the customer know what was needed?

2. Waiting for a decision: Who can resolve the conflict, and what evidence do they need?

3. Waiting in a queue: Is work ready but unassigned, or assigned without a priority?

4. Unknown cause: The record does not show why work paused. Ask the people involved and verify before assigning a cause.

In this example, the coordinator’s request for clarification and the customer’s response are visible. The queue before review and the later gap before the account lead resumes are also visible. Those are different conditions. One might improve with a clearer request; another may need a named backup reviewer or a capacity decision.

Do not jump from “the queue is long” to “automate the queue.” First confirm that the team agrees on priority, ownership, and the finish condition. Then decide whether a tool can help with a bounded part, such as highlighting a missing field or preparing a review task. The human still resolves conflicting source information.

Four labels make waiting easier to act on

A useful process review does not need a sophisticated time study to start. Put a short reason next to each pause:

• Customer response. The process is waiting for information or approval outside the team. Check whether the request was understandable and specific.

• Decision. Two sources conflict, a policy is unclear, or the person handling the work lacks authority. Find the decision owner before adding automation.

• Queue. The next step is ready, but no one has capacity or ownership. Look at assignment rules and workload.

• Unknown. No one can explain the pause from the record. That is a documentation or visibility problem. Do not convert an unknown into a confident AI recommendation.

NIST’s AI Risk Management Framework puts understanding the context in its Map function and measuring context-relevant outcomes in Measure. It is a voluntary framework, not a prescribed business-process audit. The relevant idea here is modest: document the setting, people, assumptions, and evidence before deciding what role an AI system should play.

Make the quiet gap visible

• Arrived → started: Record both times; label estimates.

• Blocked → resumed: Keep each pause and its reason.

• Waiting on: Customer, decision, queue or unknown?

• Next move: Name the person who can resolve this wait.

A one-week trace your team can run

Pick one repeatable customer process and follow a small set of real items for one week. Do not collect more personal information than needed; use your approved system and privacy rules.

For each handoff, record arrival, start, every blocked/resume pair, finish, the current owner, the wait label, and whether the customer could see the next step. Keep the definitions stable. If staff only remember times after the fact, mark them as estimates instead of presenting them as exact.

At the end of the week, compare the longest waits. Ask the person who did the work what was happening, then check the record. Choose one small change that has an owner: a clearer intake question, a visible ready-for-review status, a backup approver, or a daily queue check.

The test is not “did the map get shorter?” It is whether the change reduced a specific avoidable pause without increasing rework, errors, or customer confusion. If volume is low or the cases differ, treat the result as a clue and keep observing rather than claiming a proven improvement.

If the team tracks the work in ClickUp, the workspace guide can help make ownership and status visible. If an AI-supported step is appropriate, the Claude workflow guide covers practical use with review. For what a team should retain after an implementation, see the AI workflow handover runbook. A good handoff also says where to find the process owner, instructions, exceptions, and fallback.

Questions about process waiting time

What is the difference between touch time and waiting time?

Touch time is the time someone spends doing the work. Waiting time is the elapsed gap while the work waits for information, a decision, an owner, or capacity. Measure both when you want to understand the customer’s total experience.

How do I find bottlenecks in a customer process?

Trace real work items through each handoff. Record arrival, start, every blocked/resume pair, and finish, then ask the people involved what caused the largest gaps. Validate recollections against the system record where possible.

Should I automate a step that causes a long delay?

Not automatically. First find out whether the delay is caused by an unclear rule, a missing owner, a customer response, or a capacity queue. Automate only a well-defined step where the tool can help without making an unresolved decision.

What if the team does not have exact timestamps?

Start with a short observation period and label estimates clearly. You can also add lightweight timestamps to an approved workflow record. Do not imply minute-level precision when the team only remembers the day.

Can AI identify process bottlenecks from task data?

AI may help summarize or categorize records, but only if the data is appropriate, the categories are defined, and a person checks the result. It cannot infer an unrecorded cause with certainty. Keep the source record and uncertainty visible.

How many customer cases should we trace?

There is no universal number. Start with enough comparable cases to see whether the same kind of wait recurs. If volume is low or cases vary, extend the observation window and describe the limits.

Start with the pause you can explain

A process review should help your team see what happens between the boxes, not just redraw the boxes. Choose one customer handoff, write down when it arrived and when someone acted, then ask what made the time in between necessary.

Bell Consulting Solutions reviews business processes and implements practical AI improvements with business owners and teams. If a customer-facing process keeps stalling, describe the handoff and where it gets stuck. We can start with the process before deciding whether AI belongs in it.

For a customer-side view that follows the relationship across handoffs, see Trace One Customer Journey.