# Lesson 4 practice: Turn “slow resolution” into specific waits

[中文](README.md)

Open [waiting.csv](waiting.csv). Decide which waiting stage deserves investigation and explain what the data cannot establish. These 20 rows match the introductory Beichen JSON by `event_id`. Expert wait and resolution time are retained from that dataset. Search waits, approval waits, and segment coordinates are **new synthetic assumptions**, not recovered real logs or evidence that those fields existed in the original case.

## Fields

| Field | Meaning |
| --- | --- |
| `source_type` | `intro_linked_synthetic_extension`: a synthetic extension linked to introductory records |
| `event_id` | Matching introductory event ID |
| `search_start_min` / `search_end_min` | Search-wait start and end coordinates, in minutes |
| `expert_start_min` / `expert_end_min` | Expert-wait start and end coordinates |
| `approval_start_min` / `approval_end_min` | Approval-wait start and end coordinates |
| `search_wait_min` / `expert_wait_min` / `approval_wait_min` | Duration of each waiting segment |
| `total_wait_min` | Sum of the three waits |
| `resolution_min` | Whole-task duration, including waits and other work |

Coordinates start at minute zero for each task. This extension deliberately makes search, expert, and approval waits sequential and non-overlapping. Real work can overlap or loop, so simple addition may be inappropriate. A zero indicates no wait in that synthetic segment, not a proven absence of a real bottleneck.

## Calculate and interpret

1. Check each segment’s `end − start = wait`, the sum of segments, and whether total wait fits within resolution time. Find the longest wait and write a question to investigate. Duration does not diagnose equipment.
2. Sum the columns: search **140**, expert **367**, and approval **200**, totaling **707 minutes**. Their shares of waiting time are about **19.8% / 51.9% / 28.3%**. The denominator is waiting minutes across all rows, not 20 tasks or total resolution time.
3. Resolution totals **1,753 minutes**, averaging **87.65 minutes**. The ratio 707 / 1,753 ≈ **40.3%** is waiting time as a share of resolution time in this extension, not approval’s share. Approval represents 200 / 707 ≈ **28.3%** of waiting time.
4. Write two competing explanations, such as limited expert capacity or incomplete initial information causing repeated clarification. List evidence that could distinguish them. The longest stage is not necessarily the easiest to change or the best candidate for AI.
5. Propose the next step and a stopping condition: what to record, how to compare information and process improvements, and what evidence would support keeping or changing the plan. Mark this as a proposal, not customer approval.

## Check your reasoning

The **60%** from 12 / 20 describes tasks with expert waits, not a share of waiting minutes. E-013 has a **46-minute** expert wait in the introductory records; public event 03 separately states 42 minutes. Keep those sources separate rather than averaging or silently reconciling them. The introductory JSON has no approval segments: the added 200 minutes cannot serve as original event evidence.

Use these rows to practice denominators, segmentation, and investigation questions. They do not establish that a product will shorten resolution or achieve a 30% improvement. When studying alone, submit calculations and unanswered questions. A peer can check one denominator and one claim that exceeds the source.

In the next lesson, turn a task step into understandable states, refusal options, and human handoff paths.