Write an internal ticket handoff summary
beginnerClaude HaikuCustomer ServiceSupporthandoffinternalsupport-opsticket-management
Use case
Use this prompt when transferring a ticket between support reps, shifts, or teams. A good handoff summary eliminates the need for the customer to repeat themselves and ensures the receiving rep has full context from the first read.
The prompt
You are a senior support specialist. Write a structured internal handoff summary for the following support ticket. Ticket details: - Customer name and account:{{customer_name}},{{account_type}}- Original issue:{{original_issue}}- Full conversation history or notes:{{conversation_history}}- Current status of the issue:{{current_status}}- What has been tried:{{attempted_steps}}- What worked / what didn't:{{results}}- What is still unresolved:{{open_items}}- Who is receiving the handoff:{{receiving_team}}(e.g., engineering, billing, senior support, next shift) - Urgency:{{urgency_level}}(low / medium / high / critical) - Customer's current sentiment:{{customer_sentiment}}Write a handoff summary with these sections: **TICKET: [Issue summary in 8 words or less]** **Customer:** [Name, account tier] **Urgency:** [Level + brief rationale] **Receiving team/rep:** [Who this is going to] **Situation (2–3 sentences):** What is the customer experiencing and why does it matter? Written so a new rep can understand the full picture without reading the full thread. **What's been done:** Bullet list of every step taken, what was found, and the outcome. Specific and factual — no vague "we looked into it" language. **What's still open:** Bullet list of unresolved items, open questions, or things the receiving team needs to investigate. **Customer context:** - Current sentiment (frustrated / neutral / cooperative / threatening to churn / threatening legal action) - Any commitments made to the customer (and by when) - Anything sensitive to know before reaching out **Recommended next action:** One specific action the receiving rep should take first, with suggested language or approach if needed.
Variables
{{{{customer_name}}}}Replace with your {{customer name}}{{{{account_type}}}}Replace with your {{account type}}{{{{original_issue}}}}Replace with your {{original issue}}{{{{conversation_history}}}}Replace with your {{conversation history}}{{{{current_status}}}}Replace with your {{current status}}{{{{attempted_steps}}}}Replace with your {{attempted steps}}{{{{results}}}}Replace with your {{results}}{{{{open_items}}}}Replace with your {{open items}}{{{{receiving_team}}}}Replace with your {{receiving team}}{{{{urgency_level}}}}Replace with your {{urgency level}}{{{{customer_sentiment}}}}Replace with your {{customer sentiment}}
Example
Input
customer_name: Josephine Park, Harlow Retail Group account_type: Enterprise original_issue: Signal anomaly detection sending false positive alerts for 3 days conversation_history: | Day 1: Josephine reported false positives every 15 minutes. Rep adjusted alert sensitivity threshold — no change. Day 2: Rep cleared cache, confirmed data source updating normally. Issue persisted. Josephine said team was "losing trust in the feature." Day 3: Josephine emailed again saying team has now disabled Signal entirely. Expressed concern about value of Enterprise upgrade. current_status: issue unresolved; Signal disabled by customer; requires engineering investigation attempted_steps: adjusted alert sensitivity, cleared cache, confirmed data source health results: all tier-1 interventions tried without resolution; data source is healthy; issue appears to be in alert logic, not data open_items: root cause of false positive alert logic; engineering investigation pending; CSM not yet looped in receiving_team: engineering (and CC to CSM team) urgency_level: high customer_sentiment: very frustrated; mentioned Enterprise upgrade value; has disabled the feature; renews in 4 months
Output
**TICKET: Signal false positives — Enterprise customer disabled feature** **Customer:** Josephine Park, Harlow Retail Group (Enterprise) **Urgency:** HIGH — core feature disabled for 3 days; renewal in 4 months; customer expressing doubt about Enterprise value **Receiving team:** Engineering (please CC customer success / CSM team) **Situation:** Harlow Retail Group has been receiving false positive anomaly alerts from Signal every ~15 minutes for 3 days on a metric that's performing normally. After exhausting tier-1 options, the customer's team disabled Signal entirely — which is the primary value driver for their Enterprise upgrade. This is both a technical and account risk issue. **What's been done:** - Adjusted alert sensitivity threshold (Day 1) — no change in alert frequency - Cleared cache and confirmed data source is updating normally and healthy (Day 2) — issue persisted - Confirmed the affected metric is performing within normal range — the alerts are false positives, not real anomalies **What's still open:** - Root cause of alert logic generating false positives on a healthy metric — needs engineering investigation of Signal alert rules for this account - CSM has not been looped in — needs to be aware given renewal timeline and account health - Commitment made: customer will hear back within 2 hours of escalation (today) **Customer context:** - Sentiment: very frustrated after 3 days; team has lost trust in Signal; customer raised concern about value of Enterprise upgrade - Commitments: 2-hour update promised by current rep - Sensitive: mention of Enterprise upgrade value signals potential churn risk; do not lead with troubleshooting steps in the next outreach — lead with acknowledgment and escalation status **Recommended next action:** Engineering to review Signal alert logic for Harlow's account config. CSM to send a relationship-holding email within 1 hour acknowledging the escalation: "I wanted to reach out directly — I know this has been frustrating, and our engineering team is actively investigating right now. I'll update you by [specific time]."
Tips for best results
- 1The handoff summary is for the next rep, not for the customer. Write it as if you're briefing a colleague who has zero context — because that's exactly what you're doing.
- 2The 'Recommended next action' should be specific enough that the receiving rep doesn't have to make a decision — they execute.
- 3The 'Customer context' section is where soft information lives: sentiment, relationship history, what was promised. This is what prevents the receiving rep from opening with the wrong tone.
- 4Use this prompt for every handoff between shifts or teams, not just complex issues. A consistent handoff format eliminates the 'I wasn't on that ticket' excuse.
- 5After completing a handoff, confirm with the receiving rep that they've read it — a handoff summary that isn't read is just documentation nobody uses.
Related prompts
Decide whether and how to escalate a support ticket
intermediateEvaluate a support ticket against a structured escalation framework and generate a recommended action with rationale.
Customer Serviceescalationsupport-processtriage
Draft a response to a customer support ticket
beginnerGenerate a polite, helpful, and complete first-response draft to a customer support ticket, tailored to the issue type and customer tone.
Customer Servicesupportticketresponse
Summarize a sales call into structured CRM notes
beginnerConvert raw call notes or transcript snippets into clean, structured CRM activity notes with next steps and deal intelligence.
Salescrmsales-opscall-notes
Need help implementing this prompt in your workflow?
Book a call