Support Ticket Writing
Parent: Writing and Documentation · researched 2026-05-29T18:36:16.921Z· 8 sources · 9 concepts · skill support-ticket-writing
Prose craft for the moment between "the customer hit a problem" and "the ticket is closed." Every word in that window is read by a person who is, by definition, having a worse day than they planned.
Support Ticket Writing
- Prose craft for the moment between "the customer hit a problem" and "the ticket is closed." Every word in that window is read by a person who is, by definition, having a worse day than they planned. [source]
1. The first response is a contract, not a status report
- A strong first response always contains four moves, in this order: [source]
- Acknowledge - name the problem in the customer's own words. [source]
- Empathize - name the impact ("I can see how this would block your release"), not a generic "I understand." [source]
- Commit - state what you will do next and when you will be back. A timestamp or interval. [source]
- Ask only what you need - batch diagnostic questions; never trickle. [source]
2. The "I hear you" plus concrete next step pattern
- The most reliable de-escalation move: acknowledgment of feeling, then a concrete next step. Either half alone is weaker. [source]
- > I can see how frustrating this is - your cluster has been failing over for three hours and you're heading into a maintenance window. I'm pulling the FTDC now and will reply within 30 minutes either with a root cause or with the questions I need to narrow it down. [source]
- The phrase "I understand" is overused to the point of suspicion. "That sounds really frustrating," "I can see why this is urgent" land harder because they're specific. [source]
3. Apology calibration
- Never write "we apologize for any inconvenience this may have caused." It is the most universally-detested phrase in support writing. [source]
4. Holding-statement patterns
- A holding statement: [source]
- > "Quick update: I'm still working through the logs you sent. I've ruled out network latency and am now looking at the WiredTiger cache. I'll have a clearer picture by 17:00 UTC. No action needed from you in the meantime." [source]
- The cardinal rule: never send a holding statement without a next time-boundary. [source]
6. Escalation handoff prose: the warm handoff
- Outgoing owner writes: [source]
- > "I'm bringing in [Name], who specializes in [area], to take over the deep-dive on this. They have the full context - the FTDC, the timeline, what we've ruled out so far. [Name] will reply within [time] with next steps." [source]
- Incoming owner writes within the promised window: [source]
- > "Hi [customer], [outgoing] looped me in. I've read the case and the FTDC; I see what they're describing with the failover loop. Before I dig further, can you confirm: [one or two crisp questions]." [source]
- Anti-pattern: the incoming owner asks the customer to "summarize what's been happening." [source]
7. Phone-the-customer vs ticket-only
- Call the customer when: [source]
- The case has crossed a sentiment threshold (all-caps, profanity, threats to escalate). [source]
- More than three back-and-forth cycles have occurred without progress. [source]
- The customer is in an active incident. [source]
- The next step requires real-time troubleshooting. [source]
- You're about to escalate up a tier. [source]
- Stay on the ticket when: [source]
- The technical context benefits from being written. [source]
- Multiple stakeholders need to read the same answer. [source]
- **After a phone call, always post a summary on the ticket.** [source]
9. The five things to never write
- "Please be patient." Direct command to a person who is out of patience. [source]
- "We apologize for any inconvenience this may have caused." Disbelief plus minimization. [source]
- "Per my last email..." Reads as scolding. [source]
- "Unfortunately..." Lead with the news instead. [source]
- "This is a known issue." Without immediately following it with the workaround, the timeline for a fix, and an apology. [source]
First response on a SEV1
- > I'm [Your name], picking up this case now. I can see your primary in [cluster] has been unavailable since [time], and your application has been throwing connection errors for [duration]. That's the kind of thing that should never be quiet from us, and I'm sorry you're dealing with it during business hours. [source]
- > Here's what I'm doing in parallel right now: [source]
- > - Pulling the cluster's recent logs and FTDC. [source]
- > - Checking the Atlas control-plane status for [region]. [source]
- > I'll reply by [exact time] either with a root cause hypothesis or with the specific diagnostic data I need from you. In the meantime, if the situation changes on your side - for example, the secondary takes over and you regain availability - please let me know. [source]
Anti-Patterns
- Generic "I understand" - use a specific empathy beat instead. [source]
- Time-vague commitments - "soon," "shortly," "ASAP." Use clock time in a named timezone. [source]
- Trickle diagnostics - asking for one piece of data, waiting, then asking for another. [source]
- Closing without recap - no description of cause or fix. [source]
- Cold handoff - "I've assigned this to a colleague" with no name, no warm intro. [source]
References
Children
- First-Response Templates (frontier)
- HEARD De-escalation (frontier)
- ASAP De-escalation (frontier)
- Holding Statement Patterns (frontier)
- Apology Calibration (frontier)
- Status-Update Cadence by Severity (frontier)
- Warm vs Cold Handoff (frontier)
- Phone vs Ticket Decision (frontier)
- CSAT and Closing Language (frontier)
Frontier under this node: ASAP De-escalation, Apology Calibration, CSAT and Closing Language, First-Response Templates, HEARD De-escalation, Holding Statement Patterns, Phone vs Ticket Decision, Status-Update Cadence by Severity, Warm vs Cold Handoff