/draft-response

name: draft-response
description: Draft a professional customer-facing response tailored to the situation and relationship. Use when answering a product question, responding to an escalation or outage, delivering bad news like a delay or won't-fix, declining a feature request, or replying to a billing issue.
argument-hint: "<situation description>"

/draft-response

> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).

Draft a professional, customer-facing response tailored to the situation, customer relationship, and communication context.

Usage

/draft-response <context about the customer question, issue, or request>

Examples:

• `/draft-response Acme Corp is asking when the new dashboard feature will ship`
• `/draft-response Customer escalation — their integration has been down for 2 days`
• `/draft-response Responding to a feature request we won't be building`
• `/draft-response Customer hit a billing error and wants a resolution ASAP`

Workflow

1. Understand the Context

Parse the user's input to determine:

• **Customer**: Who is the communication for? Look up account context if available.
• **Situation type**: Question, issue, escalation, announcement, negotiation, bad news, good news, follow-up
• **Urgency**: Is this time-sensitive? How long has the customer been waiting?
• **Channel**: Email, support ticket, chat, or other (adjust formality accordingly)
• **Relationship stage**: New customer, established, frustrated/escalated
• **Stakeholder level**: End user, manager, executive, technical, business

2. Research Context

Gather relevant background from available sources:

**~~email:**

• Previous correspondence with this customer on this topic
• Any commitments or timelines previously shared
• Tone and style of the existing thread

**~~chat:**

• Internal discussions about this customer or topic
• Any guidance from product, engineering, or leadership
• Similar situations and how they were handled

**~~CRM (if connected):**

• Account details and plan level
• Contact information and key stakeholders
• Previous escalations or sensitive issues

**~~support platform (if connected):**

• Related tickets and their resolution
• Known issues or workarounds
• SLA status and response time commitments

**~~knowledge base:**

• Official documentation or help articles to reference
• Product roadmap information (if shareable)
• Policy or process documentation

3. Generate the Draft

Produce a response tailored to the situation:

## Draft Response

**To:** [Customer contact name]
**Re:** [Subject/topic]
**Channel:** [Email / Ticket / Chat]
**Tone:** [Empathetic / Professional / Technical / Celebratory / Candid]

---

[Draft response text]

---

### Notes for You (internal — do not send)
- **Why this approach:** [Rationale for tone and content choices]
- **Things to verify:** [Any facts or commitments to confirm before sending]
- **Risk factors:** [Anything sensitive about this response]
- **Follow-up needed:** [Actions to take after sending]
- **Escalation note:** [If this should be reviewed by someone else first]

4. Run Quality Checks

Before presenting the draft, verify:

• [ ] Tone matches the situation and relationship
• [ ] No commitments beyond what's authorized
• [ ] No product roadmap details that shouldn't be shared externally
• [ ] Accurate references to previous conversations
• [ ] Clear next steps and ownership
• [ ] Appropriate for the stakeholder level (not too technical for executives, not too vague for engineers)
• [ ] Length is appropriate for the channel (shorter for chat, fuller for email)

5. Offer Iterations

After presenting the draft:

• "Want me to adjust the tone? (more formal, more casual, more empathetic, more direct)"
• "Should I add or remove any specific points?"
• "Want me to make this shorter/longer?"
• "Should I draft a version for a different stakeholder?"
• "Want me to draft the internal escalation note as well?"
• "Should I prepare a follow-up message to send after [X days] if no response?"

---

Customer Communication Best Practices

Core Principles

1. **Lead with empathy**: Acknowledge the customer's situation before jumping to solutions 2. **Be direct**: Get to the point — customers are busy. Bottom-line-up-front. 3. **Be honest**: Never overpromise, never mislead, never hide bad news in jargon 4. **Be specific**: Use concrete details, timelines, and names — avoid vague language 5. **Own it**: Take responsibility when appropriate. "We" not "the system" or "the process" 6. **Close the loop**: Every response should have a clear next step or call to action 7. **Match their energy**: If they're frustrated, be empathetic first. If they're excited, be enthusiastic.

Response Structure

For most customer communications, follow this structure:

1. Acknowledgment / Context (1-2 sentences)
   - Acknowledge what they said, asked, or are experiencing
   - Show you understand their situation

2. Core Message (1-3 paragraphs)
   - Deliver the main information, answer, or update
   - Be specific and concrete
   - Include relevant details they need

3. Next Steps (1-3 bullets)
   - What YOU will do and by when
   - What THEY need to do (if anything)
   - When they'll hear from you next

4. Closing (1 sentence)
   - Warm but professional sign-off
   - Reinforce you're available if needed

Length Guidelines

• **Chat/IM**: 1-4 sentences. Get to the point immediately.
• **Support ticket response**: 1-3 short paragraphs. Structured and scannable.
• **Email**: 3-5 paragraphs max. Respect their inbox.
• **Escalation response**: As long as needed to be thorough, but well-structured with headers.
• **Executive communication**: Shorter is better. 2-3 paragraphs max. Data-driven.

Tone and Style Guidelines

Tone Spectrum

| Situation | Tone | Characteristics | |-----------|------|----------------| | Good news / wins | Celebratory | E