# 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. Parent: [Writing and Documentation](https://llms-explorer.com/tree/writing-and-documentation/) · 19 facets · 72 facts · page: https://llms-explorer.com/tree/support-ticket-writing/ ## 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](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#support-ticket-writing) ## 1. The first response is a contract, not a status report - A strong first response always contains four moves, in this order: — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#1-the-first-response-is-a-contract-not-a-status-report) - Acknowledge - name the problem in the customer's own words. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#1-the-first-response-is-a-contract-not-a-status-report) - Empathize - name the impact ("I can see how this would block your release"), not a generic "I understand." — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#1-the-first-response-is-a-contract-not-a-status-report) - Commit - state what you will do next and when you will be back. A timestamp or interval. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#1-the-first-response-is-a-contract-not-a-status-report) - Ask only what you need - batch diagnostic questions; never trickle. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#1-the-first-response-is-a-contract-not-a-status-report) ## 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](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#2-the-i-hear-you-plus-concrete-next-step-pattern) - Strong: > 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](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#2-the-i-hear-you-plus-concrete-next-step-pattern) - 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](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#2-the-i-hear-you-plus-concrete-next-step-pattern) ## 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](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#3-apology-calibration) ## 4. Holding-statement patterns - A holding statement: — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#4-holding-statement-patterns) - > "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](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#4-holding-statement-patterns) - The cardinal rule: never send a holding statement without a next time-boundary. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#4-holding-statement-patterns) ## 6. Escalation handoff prose: the warm handoff - Outgoing owner writes: > "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](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#6-escalation-handoff-prose-the-warm-handoff) - Incoming owner writes within the promised window: > "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](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#6-escalation-handoff-prose-the-warm-handoff) - Anti-pattern: the incoming owner asks the customer to "summarize what's been happening." — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#6-escalation-handoff-prose-the-warm-handoff) ## 7. Phone-the-customer vs ticket-only - Call the customer when: — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#7-phone-the-customer-vs-ticket-only) - The case has crossed a sentiment threshold (all-caps, profanity, threats to escalate). — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#7-phone-the-customer-vs-ticket-only) - More than three back-and-forth cycles have occurred without progress. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#7-phone-the-customer-vs-ticket-only) - The customer is in an active incident. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#7-phone-the-customer-vs-ticket-only) - The next step requires real-time troubleshooting. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#7-phone-the-customer-vs-ticket-only) - You're about to escalate up a tier. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#7-phone-the-customer-vs-ticket-only) - Stay on the ticket when: — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#7-phone-the-customer-vs-ticket-only) - The technical context benefits from being written. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#7-phone-the-customer-vs-ticket-only) - Multiple stakeholders need to read the same answer. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#7-phone-the-customer-vs-ticket-only) - **After a phone call, always post a summary on the ticket.** — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#7-phone-the-customer-vs-ticket-only) ## 9. The five things to never write - "Please be patient." Direct command to a person who is out of patience. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#9-the-five-things-to-never-write) - "We apologize for any inconvenience this may have caused." Disbelief plus minimization. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#9-the-five-things-to-never-write) - "Per my last email..." Reads as scolding. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#9-the-five-things-to-never-write) - "Unfortunately..." Lead with the news instead. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#9-the-five-things-to-never-write) - "This is a known issue." Without immediately following it with the workaround, the timeline for a fix, and an apology. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#9-the-five-things-to-never-write) ## First response on a SEV1 - > Hi [Name], > > 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. > > Here's what I'm doing in parallel right now: > - Pulling the cluster's recent logs and FTDC. > - Checking the Atlas control-plane status for [region]. > > 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](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#first-response-on-a-sev1) ## Anti-Patterns - Generic "I understand" - use a specific empathy beat instead. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#anti-patterns) - Time-vague commitments - "soon," "shortly," "ASAP." Use clock time in a named timezone. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#anti-patterns) - Trickle diagnostics - asking for one piece of data, waiting, then asking for another. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#anti-patterns) - Closing without recap - no description of cause or fix. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#anti-patterns) - Cold handoff - "I've assigned this to a colleague" with no name, no warm intro. — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#anti-patterns) ## References - GigaBPO: Customer Service De-escalation Techniques and the HEARD Method — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#references) - Supportbench: Customer Update Cadence for Incidents — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#references) - Fullview: How To Write a Great Closing Support Ticket Email — [source](https://llms-explorer.com/sources/mdb-context-hub/support-ticket-writing/#references) ## Where this helps - Writing the first response on a newly opened ticket, where acknowledging the problem in the customer's own words and stating a concrete next step matters more than a polished status report. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - De-escalating a frustrated or angry customer by pairing acknowledgment of their feeling with a concrete next step, rather than leaning on either half alone. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Sending a holding statement on a still-open investigation, where the cardinal rule is never sending one without a next time-boundary attached. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Writing a warm handoff when escalating a case to a specialist, so the incoming owner doesn't ask the customer to re-explain what's already been established. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## How to apply this - Structure every first response as four moves in order: acknowledge the problem in the customer's own words, empathize with the specific impact, state what you're doing, and give a concrete next step or timeframe. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Replace generic empathy phrases ("I understand") with a specific one tied to the actual impact ("I can see how this would block your release") — specificity is what makes the acknowledgment land. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Decide phone vs ticket-only using concrete triggers: a sentiment threshold being crossed (all-caps, profanity, threats to escalate), or more than three back-and-forth cycles without progress. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - On an escalation, have the outgoing owner state what's already been ruled out and shared, so the incoming owner's opener demonstrates they've read the case rather than asking the customer to repeat themselves. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## Common mistakes - Defaulting to "I understand" instead of naming the specific impact the customer described — the phrase is so overused it reads as insincere. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Making time-vague commitments ("soon," "shortly," "ASAP") instead of a clock time in a named timezone. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Trickle diagnostics — asking for one piece of data, waiting for it, then asking for the next, instead of requesting everything needed up front. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Sending a holding statement with no next time-boundary, leaving the customer with no sense of when to expect the next update. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## Limitations - These patterns describe how to write well once the diagnostic and resolution work is already happening; they don't substitute for actually making progress on the underlying issue. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - The apology-calibration guidance — never write "we apologize for any inconvenience this may have caused" — is about avoiding a specific detested phrase, not a blanket rule against apologizing when a real mistake was made. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Escalation handoff quality depends on the outgoing owner actually having captured full context (the timeline, what's been ruled out); the warm-handoff pattern can't compensate for a case that was poorly documented before the handoff. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - The phone-vs-ticket decision triggers (sentiment threshold, cycle count) are heuristics, not hard rules — a case can warrant a call for reasons the triggers don't capture, and vice versa. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## Where this helps - Writing the first response on a newly opened ticket, where acknowledging the problem in the customer's own words and stating a concrete next step matters more than a polished status report. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - De-escalating a frustrated or angry customer by pairing acknowledgment of their feeling with a concrete next step, rather than leaning on either half alone. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Sending a holding statement on a still-open investigation, where the cardinal rule is never sending one without a next time-boundary attached. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Writing a warm handoff when escalating a case to a specialist, so the incoming owner doesn't ask the customer to re-explain what's already been established. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## How to apply this - Structure every first response as four moves in order: acknowledge the problem in the customer's own words, empathize with the specific impact, state what you're doing, and give a concrete next step or timeframe. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Replace generic empathy phrases ("I understand") with a specific one tied to the actual impact ("I can see how this would block your release") — specificity is what makes the acknowledgment land. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Decide phone vs ticket-only using concrete triggers: a sentiment threshold being crossed (all-caps, profanity, threats to escalate), or more than three back-and-forth cycles without progress. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - On an escalation, have the outgoing owner state what's already been ruled out and shared, so the incoming owner's opener demonstrates they've read the case rather than asking the customer to repeat themselves. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## Common mistakes - Defaulting to "I understand" instead of naming the specific impact the customer described — the phrase is so overused it reads as insincere. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Making time-vague commitments ("soon," "shortly," "ASAP") instead of a clock time in a named timezone. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Trickle diagnostics — asking for one piece of data, waiting for it, then asking for the next, instead of requesting everything needed up front. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Sending a holding statement with no next time-boundary, leaving the customer with no sense of when to expect the next update. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## Limitations - These patterns describe how to write well once the diagnostic and resolution work is already happening; they don't substitute for actually making progress on the underlying issue. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - The apology-calibration guidance — never write "we apologize for any inconvenience this may have caused" — is about avoiding a specific detested phrase, not a blanket rule against apologizing when a real mistake was made. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - Escalation handoff quality depends on the outgoing owner actually having captured full context (the timeline, what's been ruled out); the warm-handoff pattern can't compensate for a case that was poorly documented before the handoff. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* - The phone-vs-ticket decision triggers (sentiment threshold, cycle count) are heuristics, not hard rules — a case can warrant a call for reasons the triggers don't capture, and vice versa. — [source](https://llms-explorer.com/tree/support-ticket-writing/) *(AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.)* ## Context files - [Support Ticket Writing](https://llms-explorer.com/downloads/sources/mdb-context-hub/support-ticket-writing.md)