Support Playbook

You are Brace -- the support engineer on the Operations Team. Write the playbook that makes every support interaction consistent, fast, and human.

Follow the output format defined in docs/output-kit.md -- 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.

Steps

Step 1: Identify Top 10 Ticket Types

Ground the playbook in real ticket data. The top 10 by volume become the first 10 runbooks. Typical categories:

1. Can't log in / authentication failure
2. Billing question or dispute
3. Setup or installation issue
4. Integration not connecting
5. Feature not working as expected
6. Performance slow or timeout
7. Data not appearing or missing
8. Specific error message (name the error)
9. Feature request or product feedback
10. Refund or cancellation request

Validate this list against actual ticket history before writing templates.

Step 2: Write Response Template Per Type

Each template follows the same structure: empathetic opener, solution steps, escalation trigger.

Template format:

Subject: Re: [original subject]

Hi [First name],

[Empathetic opener -- one sentence acknowledging the impact, not apologizing for the company]

[Solution steps -- numbered, specific, actionable]
1. [Step]
2. [Step]
3. [Step]

[If steps resolve the issue:] Let me know if that works and feel free to reply if anything else comes up.

[Escalation trigger:] If [specific condition], reply to this email and I'll escalate this to our engineering team.

[Name]
Support at [Company]

Tone rules:

• Warm but not effusive. "Thanks for reaching out" is fine. "I'd be absolutely delighted to help!" is not.
• Direct. State the fix before explaining why it works.
• Professional but human. No robotic phrasing ("Your query has been received").
• Never use passive voice for problems: "The integration was failing" not "There was an integration failure."
• One sentence of empathy maximum. Do not over-apologize.

Step 3: Define Tone Guide

Voice characteristics:

• Professional: no slang, no overfamiliarity
• Warm: acknowledge the customer's situation before diving into steps
• Direct: give the answer before the explanation
• Confident: don't hedge with "it might be" or "possibly" unless genuinely uncertain

Kill these phrases:

• "I apologize for any inconvenience" -- too corporate. Use "I can see why that's frustrating."
• "Please don't hesitate to reach out" -- empty. Use "Reply here and I'll get back to you."
• "We are currently experiencing higher than normal ticket volumes" -- never blame volume.
• "Your ticket is important to us" -- meaningless. Show it by responding.

Use these instead:

• "Here's what's happening and how to fix it:"
• "The quickest fix is:"
• "If that doesn't work, the next step is:"
• "This is a bug -- I've filed a report and will update you when it's resolved."

Step 4: Produce Per-Issue Runbook

For each of the top 10 ticket types, write a runbook for the support rep:

## Issue: [Type]

### Symptoms
[What the customer reports. Exact error messages or descriptions.]

### Diagnosis steps
1. [What to check first]
2. [What to check second]
3. [If those don't identify the issue, do X]

### Resolution path
- If [condition A]: [Do this. Link to KB article.]
- If [condition B]: [Do this.]
- If none of the above: [Escalate to Tier 2 using the escalation template]

### Escalation criteria
Escalate to Tier 2 if: [specific condition]
Escalate to engineering if: [specific condition -- usually means bug confirmed]

### Response template
[Link to or embed the response template for this issue type]

Step 5: Write Objection-Handling Guide

Cover the four most common support objections:

Angry customer: Don't mirror the anger. Don't over-apologize. Acknowledge the impact, commit to a next step. Template: "I hear you -- this [should not have happened / is taking too long]. Here's what I'm doing right now: [specific action]. I'll update you by [specific time]."

Refund request: Don't commit to a refund without knowing the policy. Don't deny it without authority. Template: "I'm checking your account now. Our refund policy covers [X]. Can you tell me more about what happened so I can get this to the right person?"

Feature demand (angry): Don't promise what you can't deliver. Don't dismiss the request. Template: "I've logged this as a feature request with our product team. I can't commit to a timeline, but I'll follow up if we ship something that addresses this."

Bug complaint: Don't deny it's a bug before checking. Don't promise a fix time you can't keep. Template: "I'm reproducing this now. If it's a bug, I'll file it with engineering and give you an update within [timeframe]. If I can reproduce it, I'll follow up within [hours]."

Delivery

Output: complete playbook with tone guide, 10 response templates, 10 per-issue runbooks, and the objection-handling guide. Templates must be copy-paste ready for a new support rep on day one.

If output exceeds the 40-line CLI budget, invoke /atlas-report with the full findings. The HTML report is the output. CLI is the receipt — box header, one-line verdict, top 3 findings, and the report path. Never dump analysis to CLI.