Lessons 87.1–87.4 built the relationship system: the inbox reads as a sensor, triage handles it safely, the CRM remembers, lifecycle messages arrive and stop on time. One move remains — the one most teams skip. Take the recurring evidence and change the product and the docs, so the ticket never arrives again. Support that only answers is a cost center. Support that teaches the operation is an engine.

The loop, end to end

evidence → backlog + docs → ship + publish → fewer tickets

Evidence. Start from the Lesson 87.1 pattern read and the triage records (Lesson 87.2): the question asked five-plus times, with ticket IDs, quotes, and the root-cause candidate. Evidence is counted, dated, and linked — not "users seem confused about…"

Backlog. Convert the evidence into one product item with an owner: the defect to fix, the onboarding step to clarify, the offer wording to correct. Attach the ticket IDs so the engineer sees humans, not abstractions. Prioritize by ticket volume × severity — the export bug hitting paying teams outranks the cosmetic confusion hitting triallists.

Docs. In parallel, write or fix the canonical content (Class 85's playbook): the FAQ entry, the guide section, the checklist step — source-linked, dated, wired into the triage layer's approved knowledge (Lesson 87.2) so the next identical question drafts from the new answer. Product fix without docs leaves the confused searching; docs without the fix institutionalize the workaround.

Fewer tickets. Measure the same question's arrival rate before and after, over the same length of time. "Export-missing-rows: 11 tickets in the 30 days before, 2 in the 30 days after" is proof. "Feels quieter" is not. Log the result in the decision log (Lesson 86.5's habit, applied to support) and close the loop by telling the affected customers: "you reported this — it is fixed, here is the note." That reply converts complainants into loyalists more reliably than any campaign.

Run the loop on a cadence: monthly, the support owner brings the top three repeats, the product owner accepts or declines each with a reason, the content owner drafts the doc change, and all three review the previous month's proof. Small, regular, undeniable. Over a year, twelve loops retire most of the avoidable inbox — and each retirement frees the triage layer and the humans behind it for the novel problems that actually need judgment.

Exercise: close one loop completely

Pick the single most repeated question from your Lesson 87.1 sample. Take it all the way through — change, update, proof.

# CLOSE-THE-LOOP.md — [Question, e.g. "Export is missing rows"]

## Evidence
- Asked ___× in ___ days (ticket IDs: ___) / representative quote: "___"
- Root-cause candidate (87.1): ___ / triage category (87.2): ___

## Product change
- Backlog item: ___ / owner ___ / shipped date ___ (or declined because ___)
- What changed for the user: ___ (one sentence)

## Content update
- Piece written/fixed: ___ (link) / wired into approved knowledge: yes/no / owner ___
- Lifecycle/triage reference updated: ___ (which flow now points at it)

## Proof
- Before: ___ tickets / 30 days → After: ___ tickets / 30 days (same window)
- Customers told (who + message): ___
- Decision log entry (date + next repeat to attack): ___

Worked mini-example — ByeBuy: "where does the worksheet live after I close the tab?" asked 9× in three weeks (onboarding gap). Product change: the worksheet autosaves with a visible "saved — resume here" link, shipped by the builder in one afternoon. Content update: the worksheet's first step rewritten plus a 60-second "resume your work" note linked from the welcome email; triage approved-knowledge updated. Proof: 9 tickets in 21 days → 1 in the next 21. Reporters got the fix note; two replied with thanks, one booked a walkthrough. Next repeat queued: the leaderboard-lesson contradiction.

Finish line: one CLOSE-THE-LOOP.md with evidence, a shipped change (or a reasoned decline), a published update, before/after ticket counts, and customers told.

Verify quickly: three checks — can a stranger find the new doc answer in under a minute? Does triage draft from it? Did the ticket count actually fall over equal windows? If any answer is no, the loop is open — name which station failed.

Common failure mode: the answer-only loop — great replies, zero backlog items, docs frozen, same questions forever, team proud of response times while the product stands still. Response time is courtesy; fewer tickets is progress. Run the monthly review until the proof becomes routine.

Check your understanding

1. What are the four stations of the close-the-loop flow, and what does each produce? 2. Why must the product fix and the docs update ship together? What breaks when only one ships? 3. What counts as proof of improvement — and why must the windows before and after match?

Next

Part XVI's middle closes here. You can turn demand signals into follow-up (Class 86) and turn support into memory and improvement (Class 87). Class 88 connects the machinery itself — webhooks, platforms, permissions, exceptions, and the measured review that decides what automation deserves to grow.