Class 86 followed up with people who showed interest. Class 87 serves the people who need help — and treats every request as instrumentation. A support inbox is the cheapest user-research lab you own: each message describes a gap between what you promised and what someone experienced. This lesson teaches you to read it that way.

The vocabulary, in plain language

• Request: any ask for help — email, chat, reply, call, hallway question. The channel varies; the need is the unit.
• Ticket: a request given a record — an ID, a category, an owner, a state. Unticketed requests evaporate; ticketed ones accumulate into evidence.
• Resolution: the outcome that actually fixed the need — not the reply, the fix. "Answered" is activity; "can now deploy" is resolution.
• Response time: how fast the first human (or honest) acknowledgment arrives. Speed of acknowledgment matters more than speed of full solution — silence breeds second tickets.
• Deflection: a request resolved without a human touch — the checklist, the FAQ entry, the in-product hint that answered it at 2 a.m. Good deflection is help, not avoidance.
• Escalation: passing the ticket up or across — to billing, to an engineer, to a founder — with context attached. Escalation with context is care; escalation as forwarding is abdication.
• Product signal: the pattern across tickets — the recurring friction that points at onboarding, the product, the offer, or the docs.

The mental model: each ticket is a ping from the sonar. One ping is a customer to help. Ten pings from the same direction are a map of the rock you keep hitting.

What recurrence reveals

Sort every repeat into one of four root-cause candidates:

1. Onboarding gap. "Where do I put the API key?" asked eight times in a fortnight means the setup path misleads — the fix is guidance at the moment of confusion, not eight better replies. 2. Product defect. "Deploy fails at step 4 with the same error" is the product speaking through users. Route it to the backlog with ticket IDs attached, not to a macro. 3. Unclear offer. "I thought the trial included team seats" means the promise misled. The fix is wording on the pricing page — owned by whoever wrote the claim (Lesson 86.4's rule returns). 4. Missing document. "How do I migrate from X?" asked monthly with no canonical answer means the library has a hole. One strong source-linked piece (Class 85's playbook) deflects the next ten.

ByeBuy feels this directly: three "where does the worksheet live after I close the tab?" messages in a week is an onboarding gap (add the save step to the worksheet itself); repeated "your leaderboard lesson contradicts the docs" is a content defect (correct the piece, log the change); "I thought office hours were 1:1" is an unclear offer (rewrite the invite). Same inbox, three different owners — which is why categorization precedes assignment.

Exercise: categorize ten messages

Collect ten real or realistic messages — support inbox, replies, community questions, sales-call confusions. Categorize each by immediate need and root-cause candidate.

# SUPPORT-SAMPLE-10.md — [Project] — [Date range]

| # | Message (one line) | Immediate need | Root-cause candidate | Owner |
|---|--------------------|----------------|----------------------|-------|
| 1 | ___ | answer / fix / refund / guidance / reassurance | onboarding / defect / offer / docs / one-off | ___ |
| … | (through 10) | | | |

## Pattern read (three lines)
- Most repeated candidate: ___ (___ of 10)
- Strongest single signal: ___ ("___" × ___)
- First fix worth making: ___ (owned by ___, deflects ~___ future tickets)

Worked mini-example — local booking service, ten messages: four "is Saturday still free?" (immediate need: answer; candidate: onboarding — no live availability shown), three "the confirmation link expired" (defect — 24-hour token too short), two "does the quote include cleanup?" (offer — package wording vague), one genuine one-off. Pattern read: availability display first (four of ten, owned by the builder, deflects ~15 tickets a month), token lifetime second. Two fixes retire most of the inbox.

Finish line: ten messages categorized with immediate need, root-cause candidate, and owner — plus a three-line pattern read naming the first fix.

Verify quickly: for your top candidate, check: do at least three messages point the same way? If yes, you have a signal. If every message points somewhere different, collect ten more before proposing surgery.

Common failure mode: the polite treadmill — answering each ticket warmly, individually, forever, while the same question arrives weekly. Kindness without categorization is how inboxes grow and products stall. Answer the person; ticket the pattern.

Check your understanding

1. What is the difference between a resolution and a reply? Why does response time still matter? 2. Name the four root-cause candidates and give one example question for each. 3. Why must a ticket exist as a record — what is lost when requests stay as chat memory?

Next

You can read the inbox as a sensor. Lesson 87.2 builds the layer that acts on the reading — an AI support triage loop that classifies, retrieves approved knowledge, drafts, resolves or routes, and records — with clear handoff lines a machine must never cross.