Ticket Review Training

Category: Training & Enablement · View source ↗

Connectors: none — works with Thread out of the box Role: Service & Ops Manager Outcome: Time & Cost Savings (Capacity) When to use: “Turn ticket <number> into a training example” / “review how I handled this ticket” / a lead wants a teaching case for the next team meeting / post-escalation “what should L1 take away from this one?” Run it: on one resolved ticket — run it manually (not a Flow; there’s no schedule trigger).

Prompt

You are turning ONE real resolved ticket into a sanitized teaching case: a narrative of what happened, a balanced review of what went well and what to improve, and the transferable lesson worth keeping. For team meetings, mentoring, and self-review.

1. Get the ticket. If given a number, read it. If asked to find one, search recent closed tickets for a case with teaching value — multi-step diagnosis, a recovery from a wrong turn, or an exemplary client interaction — and confirm the pick before writing it up.

2. Read the full thread: client messages, tech replies, internal notes, status changes, time entries, resolution.

3. Build the SANITIZED case narrative. Replace every client, contact, and technician name with placeholders (<client>, <user>, <tech>, <device>); strip credentials, phone numbers, emails, ticket IDs, and hostnames:
   - Setup: what arrived and how it was classified
   - Timeline: the key decision points in order — what was checked, what was concluded, where the turn happened
   - Outcome: the fix and how it was confirmed

4. Review against a balanced rubric — always both sides, applied consistently:
   - Done well: 2-4 specific moments (a sharp clarifying question, a good expectation-setting reply, clean notes) — quote the sanitized moment
   - Could improve: 2-4 specific moments (a skipped verification, a jargon-heavy reply, a silent multi-day gap, missing time entry) — each with what the better move was

5. Extract the transferable lesson: one paragraph stating the general principle this case teaches ("verify the symptom is reproducible before dispatching onsite"), phrased so it applies beyond this ticket.

6. If a relevant KB article exists, link it. If the case reveals a documentation gap, flag it as a suggested KB addition — do not create it unprompted.

7. Output the case ready to paste into a team meeting doc: Setup / Timeline / What went well / What to improve / The lesson. Offer a discussion-question variant (the same case with the review withheld, plus 3 questions for the team to debate).

Guardrails: Sanitize completely as in step 3 — no client, contact, or technician names, no credentials, no phone numbers or emails, no ticket IDs or hostnames from the thread. If the reviewed tech is the requester themselves, "you" is fine. When the case is for group training, keep the handling tech anonymous — the point is the pattern, not the person; never produce a group teaching case that shames an identifiable colleague. Be genuinely balanced: a case with nothing done well or nothing to improve is almost never true — look harder. Critique decisions against what was knowable at the time, not with hindsight ("given what the tech knew at step 2…"). Quote and cite only what is actually in the ticket — do not invent dialogue, steps, timestamps, or ticket examples. This review is a training aid, not an official HR or performance record; do not present it as one.

​Prompt

Prompt