Analyze how work flows from request to customer outcome
Use only information supplied in the conversation and this skill text. Do not browse, call tools, inspect files, execute code, create artifacts, or take external actions. Return the work directly in chat. Attribute material claims to supplied source labels or quotations; a pasted URL is a source label, not evidence that its contents were checked. Distinguish supplied facts, reasonable interpretations, proposals, and unknowns.
Inputs and scope: Request the process boundary, customer outcome, unit of work, stage sequence, touch and waiting times, volumes, branches, handoffs, and observation scope. Distinguish one observed case from averages over many cases. If a decision-changing input is absent, ask the smallest useful question and complete the portions supported by available material. State assumptions explicitly; do not manufacture facts, approvals, dates, or completion evidence.
Method 1. Define the start and end of the value stream and whose outcome matters. Keep the same unit of work throughout; mixing an individual request with a daily batch can distort the entire map. 2. Arrange supplied stages in sequence, showing responsible roles, inputs, outputs, queues, decisions, and return loops. Mark missing stages or uncertain order rather than implying a complete observed process. 3. Separate active processing, waiting, transit, and rework time. Normalize compatible units, note whether values are averages or case observations, and avoid adding parallel activities as though they were sequential. 4. Calculate simple end-to-end totals only when supplied timing supports them. For a sequential path, show the sum and any unknown segments; a touch-time share is meaningful only with a compatible complete denominator. 5. Identify likely flow constraints using waiting, handoffs, arrival patterns, rework, and capacity evidence. A long queue suggests a problem to investigate but does not alone prove the bottleneck's cause or that a particular control is unnecessary. 6. Propose a future-state flow hypothesis and the measurements needed to test it. Prioritize customer lead time and quality rather than local utilization; leave waste-category diagnosis to a separate analysis when that is the main question.
Output: Return a textual current-state map, timing table, bounded lead-time calculation, likely constraints with evidence, proposed flow changes, and missing observations.
Quality checks: Check units, sequence versus parallelism, incomplete paths, averages versus single cases, and double-counted rework. No process observation, code exploration, implementation, or ongoing monitoring is claimed.
Worked example: A request takes 10 minutes to enter, waits 120 minutes, receives a 20-minute review, waits 60 minutes, and takes 10 minutes to close. The supplied sequential lead time is 220 minutes, with 40 minutes of touch time and 180 of waiting. Investigate the approval queue and handoff timing before recommending faster typing; the figures do not prove all waiting can be removed.