Process Analysis and Improvement Questions

Using the metrics together

I would track all four because each answers a different question.

• Cycle time shows how long active work takes once it starts.
• Lead time shows the customer’s total wait from request to completion.
• Throughput shows how much work the system finishes in a period.
• First-pass yield shows how often work is completed without rework.

Used together, they tell a much better story than any single metric. For example, if throughput is stable but lead time is rising, the problem is usually queueing or batching. If cycle time is low but first-pass yield is poor, the team may be moving quickly but creating rework. If throughput rises while lead time stays flat, demand may also be rising.

Worked example

Take a support-ticket queue with these two snapshots:

Cycle time, throughput, and first-pass yield are unchanged between the two weeks: agents are working just as fast, closing the same volume, and getting it right the first time just as often. The only number that moved is lead time, which nearly tripled from 6 to 14 hours. That gap between lead time and cycle time (12 hours of pure waiting in week 5, versus 4 hours in week 1) is the signature of a queueing problem: tickets are piling up before anyone starts them, most likely because intake volume briefly exceeded agent capacity or a triage step is batching tickets before routing them. The fix is adding intake capacity or shrinking the batch size, not asking agents to work faster or auditing their quality, since neither cycle time nor first-pass yield shows a problem.

Contrast that with a second scenario: cycle time and lead time both stay at 2 and 6 hours, throughput holds at 40 tickets/day, but first-pass yield drops from 90% to 70%. Nothing about speed changed, agents are still starting and finishing tickets on the same clock, but three in ten tickets now get reopened. That is a quality problem, not a queueing or capacity problem, and it points at inadequate review or unclear resolution criteria rather than staffing.

What a healthy process looks like

A healthy process has predictable throughput, short and stable cycle times, low waiting time, and high first-pass yield. I’d also watch the trend over time, because a one-week improvement can hide a broader capacity or quality problem.

Current-state analysis

I’d start by mapping the order-to-cash flow from order receipt to invoice creation, then quantify where the 12 days are spent. I’d sample real orders across different customer types and look for timestamps, rework loops, and approval waits.

Worked example: decomposing the 12 days

Timestamping a sample of 40 recent orders across receipt, entry, approval, exception handling, and invoicing gives a stage breakdown that sums to the given 12-day average: order entry and validation, 2 days; the approval chain (every order routes through the same sequential sign-offs regardless of size or risk), 5 days; exception handling and data cleanup before an order can be invoiced, 3 days; invoice generation itself, 2 days (2 + 5 + 3 + 2 = 12 days). Layered on top of the stage totals, 35% of the sampled orders bounce back to entry for missing or incorrect data (a PO number, a tax code, a pricing mismatch), and each bounce adds roughly 4 more days re-doing entry and re-approval, which is why individual orders run well past the 12-day mean even though the four stage totals already account for it.

Top root causes, committed to this scenario's numbers

Ranking causes by how many of the 12 days they actually hold, not by opinion: (1) the single-track sequential approval chain, 5 of 12 days (42%), and the stage rework loops re-enter after a bounce, so fixing it also shortens every reworked order; (2) incomplete or inaccurate order entry, which does not carry its own stage total but drives the 35% rework rate; (3) exception handling and data cleanup blocking invoicing, 3 of 12 days (25%), traceable to the same missing-data problem surfacing one stage later. A Pareto view built from a larger sample would refine these percentages, but the sampled 40 orders already point at the approval chain as the single biggest lever, not an unranked "mix of" possibilities.

Future state

Quick win: add order validation rules at intake (reject an order missing a PO number, tax code, or price match before it starts the approval clock) and a standard checklist for high-risk orders, targeting root cause #2. If that cuts the rework rate from 35% to 15%, the eliminated 20 percentage points of rework, each worth about 4 days, removes roughly 0.20 x 4 = 0.8 days from the 12-day average immediately, with no new tooling.

Longer-term: replace the single-track approval chain with a risk-tiered approval matrix that delegates sign-off to one approver for low-risk orders (roughly 70% of volume) instead of routing everything through the full sequential chain, cutting their approval time from 5 days to 2, while the remaining 30% (genuinely high-risk orders) still take the full 5-day chain. Blended approval time becomes 0.7 x 2 + 0.3 x 5 = 1.4 + 1.5 = 2.9 days, down from 5, a savings of about 2.1 days. Automating the entry-to-approval and approval-to-invoicing handoffs, plus a shared order-status/SLA-aging dashboard, address root cause #3 (exception handling) next, once the first two changes are proven.

Combined, the quick win and the approval-matrix change alone bring the projected average from 12 days toward roughly 12 - 0.8 - 2.1 = 9.1 days, about a 24% cut, before the exception-handling root cause is even addressed.

Measures of success

I’d track average order-to-invoice time, rework rate, approval wait time, invoice defects, and customer complaints. The future state is successful if it shortens cycle time without increasing errors or pushing work into another team.

Reconcile the versions

I would not pick a version immediately. I’d treat this as a data-confidence problem and build a short evidence trail.

• Interview both stakeholders separately to understand what each is actually describing, including exceptions.
• Pull timestamped system data, tickets, logs, or approvals to anchor the map in facts.
• Compare the two narratives against the artifacts and mark every step as confirmed, inferred, or unknown.
• If timestamps are inconsistent, I’d check whether the issue is system latency, manual entry, or missing events.

Validate the current state

I’d run a quick walk-through of recent real cases end to end, ideally with someone who executed the work. That helps expose handoffs that people forget to mention. I’d also sample enough cases to see whether the process is stable or varies by customer, region, or request type.

Prevent incomplete decisions

I’d create a versioned current-state map with a confidence level and an explicit assumptions log. Then I’d tell the team not to make redesign decisions until the map has been validated by evidence and signed off by the main process owners.

Worked example

Take a returns-handling process as the concrete case. Operations says a return is "handed off" to Support the moment the RMA (return merchandise authorization) status flips to "Approved" in the warehouse system; Support says the handoff happens when the customer replies to the automated approval email with a tracking number. For one real case (case #4821), the warehouse system logs the RMA status change at 2:14pm, but Support's ticket system shows the case entering their queue at 4:40pm: a 2-hour-26-minute gap with no logged event in between.

Interviewing both sides and checking the artifacts gives a short, confidence-tagged map for that step:

• RMA approved in warehouse system: confirmed (system timestamp 2:14pm).
• Customer notified by automated email: confirmed (email-send log, 2:16pm).
• Customer replies with tracking number, triggering Support's intake: inferred (Support says this is what starts their process, but no reply timestamp is captured anywhere).
• Ticket enters Support's queue: confirmed (ticket-system timestamp 4:40pm), but the 2h26m gap between the email send and the ticket's appearance is unknown: neither system logs the customer's reply time, so nobody can currently say whether the delay is customer response time, an email-delivery lag, or an unlogged manual step Support performs before creating the ticket.

Before treating that map as settled, I'd sample at least 15-20 recent cases across a couple of customer segments, not just this one case, since a single instance could be an outlier; the goal is a stable pattern (for example, "this unknown gap shows up in 18 of 20 sampled cases") rather than a one-off. The versioned map would carry that confidence level per step and an assumptions-log entry for the unresolved gap, so anyone using the map later can see exactly what is proven versus assumed instead of treating the whole map as equally solid.

How I’d build the map

I would start by splitting onboarding into customer segments, because “the same process” usually hides branches. Then I’d collect actual cases from sales, operations, and finance and build a swimlane view showing each handoff, decision point, and exception.

Evidence over assumptions

• Review completed onboarding files, emails, and system timestamps.
• Shadow a few live cases from start to finish.
• Compare simple vs. complex customers to see where the path changes.
• Maintain an assumptions log for anything not directly observed.

I’d pay close attention to where information changes hands, where approval is required, and where work pauses waiting for clarification. Those are often the real sources of delay.

A worked finding that disproves “one path” (illustrative)

Splitting by segment and pulling real timestamps is what actually surfaces the branches. For a small-business self-serve deal, the sales-to-operations handoff, sales marking the deal closed-won to operations starting provisioning, shows an average gap of about 4 hours in the CRM timestamps. For an enterprise deal with custom contract terms, the same handoff shows an average gap of 6 business days, because legal review and a custom statement of work sit in between that “it’s basically the same process” never mentions. Comparing a sample of 20 recent enterprise closes against 20 recent self-serve closes this way is what disproves the team’s claim: the self-serve path has one handoff and one owner, the enterprise path has three additional handoffs (legal, finance for custom billing terms, and a dedicated onboarding manager) that never show up if you only interview the team lead about “the” onboarding process.

Validation

Once the draft map is ready, I’d walk it back to the people who do the work and ask them to challenge it with recent examples. If the team says it is all one path, the data usually reveals the exceptions, exactly the 4-hour-versus-6-day gap above. The goal is a current-state map that reflects how work actually moves, not how people think it should move.

How I’d diagnose it

I would separate the problem into three questions: where work is waiting, where work is actually being done, and where work is being handed off.

• First, I’d map the queue at each stage: backlog size, aging, and SLA breach points.
• Then I’d compare wait time to active processing time. Long waits with short touch time usually mean a bottleneck in queueing, not execution.
• I’d look for one stage with a growing queue while others report being “busy.” That often means the constraint is upstream or at a handoff.

Worked example. Say the flow runs Team A -> Team B -> Team C, with a 3-business-day SLA end to end. Pulling two weeks of timestamped status history for 50 cases shows: Team A's queue holds steady around 15 items with active handling time flat at 20 minutes/item; Team B's queue grows from 20 items to 80 items over the same two weeks while its active handling time stays flat at 15 minutes/item; Team C's queue holds steady around 10 items with handling time flat at 25 minutes/item. Team B says it is waiting on Team A, but Team A's own queue and handling time are both flat, so nothing in Team A's data supports that claim. What the data actually shows is Team B's own queue growing while Team B's per-case work hasn't gotten any slower, which means cases are arriving at Team B faster than Team B can clear them: a capacity constraint at Team B itself, not an upstream dependency. Of the 50 sampled cases, the ones that breach the 3-day SLA are the ones that sat in Team B's growing queue for 2 or more of those 3 days, confirming Team B, not Team A or Team C, as where the fix belongs.

Data I need first

The first data I’d ask for is timestamped status history for a sample of cases: created, started, paused, waiting on another team, completed. That tells me whether the delay is due to capacity, approvals, dependencies, or rework.

How I’d decide

If the queue is growing before a step, the bottleneck is likely there even if that team says it is waiting on someone else. If processing time is high but queue time is low, the issue is execution efficiency or quality. I’d use both views together so I don’t confuse busy teams with constrained systems.