Verified against ChatGPT · 2026-08-11
Summarize a long ticket thread for handoff without losing the one detail that matters
Condenses a long, messy support ticket thread into a short handoff summary built around what the next agent actually needs to act, instead of a chronological recap that makes them re-read the whole thing anyway.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are summarizing a long support ticket thread so it can be handed off to another agent, team, or shift — the summary needs to let them act immediately without opening the full thread. FULL TICKET THREAD 14-message thread over 5 days: customer reported a billing error, first agent asked for account details, second agent (after shift change) asked for the same details again, customer got frustrated, third agent identified the cause but had to leave shift before applying the fix. WHY THIS IS BEING HANDED OFF Shift change — outgoing agent identified the cause but the fix requires a permission level only the next shift's senior agent has. WHAT THE NEXT AGENT NEEDS TO DECIDE OR DO Apply the manual billing correction (already identified, just needs applying) and confirm the corrected amount with the customer. ANY COMMITMENTS ALREADY MADE TO THE CUSTOMER Second agent told the customer 'this will be resolved by end of day' — that deadline is today. HOW TO SUMMARIZE Do not write this as a chronological play-by-play of every message exchanged — write it backward from what the next agent needs to do, then include only the history that's relevant to that decision. State any commitment already made to the customer explicitly and prominently, even if it's just one line buried in message 6 of 14 — a promised refund, callback, or timeline that gets missed because it wasn't surfaced in the handoff is a broken promise the next agent didn't know they were making. Note the customer's current emotional state and how many times they've had to repeat themselves, if the thread shows escalating frustration — this changes how the next agent should open their reply. If something was tried and explicitly did not work, say so clearly so it isn't suggested again. Keep the summary itself short enough to read in under 30 seconds; anything that needs more context than that should be a link back to the specific message in the thread, not pasted in full. WHAT NOT TO DO Do not omit a commitment or promise made to the customer, even an informal one, for the sake of brevity — that's the one category of detail this summary must never drop. Do not editorialize about whether the customer's request is reasonable; state facts and status, not opinions about the case. OUTPUT FORMAT 1. One-line status (where this stands right now). 2. Commitments already made to the customer (bulleted, even if just one). 3. What's already been tried and ruled out. 4. What the next agent needs to decide or do, per Apply the manual billing correction (already identified, just needs applying) and confirm the corrected amount with the customer.. 5. Customer state note, if relevant (e.g., "third contact on this issue, growing frustrated").
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Asked to summarize a long thread without further direction, GPT-5.1 defaults to a chronological recap because that's the structurally safest and most common shape for summarization — it mirrors the input's own order and requires the least reorganization of the source material, but a chronological recap forces the next agent to mentally reconstruct "so what do I actually do now" themselves, which defeats the point of summarizing at all. Building the summary backward from the required next action inverts that default, and it's a meaningfully different cognitive task for the model — it has to identify what in the history is causally relevant to the decision ahead rather than just compressing everything proportionally, which is why explicitly stating {{next_action_needed}} changes the output structure rather than just its length. The instruction to surface any customer commitment prominently regardless of where it appeared in the thread addresses a real and costly failure mode: a promise buried in message 6 of 14 is exactly the kind of detail a proportional, evenly-weighted summary would compress down to a fragment or drop, and a missed "resolved by end of day" promise is the single most damaging thing that can happen in a shift handoff, since it converts an internal process gap into a broken promise the customer directly experiences. Noting escalating customer frustration and repeat-contact count matters because it changes how the next agent should open their reply — a fourth message on the same issue needs an opening line acknowledging the repetition, not a fresh "Hi, thanks for reaching out" that reads as if nobody looked at the account history, and GPT-5.1 has no way to surface that signal unless the summary format explicitly asks for it.
What you get back
Status: Cause identified (billing system double-charged due to a plan-change timing bug); fix ready to apply, awaiting agent with billing-correction permissions. Commitments made: Told customer "resolved by end of day" — that deadline is today. Already tried/ruled out: Not a duplicate-payment-method issue; confirmed single card, single charge event duplicated on our end. Next action: Apply the manual billing correction (details in message 11) and confirm the corrected total with the customer before end of day. Customer state: Third message on this issue after being asked to re-provide account details once already — open without asking for anything already given.
Verified against
ChatGPT GPT-5.1 · 2026-08-11
Changelog
- 2026-08-11 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
