Baseline≈85%
Target (to verify)≥ 90% vs senior double annotation
YUEXU AI
正在整理流程
01 / SAMPLE
After five working days, this is the document you keep.
A complete Handoff Pack from a guided diagnostic, built on a fictional mid-size equipment manufacturer: after-sales repair triage. Every company, person and number here is invented — the structure, evidence discipline and boundary design are what a real engagement delivers.
Prototype / Demo dataFictional companyStructure = real delivery
WHAT THE PACK CONTAINSA judgment your team can challenge, not a pitch it has to trust.
Business AnchorOpportunity MapData & Responsibility BoundaryValidation PathNext Step
02 / Cover
Prototype / Demo dataEngagement facts, stated up front.
| Client | Xinglan Equipment Mfg. Co. (fictional: East China, ~800 staff, industrial cleaning equipment) |
|---|---|
| Scope | After-sales repair intake and triage: from customer report to field-engineer dispatch |
| Period | 2026-08-10 to 2026-08-14, five working days |
| Participants | Sponsor (VP Ops), process owner (after-sales director), service desk lead, IT lead |
| Lead FDE | Liu Anye (YUEXU AI) |
| Verdict | Pilot — proceed to a read-only shadow validation |
03 / One-page verdict
Worth doing — but only one slice of it, and read-only first.
Four candidate opportunities were scored. A (structured intake & triage) goes to shadow validation; B waits for ERP confirmation; D is explicitly rejected. The numbers below are validation targets, not promises.
BaselineUntracked
Target (to verify)≤ 2%
Baseline25 min
Target (to verify)Est. saving ≥ 10 min/ticket
Gate result: Pilot. Two blockers found by the diagnostic itself — the data owner is unassigned, and ticket texts contain customer contact details that must be anonymized before any export.
04 / Business Anchor
Who owns the outcome, and what inaction costs.
One business result, one accountable sponsor, and a baseline measured during the diagnostic — not reconstructed after launch.
| Role | Person (fictional) | Status |
|---|---|---|
| Sponsor | VP Operations | Confirmed: judgment before budget |
| Process owner | After-sales director | Confirmed, joined the walkthrough |
| Frontline | Desk lead + 4 agents | 2 agents to annotate |
| Data owner | Unassigned (ERP/ticketing ownership unclear) | Gap: must be resolved before the pilot |
| Risk owner | After-sales director (proposed) | Pending written confirmation |
| IT | IT lead | ERP interface unassessed |
Cost of inaction: service volume grows ~15% a year with installed base while desk headcount scales linearly; night and weekend triage gaps persist. Out of scope: spare-parts supply, engineer KPIs, CSAT callback programs.
05 / Baseline
Prototype / Demo dataMeasured, not estimated.
| Metric | Value (demo) | How measured |
|---|---|---|
| Monthly tickets | 420 | System export, trailing 12 months |
| First response (business hours) | 3.2 h | System timestamps |
| Night/weekend response | Next day 9:30 | No triage coverage |
| Logging + triage per ticket | ~25 min | Measured, 60-ticket sample |
| Triage accuracy | ≈85% | Sampled retrospective review |
| First-time-fix rate | 78% | Trailing 6 months |
| Urgent share | ≈8% | Ticket type field |
06 / Current workflow
Six steps, three of them painful.
From customer report to field-engineer dispatch. Logging plus triage is 25 minutes of serial, on-duty-only work.
Customer reports by phone / WeChat / email — no single entry pointAgent logs the ticket by hand (~8 min)Check ERP serial number and warranty terms (~5 min, inconsistent judgment)Classify fault and urgency by experience, pick a skill group (~12 min)Dispatch by phone / WeChat with verbal contextEngineer calls back for missing context (~15% of tickets)
Slowest: logging + triage, 25 minError-prone: fault classificationWaiting: nights & weekends
07 / Opportunity Map
Four candidates, one clear first slice.
Scored on value, feasibility, risk and adoption — the same deterministic dimensions as the online diagnostic. Note what gets rejected, and why.
Option AFirst: shadow validation
Structured intake & triage suggestion
Extract device, symptom and urgency from the report text; suggest category and skill group
Value82
Feasibility86
Risk28
Adoption40
Option BPhase two
Warranty eligibility pre-check
Serial + contract matching; ERP interface unconfirmed
Value74
Feasibility58
Risk45
Adoption52
Option CMerged into A
Similar-ticket retrieval
Folded into A as an assist, not a standalone project
Value55
Feasibility70
Risk22
Adoption35
Option DNot now
Dispatch & routing optimization
Scheduling lives in personal experience; digitization premise does not hold
Value78
Feasibility30
Risk62
Adoption74
08 / Data & Boundary
What AI may and may not do, written down before any model runs.
AI may (shadow only)
- Extract device, symptom, urgency — from the report text
- Suggest category and skill group with confidence — suggestion, never the verdict
- Retrieve similar past tickets — for the agent to review
- Flag low confidence for a human — never guess
AI may not
- Dispatch or notify engineers — human confirms first
- Warranty eligibility verdicts — out of scope until phase two
- Send anything to the customer — zero outbound in shadow mode
- Write to ERP or mutate ticket state — read-only
Data sources: ticket texts (medium sensitivity, pending authorization), ERP serial and warranty fields (phase two), internal fault knowledge (low). Anonymization replaces customer names, contacts and addresses with IDs; a 50-ticket sample is human-reviewed; the mapping table stays with the client.
09 / Validation Path
How success gets proven — and how it gets stopped.
Read-only shadow: the AI suggests next to the existing console; agents work exactly as today. Acceptance is customer-verifiable; stop conditions have a named owner.
Offline eval (weeks 1–2)
- 300 anonymized historical tickets
- Compared against senior double annotation
Shadow run (weeks 3–4)
- Live tickets; AI suggests, never acts
- Track agreement, override rate, latency
Acceptance (customer-verifiable)
- Agreement ≥ 90%; missed-urgent ≤ 2%
- Latency ≤ 5s; no added agent burden
Stop conditions (owner can halt)
- Agreement < 75% for two weeks; missed-urgent > 5%
- Clear burden increase; any anonymization leak
10 / Next step
Recommended: proceed to a read-only shadow pilot.
Gate result Pilot: workflow fixed, owners named, baseline measured, failure modes mild and reversible. The client decides three things; then the shadow run is scheduled.
01
Assign a data owner and authorize the anonymized export of 300 tickets
02
Assign 2 senior agents for double annotation (~6 h each over two weeks)
03
Commit to the week-4 joint decision: proceed, adjust, or stop
Prototype / Demo data. Every company, person and number in this sample is fictional. Real Handoff Packs belong to the client; anonymized reuse requires separate written consent covering scope, channels and duration. This sample makes no performance or ROI claim.