Service Diagnosis
Core principle: Diagnosis without measurement is opinion. Measurement without aim is vanity. Every improvement must state what gets better, for whom, and how you'd know.
Prerequisite
This skill reads an existing blueprint. Run service-design:service-blueprint first. The blueprint's lanes, moments of truth, and failure modes are the raw material for diagnosis.
Identify Fail Points
Mark fail points on the blueprint. For each, trace root cause across five categories:
| Category | What it catches |
|---|---|
| Policy | Rules that force bad outcomes — approval gates, eligibility traps, rigid scripts |
| Training | Staff lack knowledge or confidence to handle the scenario |
| System | Technical failures — downtime, latency, missing integrations |
| Handoff | Drops between teams, channels, or stages — no owner, no signal |
| Incentive | Metrics that reward behavior misaligned with customer outcomes |
Surface redundancies (duplicate work, conflicting ownership) and capacity constraints (queues, wait times, batching). These are structural — they won't appear in individual complaint data.
Anchor Measures to Lanes
Map measures directly onto blueprint lanes. Measures that float free of lanes measure nothing actionable.
| Lane | Measures |
|---|---|
| Customer outcomes | Task success rate, time-to-value, perceived clarity |
| Frontline outcomes | Handle time, rework rate, escalation rate |
| System outcomes | Latency, defect rate, policy exception frequency |
State current and target for each. If current is unknown, tag [gap] — that gap is itself a finding.
Design PDSA Tests
For each top fail point, design a test: aim (what this proves), change (smallest safe experiment), measure (signal of success), expected outcome (prediction), risk/guardrail (stop condition), decision rule (scale if X, revert if Y). Small scale — one segment, one workflow, one week. Avoid big-bang rollouts.
Value Stream Mapping
When operational bottlenecks dominate — queues, rework, long lead times — diagram material and information flows end to end. Separate value-creating steps from waste (waiting, transport, overprocessing, duplication). The blueprint provides structure; the value stream map provides timing.
SERVQUAL Lens
Optional but powerful. Score the service against five dimensions:
| Dimension | Question |
|---|---|
| Tangibles | Does the physical/digital evidence signal quality? |
| Reliability | Does the service deliver what it promised? |
| Responsiveness | Does the org act willing and fast? |
| Assurance | Do actors trust the service's competence? |
| Empathy | Does the service treat the person as individual? |
Map gaps to blueprint lanes. A reliability gap traced to a backstage handoff is actionable. A reliability gap floating in the abstract is not.
Confidence Discipline
Tag every claim: [confirmed] (verified in code, data, or docs), [hypothesis] (inferred from patterns), or [gap] (unknown). For each hypothesis, note what would confirm or refute it.
Output
Write to docs/service-design/<slice>/diagnosis.md using the template at service-design/templates/diagnosis.md. Populate the Aim Statement, Fail Points, Redundancies, Capacity Constraints, Lane-Anchored Measures, PDSA Tests, and SERVQUAL Assessment sections.