Support Team Handbook Template

1. Our Support Mission

[Your Company Name] exists to help customers succeed. The support team is the front line of that mission.

Our job is to solve problems quickly, honestly, and with empathy. When a customer contacts us, they have a problem that's blocking them from getting value from our product. Every interaction is a chance to turn frustration into trust.

What good support looks like here:

• Respond fast. Speed is respect. A slow first response tells the customer they don't matter.
• Be honest. If something is broken, say so. If we don't know the answer, say that too. Customers forgive imperfection. They don't forgive dishonesty.
• Solve the problem, not just the ticket. A closed ticket with an unhappy customer is a failure. A ticket that took longer but left the customer confident is a win.
• Know when to escalate. Asking for help is a strength. Spending 45 minutes on something a senior agent could solve in 5 is not.
• Follow up on promises. If you told a customer you'd update them by Friday, update them by Friday. Even if the news is "we're still working on it."

What support is not:

• A cost center to be minimized. We're a revenue protection and customer retention team. Every saved customer is worth more than the time spent saving them.
• A place to hide behind policy. Policies are guidelines. They exist for good reasons, but they don't override common sense.
• A dumping ground for every problem in the company. We escalate what we can't fix, and we track patterns that need product or engineering attention. If the same bug generates 50 tickets, that's a product problem, not a support problem.

2. Team Structure and Roles

Support Agent (L1)

Handles the bulk of incoming tickets. Expected to resolve 70-80% of conversations without escalation. Responsible for:

• Password resets, login issues, account changes
• How-to questions and product guidance
• Billing inquiries and straightforward refund requests (within policy)
• Known bugs with documented workarounds
• Order status, shipping questions, basic account troubleshooting
• Feature request logging and acknowledgment
• First-pass triage and priority classification on all incoming tickets

Metrics: Quality score 2.0+ average (see Section 10), SLA compliance above 90%, first contact resolution above 65%.

Senior Support Agent (L2)

Handles escalated issues from L1. Expected to resolve 90%+ of what reaches them. Responsible for:

• Complex technical troubleshooting requiring investigation
• Policy exceptions (with documented reasoning for each exception granted)
• Multi-step account investigations (billing discrepancies, data issues)
• Complaint resolution and de-escalation of angry customers
• Training and mentoring L1 agents (pair sessions, ticket reviews)
• Pattern identification: flagging recurring issues that need product or engineering attention
• Writing and updating knowledge base articles for new issue types

Support Lead / Manager

Owns team performance, hiring, scheduling, and process improvement. Does not carry a full ticket queue but handles sensitive situations directly:

• Legal threats or mentions of lawyers
• PR-risk conversations (customers with large social followings, journalists, influencers)
• High-value customer retention ($[threshold] MRR or above)
• VIP and enterprise account issues
• Policy decisions not covered by existing guidelines
• Situations involving vulnerable individuals (minors, people in distress)
• Requests from law enforcement or government agencies

Runs weekly team standups, monthly quality reviews, and quarterly planning. Owns the hiring pipeline, onboarding program, and team budget.

Support Operations / AI Ops (if applicable)

Manages automation rules, AI classification accuracy, knowledge base maintenance, and tooling. Responsible for:

• Reviewing AI-handled conversations for accuracy (weekly sample of 50+)
• Identifying new intents to automate and configuring automation rules
• Maintaining and updating the internal and public knowledge bases
• Building and maintaining reporting dashboards
• Workflow optimization (reducing unnecessary steps, improving routing)
• Evaluating new tools and integrations

On-Call Rotation

[Customize this section to match your team's structure.]

Structure: One L2 agent is on-call outside business hours. Rotation is weekly, with the schedule posted in [shared calendar / Slack channel] at least 2 weeks in advance.

On-call hours: [6 PM - 9 AM weekdays, all day weekends and holidays]

What triggers a page:

• P1 issues only (service down, data loss, active security incident, payment system failure)
• Pages come through [PagerDuty / OpsGenie / Slack alert]

Response expectations:

• Acknowledge the page within 10 minutes
• Begin investigation within 15 minutes
• If the issue requires engineering, escalate immediately (don't try to fix code yourself)

Compensation: [Comp time / on-call stipend of $[amount] per shift / specific policy]. Nobody should be on-call for free.

Handoff protocol: At each rotation change, the outgoing on-call briefs the incoming on-call on any open issues, recent incidents, or customers to watch.

Backup: If the primary on-call doesn't respond within 15 minutes, [PagerDuty / your tool] automatically pages the secondary on-call. If secondary doesn't respond in 15 minutes, it pages the support lead.

3. Support Channels and Availability

Business hours: Monday through Friday, [9:00 AM - 6:00 PM] [your timezone]. Display these on your website, in your chat widget greeting, and in your email auto-responder.

After hours: AI handles common questions automatically (password resets, order status, FAQ, business hours). Urgent issues (service down, data loss, active security incident, payment system failure) trigger the on-call alert. Everything else queues for the morning.

Weekend and holiday coverage: [Choose your policy: AI-only with on-call for P1 / skeleton crew of 1-2 agents / full coverage / no coverage with auto-responder. Document which one and why.]

Channel-Specific Guidelines

Email: More formal tone. Complete sentences. Include all relevant information in one message (customers check email less frequently, so back-and-forth is slower and more frustrating). Sign off with your name.

Chat: Faster, more conversational. Short messages. It's okay to send multiple short messages instead of one long one. Acknowledge immediately even if you need time to research ("Let me look into that, one sec").

Social media: Public-facing. Assume everyone can see your response. Acknowledge quickly, move to private channel (DM, email) for account-specific details. Never share or request personal information in public replies.

Phone: Emphasis on empathy and tone of voice. Speak clearly, don't rush. Summarize what you heard back to the customer before jumping to solutions. If you need to put them on hold, explain why and give a time estimate.

Channel Prioritization Rules

• If the same customer contacts us on multiple channels about the same issue, consolidate into whichever channel they used first. Don't make them repeat themselves.
• If a public channel (social media, app store review) contains a complaint, respond publicly within 1 hour to acknowledge, then move to a private channel for resolution.
• If a customer is mid-conversation on chat at end of business, don't abandon the conversation. Either resolve it or hand off with a warm introduction: "I'm passing this to [Name] who will keep helping you. They have the full context of our conversation."

4. Response Time SLAs

These are internal targets. Missing them occasionally is human. Missing them regularly means something is broken in our process.

How to Classify Priority

• Can the customer use the product at all? No = P1.
• Can the customer use most of the product but one feature is broken? P2.
• Is money directly involved (billing error, failed payment, unauthorized charge)? P2 minimum.
• Is the customer angry or explicitly threatening to cancel? Bump priority by one level.
• Is this a VIP, enterprise, or high-MRR customer? Bump priority by one level.
• Is the issue a security vulnerability or data breach? P1 or P2 regardless of how many customers are affected.
• Feature request with no urgency? P4. Always P4.

SLA Clock Rules

• The clock starts when the customer sends the message, not when an agent first sees it.
• The clock pauses when we're waiting on the customer for information (they need to provide screenshots, account details, etc.). It resumes when they respond.
• The clock does NOT pause for internal escalations. If you escalate to engineering, the customer's SLA clock keeps running. This means you need to follow up on escalations.
• If an SLA is about to breach (within 30 minutes of target), the ticket is automatically flagged in [your tool] and the support lead is notified via [Slack / PagerDuty].
• If an SLA has already breached, the support lead reviews the ticket within 2 hours and determines next steps.

SLA Breach Protocol

When an SLA is breached:

1. The support lead is automatically notified
2. The assigned agent (or the lead, if unassigned) contacts the customer with an apology and a specific update: "I'm sorry for the delay. Here's where we are: [status]. I'll have a resolution for you by [specific time]."
3. The breach is logged for the weekly team review
4. If breaches exceed [threshold, e.g., 10% of tickets in a week], the support lead investigates root cause (understaffing? tool issues? unclear routing?) and implements a fix

5. Escalation Procedures

When to Escalate

Escalate any time one of these is true:

• You've spent 15+ minutes on a single issue without making progress
• The issue requires code changes, database access, or infrastructure intervention
• The customer is angry and your de-escalation attempts aren't working
• There are legal, compliance, or security implications (even suspected)
• The customer explicitly asks for a manager or supervisor (always honor this immediately, no exceptions)
• The issue involves potential data breach or unauthorized access
• You're unsure whether the company's policy covers this specific situation
• The customer's account value exceeds $[threshold] MRR
• The customer mentions self-harm, abuse, or immediate danger (escalate to management instantly)
• You receive a request from law enforcement, a lawyer, or a government agency

Escalation Path

L1 to L2 (Senior Agent / Support Lead):

• Complex technical issues requiring deeper investigation
• Policy exceptions (customer wants something outside standard policy)
• Escalated complaints (customer is upset and you can't resolve their issue)
• Multi-step troubleshooting taking more than 15 minutes
• Any situation where you're unsure of the right answer

L2 to L3 (Engineering / Product):

• Confirmed bugs requiring code changes (include reproduction steps)
• Data integrity issues (missing data, corrupted records, sync failures)
• Infrastructure problems (performance degradation, outages, capacity issues)
• Security incidents (unauthorized access, vulnerability reports, suspicious activity)
• Feature questions requiring technical feasibility assessment

Any level to Management:

• Legal threats or mentions of lawyers or lawsuits
• PR risk (customer has large social following, is a journalist, or is an industry figure)
• High-value customer threatening to cancel ($[threshold] MRR or above)
• Policy decisions not covered by existing guidelines
• Situations involving vulnerable individuals (minors, people in distress, elderly customers needing extra assistance)
• Requests from law enforcement or government agencies (see Section 12)
• Self-harm or suicide mentions (see Section 14)

How to Escalate Properly

1. Document everything first. In the ticket, write: what the customer reported, what you investigated, what you tried, what the results were, and specifically why you're escalating. "Customer needs help" is not an escalation note. "Customer's export returns empty files. I verified their data exists in the dashboard, tried CSV and JSON formats, cleared cache, tested in incognito. Suspect a backend issue with the export function for accounts with 10K+ records" is.

1. Tag the right person or channel. Post in [#support-escalations in Slack / escalation queue in your tool]. Tag the specific person or team who can help. Don't broadcast to general channels hoping someone picks it up.

1. Include full context. Customer name, account ID/email, plan type, account age, MRR value if known, issue summary, steps you've already attempted, priority level, and how long the customer has been waiting.

1. State what you need. "I need engineering to investigate why export fails for accounts with 10K+ records" is actionable. "Customer has an issue with exports" is not.

1. Stay on the ticket. You're the customer's point of contact unless the escalation lead explicitly takes ownership. Update the customer: "I've brought in a specialist who has more access to the tools needed for this. They're looking into it now, and I'll keep you posted."

1. Follow up on your escalation. If you haven't heard back in [30 minutes for P1, 2 hours for P2, 4 hours for P3], ping the escalation target again. Tickets die in escalation limbo more often than anywhere else. Don't let that happen.

Cross-Department Handoff Protocol

When a ticket needs to move between teams (support to engineering, support to sales, support to billing):

1. Write a handoff summary in the ticket: customer context, issue, what's been tried, what's needed from the receiving team, and the customer's current emotional state.
2. Introduce the customer to the receiving team member if possible: "I'm connecting you with [Name] from our [team], who can help with the [specific part]."
3. The receiving team acknowledges the handoff within [1 hour] and updates the ticket.
4. The original agent follows up in 24 hours to confirm the handoff was completed. If not, re-escalate.
5. The ticket stays open until the customer's issue is fully resolved, regardless of how many teams touched it. Nobody gets to close their portion and walk away.

6. Tone of Voice and Communication Standards

The Basics

We write like a smart, friendly colleague. Not a corporation. Not a robot. Not someone reading from a card. Research shows 66% of customers are more loyal to companies that show empathy, and 61% will spend more when they feel understood.

Do:

• Use the customer's first name
• Use contractions (don't, can't, we'll, I've, it's)
• Be direct ("I fixed it" not "The issue has been resolved by our team")
• Match the customer's energy (casual customer = casual response, formal customer = match their formality)
• Admit mistakes plainly ("We messed up" not "We apologize for any inconvenience this may have caused")
• Give specific timelines ("I'll have an answer by 3 PM today" not "I'll get back to you soon")
• End messages with an open door ("Anything else?" or "Let me know if that doesn't work")

Don't:

• Use corporate jargon ("per our policy", "at this time", "please be advised", "as per my previous")
• Apologize with empty phrases ("sorry for the inconvenience" has been said billions of times and means nothing)
• Over-promise ("this will never happen again" is a promise you can't keep)
• Use passive voice to hide responsibility ("your account was suspended" hides who did it. Say: "we suspended your account because [reason]")
• Copy-paste canned responses without reading the customer's specific situation and personalizing
• Use filler ("I hope this email finds you well", "Thank you for your patience and understanding")
• Say "unfortunately" more than once per conversation
• Use ALL CAPS for emphasis (it reads as shouting)

Handling Specific Emotional States

Customer is frustrated but polite: Match their urgency. Acknowledge the specific problem, not the emotion generically. "You're right, waiting 3 days for a reply is way too long. Let me fix this right now." Then fix it fast.

Customer is angry: Let them vent. Do not interrupt, do not get defensive, and do not correct minor factual errors in their complaint (you can clarify later). After they've said their piece: "I hear you. That's a bad experience. Here's what I'm going to do about it: [specific action with specific timeline]."

If they use profanity directed at the situation ("this is so f---ing frustrating"), let it go. They're venting about the problem.

If they use slurs or personal attacks directed at you, set a boundary once: "I want to help you with this, but I need the conversation to stay respectful." Second offense: "I've asked once for respectful communication. If it continues, I'll need to end this conversation and follow up via email with a resolution." Third offense: End the conversation, document everything, and notify your lead (see Section 14).

Customer is confused: Don't repeat the same explanation louder. Rephrase from a different angle. Use an analogy. Offer to send a screenshot, a Loom video, or hop on a quick screen share. If they're still confused after your second attempt, the product might have a UX problem worth logging.

Customer is threatening to cancel: Don't panic and don't offer discounts immediately. First, understand the root cause: "I want to understand what changed. What's not working the way you expected?" If the issue is fixable, fix it. If it's a pricing concern, explain the value without being defensive. If the product genuinely isn't right for them, let them go gracefully: "I understand. I've canceled your account effective [date]. No further charges. If things change, we'd love to have you back." Route retention-risk conversations to L2 or your retention workflow.

Customer is a minor or appears vulnerable: Follow your organization's safeguarding policy (see Section 14). Do not collect personal information beyond what's strictly needed. If the customer appears to be in distress or danger, provide relevant crisis hotline information for their region. Escalate to management immediately.

Channel-Specific Tone Adaptation

7. Common Scenarios and Response Templates

These are starting points. Read the customer's actual message and personalize every response. A canned response the customer can tell is canned does more harm than good.

Account and Access

Password reset: "Hey [Name], I've sent a reset link to the email on your account ([partially redacted, e.g., j*@gmail.com]). Check your spam/junk folder if it doesn't show up in a couple minutes. The link expires in 24 hours. If you don't have access to that email anymore, let me know and we'll verify your identity another way."

Account locked (security): "Your account got locked because [specific reason: too many failed login attempts, unusual activity from a new location, a security scan flagged suspicious behavior]. I've unlocked it. You'll need to reset your password here: [link]. Important: if those login attempts weren't you, tell me right away. We'll want to check for unauthorized access and secure your account."

Account deletion / data export (GDPR/CCPA): "I can process that. Before I start: deleting your account permanently removes all your data within [30 days per GDPR / your policy]. This can't be undone. Would you like me to export your data first? I can send you everything we have in [JSON/CSV] format within [timeframe]. Once you confirm you're ready, I'll kick off the deletion."

Billing and Payments

Refund request (within policy): "Done. Refund of $[amount] for [item/order] is processing now. Should hit your [card ending in XXXX / PayPal / original payment method] within 5-7 business days, depending on your bank. You'll get a confirmation email in a few minutes."

Refund request (outside policy): "I checked and the return window closed on [date]. I can't do a standard refund, but I have a few options: [store credit for the full amount / exchange for a different item / partial refund of X% / I can ask my manager about an exception given [specific circumstance]]. What sounds best?"

Unexpected charge: "That $[amount] charge on [date] was for [specific reason: plan upgrade you made on [date], overage of X units above your plan limit, annual renewal, add-on subscription]. I can see why that'd catch you off guard, especially if [reason it might be confusing, e.g., "you didn't get a reminder email before the renewal"]. Here's the full breakdown: [details]. If you'd like to adjust your plan to avoid this next month, I can walk you through the options."

Failed payment: "Your payment of $[amount] on [date] didn't go through. The error we're seeing is [specific if available: card declined, insufficient funds, expired card, bank flagged it]. You can update your payment method at [link]. If you need a few extra days, I can extend your access until [specific date] so nothing gets interrupted."

Product Issues

Bug report (reproducible): "Thanks for reporting this. I can reproduce it on my end. I've filed it with engineering as a [priority] issue, ticket reference [ID]. I'll update you when we have a fix. Estimated timeline: [if known, give it; if not, say "I don't have an ETA yet but I'll check in with the team and update you within 24 hours"]. In the meantime, here's a workaround: [specific steps]."

Bug report (can't reproduce): "I tried to reproduce this but it's working on my end. Can you help me narrow it down? I need: what browser and version you're using, what device (desktop/mobile/tablet), whether you're on a VPN or corporate network, roughly what time it happened, and a screenshot or screen recording if you can grab one. This will help me figure out whether it's environment-specific."

Feature request: "Good idea. I've logged it for the product team with your specific use case (so they understand why you need it, not just what you want). I can't promise a timeline or guarantee it'll be built, but your input goes directly to the people making those decisions. If it does get prioritized, I'll reach out."

Outage or known issue: "We're aware of [specific issue] and our team is actively working on it. Current status: [what's happening]. Expected resolution: [time if known, or "we're working on it as fast as we can and I'll update you as soon as I have more info"]. You can check [status page URL] for real-time updates. I'll also email you directly when it's resolved."

Difficult Situations

Customer threatening legal action: Do not engage with the legal threat. Do not admit fault. Do not offer concessions to make it go away. Respond: "I take this seriously. I'm escalating your case to our [legal team / management] who can address your concerns directly. They'll be in touch within [timeframe]." Escalate to management immediately with full conversation history and context.

Abusive customer (3-strike protocol): First offense: "I understand you're frustrated, and I want to help. I need us to keep the conversation respectful so I can focus on solving your problem." Second offense: "I've asked once to keep things respectful. If the language continues, I'll need to end this conversation and follow up via email with a resolution." Third offense: End the conversation. "I'm ending this chat now. I'll follow up via email within [timeframe] with a resolution to your [issue]." Document everything in the ticket. Notify your lead. The lead reviews every terminated interaction.

Request from law enforcement or government agency: Do not provide any customer data. Do not confirm or deny that someone is a customer. Respond: "We take these requests seriously. Please send your formal request in writing to [legal@yourcompany.com]. Our legal team will review and respond within [timeframe]." Escalate to management and legal immediately. Do not discuss the request with anyone outside the legal/management escalation path.

Customer mentions self-harm or suicide: Take every mention seriously. Do not assess whether they're "really" at risk. Stay calm, listen, and do NOT attempt to be a counselor. Provide crisis resources: "If you're in crisis, please reach out to the 988 Suicide and Crisis Lifeline (call or text 988 in the US) or the Crisis Text Line (text HOME to 741741). They have trained counselors available 24/7." Escalate to your manager immediately. After the interaction, you are entitled to take a break and debrief with your lead. This is emotionally heavy and support is available for you too.

Vulnerable customers (elderly, disabled, language barriers, financial hardship): Provide additional time and patience. Don't rush. Use simpler language without being condescending. Confirm understanding at each step ("Does that make sense so far?"). If there's a language barrier, ask if they'd prefer written communication or if there's someone who can help translate. Note any accessibility needs in the account so future agents can provide consistent accommodations.

8. Tools and Access

Every team member should have access to these on day one:

Day-One Access Checklist

When a new agent starts, complete all of these before their first day:

1. Help desk account created, assigned to correct team/group/queue
2. Slack/Teams added to: #support, #support-escalations, #support-social, #engineering-bugs, #incidents
3. CRM access with read permissions (write permissions granted after Week 2)
4. Knowledge base access (internal: read; public: read + suggest edits)
5. Bug tracking tool access with create permissions
6. Screen recording tool license provisioned
7. Calendar access to team schedule, on-call rotation, and meeting invites
8. VPN / security tools installed and configured (if accessing customer data remotely)
9. Password manager vault shared (team-level credentials only)
10. 2FA/MFA enabled on all tools

Customer Data Security Rules

These are non-negotiable.

• Never share customer data in public Slack channels. Use private channels or DMs.
• Never screenshot customer PII (emails, addresses, phone numbers, payment info) and send it via messaging tools, personal email, or any channel outside your approved help desk.
• Don't store customer data on personal devices, USB drives, or personal cloud accounts.
• Don't copy customer data into AI tools (ChatGPT, Claude, etc.) unless those tools are company-approved and covered by a data processing agreement.
• If a customer asks to delete their data (GDPR, CCPA, or company policy), route the request to [Data Privacy contact] and confirm receipt to the customer within 24 hours.
• Lock your computer when you step away. Every time. Even if you're just going to the kitchen. No exceptions.
• Report any suspected data breach or unauthorized access to [Security contact] immediately, even if you're not sure. A false alarm costs nothing. An unreported breach can cost the company and its customers everything.

9. New Agent Onboarding (4-Week Program)

Week 1: Observe and Learn

Day 1-2: Setup and orientation

• Read this entire handbook (yes, all of it)
• Complete the Day-One Access Checklist (Section 8)
• Meet the team: 15-minute 1:1 with each team member
• Get assigned an onboarding buddy (a senior agent who's your dedicated go-to for questions)
• Complete security and data handling training (Section 12)
• Set up your help desk account, learn the interface, practice navigating tickets

Day 3-5: Shadow and study

• Shadow your buddy for 2 full days. Sit in on their ticket handling. Watch how they triage, research, respond, escalate, and close tickets. Take notes on patterns you notice.
• Read the last 100 resolved tickets (sorted by most recent). Note: what are the most common issues? What do good responses look like? What confuses you?
• Go through the customer onboarding flow yourself. Sign up as a new user, use every major feature, intentionally try to break things, and file bugs if you find any.
• Read all public knowledge base articles. Flag any that seem outdated, incomplete, or confusing.
• Study the internal knowledge base, especially troubleshooting guides for the top 10 issues.

End of Week 1 checkpoint: You should be able to describe the top 10 most common support issues and the standard resolution for each without looking them up.

Week 2: Supervised Practice

• Start handling P3 and P4 tickets only
• Every response is reviewed by your buddy before it goes to the customer
• Target: 10-15 tickets per day (quality over speed)
• Daily 15-minute debrief with your buddy: what went well, what was confusing, what you'd do differently
• Start building your personal cheat sheet of common responses, shortcuts, and gotchas
• Attend your first team standup

End of Week 2 checkpoint: You should be handling simple tickets confidently with minimal corrections needed from your buddy.

Week 3: Expanding Scope

• Handle all priority levels (P1-P4), but escalate anything you're not confident about (no penalty for escalating too much in Week 3)
• Buddy reviews a random sample of your responses (~30%), not all of them
• Target: 20-30 tickets per day
• Start participating in team meetings and quality reviews as an observer
• Shadow one on-call shift (observe only, don't handle)
• Write your first knowledge base article for an issue you solved that wasn't documented

End of Week 3 checkpoint: You should be comfortable with 80% of incoming tickets and know exactly when and how to escalate the other 20%.

Week 4: Independent with Safety Net

• Full queue access, all priority levels, all channels
• Buddy does spot-checks only (~10% of tickets, randomly sampled)
• Target: your sustainable pace (usually 25-40 tickets/day depending on complexity and channel mix)
• Handle your first on-call shift (with your buddy as backup)
• Complete a self-assessment: what are your strengths? Where do you still feel shaky?

End of Week 4: Formal review with support lead. Review quality scores, discuss areas for growth, set goals for the next 90 days, talk about career interests.

Ongoing Development

• Weekly 1:1 with support lead (first 3 months, then biweekly)
• Monthly quality review of 10 random tickets (see Section 10)
• Quarterly skills assessment and career development conversation
• Training budget: $[amount] per year for courses, conferences, certifications, or books
• Encouraged to contribute to the knowledge base regularly. If you solve a problem that isn't documented, write it up. Takes 5 minutes. Saves the next person 30.

10. Quality Assurance and Performance

Monthly Quality Review

Every agent gets 10 randomly selected tickets reviewed each month. Tickets are scored against four categories using a 1-3 scale:

Accuracy (did we give the right answer?)

• 3 (Excellent): Correct, complete, well-explained, solution was the best option for this specific customer
• 2 (Meets expectations): Correct information, resolved the issue, but could have been more thorough or better explained
• 1 (Needs improvement): Incorrect information given, important details missed, or guesswork presented as fact

Speed (did we meet SLA?)

• 3 (Excellent): Well within SLA, no unnecessary delays, customer never had to ask for updates
• 2 (Meets expectations): Within SLA but close, or one minor delay between messages
• 1 (Needs improvement): SLA breached, or significant delays between messages without customer updates

Tone (did we sound like us?)

• 3 (Excellent): Warm, personal, on-brand, appropriate empathy, customer felt like they were talking to a real person who cared
• 2 (Meets expectations): Professional and clear, but generic. Could have been more personal.
• 1 (Needs improvement): Robotic, rude, dismissive, or inappropriately casual for the situation

Completeness (did we actually solve it?)

• 3 (Excellent): Problem fully resolved, all follow-up actions completed (refund processed, bug filed, etc.), customer confirmed satisfaction or received clear next steps
• 2 (Meets expectations): Problem resolved but loose ends remain (forgot to file the bug, didn't confirm with the customer)
• 1 (Needs improvement): Problem unresolved, partially resolved, or customer had to follow up to get the rest of the answer

Auto-fail triggers (entire ticket scores 0):

• Gave the customer someone else's account information
• Shared customer data in an unauthorized channel
• Made a commitment the company can't keep (e.g., promised a feature by a specific date without product team approval)
• Ignored a self-harm or abuse mention

Scoring targets:

• Individual average: 2.0+ across all categories
• Team average: 2.3+
• Scores below 1.5 in any category trigger a coaching session (not punishment, coaching). The goal is improvement, not blame.

Dissatisfaction (DSAT) Review Process

Every negative customer rating (1-2 star, thumbs down, "No" to "Was this helpful?") gets reviewed:

1. Tag the DSAT ticket by root cause: agent error, policy issue, product bug, or genuinely unresolvable
2. QA-audit the specific interaction against the scoring rubric above
3. Root cause analysis: why was the customer dissatisfied? Was it something we could have prevented?
4. Feed findings back to the right team: agent coaching (if agent error), product team (if product bug), leadership (if policy needs changing)
5. Track DSAT trends monthly. Are certain categories growing? Are certain ticket types consistently generating dissatisfaction?

Team Metrics Dashboard

What we don't use as individual performance metrics:

• Tickets per hour. Fast and wrong is worse than slow and right.
• Individual CSAT scores. Satisfaction depends on product quality, pricing, shipping speed, and dozens of factors outside one agent's control.

11. Knowledge Base and Documentation

Internal Knowledge Base (for the team)

Every new issue type, workaround, or process change gets documented. If you solved a problem that wasn't in the knowledge base, write it up. Takes 5 minutes. Saves the next person 30.

What goes in the internal KB:

• Troubleshooting guides for known issues (step-by-step with screenshots)
• Workarounds for bugs that haven't been fixed yet
• Product quirks and edge cases ("if the customer has 10K+ records, the export times out. Workaround: export in batches of 2K")
• Internal processes (how to process a refund, how to escalate to engineering, how to grant a billing credit)
• Decision trees for ambiguous situations (flowchart: "customer wants a discount" with decision points)
• Glossary of internal terms, product names, and abbreviations

Article format (keep it consistent):

• Title: use the customer's words ("Customer says 'I can't log in'" not "Authentication Troubleshooting Procedures")
• Symptoms: what the customer reports seeing or experiencing
• Cause: what's actually happening technically (if known)
• Solution: numbered, step-by-step resolution
• If that doesn't work: next steps, alternative approaches, or escalation path
• Related articles: links to similar issues
• Last updated: date and who updated it

Maintenance: Review 20% of internal KB articles each month (rotate so everything gets reviewed at least twice a year). Archive anything that references deprecated features or processes. Flag articles with "last updated 6+ months ago" for review.

Public Knowledge Base (for customers)

• Write in plain language. If your grandmother couldn't follow the instructions, simplify them.
• Include screenshots for any process with more than 2 steps
• Keep articles focused: one topic per article, not mega-guides covering everything
• Add a "Was this helpful?" widget to every article. Track the results.
• Review quarterly. Archive outdated content. Update anything that references old UI, old pricing, or old features.
• Track which articles get the most views and which have the highest "not helpful" rates. Fix the unhelpful ones first.

12. Data Privacy and Compliance

Data Handling Rules

Minimum necessary principle: Only access the customer data you need to resolve their specific issue. Don't browse accounts out of curiosity. Don't look up friends' or family members' accounts. Access logs are audited.

No data on personal devices: Customer data stays in company-approved tools. No screenshots on personal phones. No notes in personal Google Docs. No forwarding customer emails to personal accounts. No copying conversations into unauthorized AI tools.

Secure communication: Discuss customer details only in private, encrypted channels (private Slack channels, help desk internal notes). Never share customer information via text message, personal email, or public channels.

Retention: Customer conversation data is retained for [your retention period]. After that, it's automatically deleted unless there's a legal hold.

Handling Specific Privacy Requests

"Delete my data" (GDPR Article 17 / CCPA):

1. Verify the customer's identity (email verification, account security question, or government ID depending on your verification process)
2. Route to [Data Privacy contact / your process]
3. Confirm receipt to the customer within 24 hours: "We've received your deletion request. We'll process it within [30 days for GDPR / 45 days for CCPA] and confirm when complete."
4. Ensure deletion is thorough: account data, conversation logs, analytics data, backups (within retention schedule), and any third-party integrations
5. Send final confirmation to the customer when deletion is complete

"Export my data" (GDPR Article 20 / CCPA right to access):

1. Verify identity (same as above)
2. Generate data export in machine-readable format (JSON or CSV, not PDF screenshots)
3. Deliver securely: encrypted email attachment, or a time-limited secure download link. Not a plain email attachment.
4. Complete within [30 days for GDPR / 45 days for CCPA]

"Stop using my data for AI training": If your company uses customer conversations to train AI models, customers have the right to opt out under GDPR and several US state laws. Confirm your company's policy: [do you use customer data for AI training? If so, how do customers opt out?]. Route these requests to [appropriate team].

Compliance Quick Reference

COPPA special procedures (if your product may be used by children under 13):

• If a user self-identifies as under 13, stop collecting data immediately
• Escalate to your COPPA compliance handler
• Parental consent is required before any account action
• Parents can review, delete, or prevent further data collection at any time
• Auto-delete inactive minor accounts after 12 months

13. Incident Response

When something breaks, speed and communication matter more than perfection.

Severity Levels

SEV-1 (Major outage): Core product is down for all or most customers. Examples: website/app completely inaccessible, payment processing broken, data loss event.

SEV-2 (Partial outage): Significant feature broken for a subset of customers. Examples: export not working, one integration down, search returning wrong results.

SEV-3 (Degraded performance): Product works but noticeably slower or with minor issues. Examples: pages loading slowly, intermittent errors, one API endpoint timing out occasionally.

Support's Role During Incidents

SEV-1:

1. Acknowledge to affected customers within 5 minutes (use a template, don't craft individual responses during an emergency)
2. Post to the status page immediately
3. Provide updates every 30 minutes minimum (even if the update is "still working on it")
4. Track affected tickets with the incident tag so you can follow up with every customer after resolution
5. Stay in the #incidents channel for real-time updates from engineering

SEV-2:

1. Identify the scope (which customers are affected?)
2. Provide workarounds where possible
3. Post to status page
4. Update affected customers every hour
5. Route new tickets about the issue to the incident thread instead of creating new investigations

SEV-3:

1. Note the issue in your ticketing system with a consistent tag
2. Provide workaround if one exists
3. Monitor for escalation to SEV-2

During an Incident

• Don't troubleshoot individually. If you see 5+ customers reporting the same thing within 30 minutes, it's an incident. Raise it in #incidents immediately.
• Use the status page. Posting there reduces inbound ticket volume by 30-50% during incidents.
• Template response for affected customers: "We're aware of [specific issue] and actively working on it. Real-time updates are at [status page URL]. I'll also email you personally when it's resolved."
• Track affected tickets. Tag every ticket related to the incident with a consistent tag (e.g., INC-2026-03-16) so you can bulk follow-up.

After Resolution

Send a personal follow-up to every affected customer. Not a mass email. A personal note:

"The [issue] from [date] is resolved. Here's what happened: [1-2 sentence explanation]. Here's what we're doing to prevent it: [specific action]. Sorry about the disruption, and thanks for your patience."

Schedule a post-incident review within 48 hours. Support's input: how many customers were affected, what the customer experience was like, where communication broke down, what templates need to be created or updated.

14. Taking Care of Yourself

Support is emotionally demanding. You absorb customer frustrations all day. Pretending that doesn't take a toll is how people burn out.

What's expected:

• Take every break you're entitled to. Step away from the screen. Don't eat lunch at your desk while answering tickets.
• After a difficult conversation (angry customer, distressing situation, abuse), take 5-10 minutes before the next ticket. Walk around, get water, step outside. Whatever resets you.
• Use your PTO. All of it. Don't hoard days. We'd rather have you rested for 48 weeks than running on fumes for 52.
• End your shift on time. The tickets will be there tomorrow. Your mental health won't wait.

What's available:

• [EAP / mental health benefit details if applicable]
• Swap difficult tickets with a teammate anytime. Nobody's keeping score.
• Request a "cool-down day" after a particularly rough week: work on knowledge base articles, documentation, or training instead of the ticket queue.
• Talk to your lead if the workload feels unsustainable. "I'm overwhelmed" is information your manager needs to hear. It's not a weakness. It's a signal that something needs to change (staffing, workload distribution, tooling, or automation).

Burnout warning signs:

• Dreading opening the inbox every morning
• Responding to customers with less patience or empathy than you used to
• Feeling cynical about customers or their problems
• Feeling like nothing you do makes a real difference
• Physical symptoms: headaches, trouble sleeping, stomach issues, fatigue
• Taking customer complaints personally or replaying difficult conversations at home

If you notice these in yourself or a teammate, say something. Talk to your lead, your buddy, HR, or your EAP counselor. This job is hard. Asking for help is how you stay good at it long-term.

After a crisis interaction (self-harm mention, death, abuse): You are entitled to: immediate break from the queue, debrief with your manager or a peer, same-day access to EAP/counseling if desired, and a lighter workload for the rest of the day. These interactions are rare but they hit hard. Nobody should process a self-harm escalation and immediately pick up the next ticket about a billing question.

15. How to Customize This Template

This handbook is a starting point. No two support teams are the same.

1. Replace all [bracketed text] with your actual company info, tool names, policies, and numbers. Search the document for "[" to find them all.
2. Adjust the SLA targets in Section 4 to match what your team can consistently deliver. Aspirational SLAs you miss 40% of the time are worse than realistic ones you hit 95% of the time.
3. Add your product-specific scenarios to Section 7. What are the top 20 questions your team gets? Write a response template for each one.
4. Remove sections that don't apply. No phone support? Delete those rows. No on-call rotation? Remove that subsection. No COPPA concerns? Remove those paragraphs. A shorter, accurate handbook beats a long, irrelevant one.
5. Add sections you need: product-specific troubleshooting guides, seasonal playbooks (Black Friday, end-of-year), compliance requirements specific to your industry, integration-specific documentation, VIP/enterprise customer procedures.
6. Review quarterly. Set a calendar reminder. Your product changes, your team grows, your processes evolve. A stale handbook that people stop trusting is worse than no handbook at all.
7. Make it findable. Store it somewhere your team actually goes every day (Notion, Google Docs, Confluence, your internal wiki). Pin it in your team's Slack channel. Not in a PDF on a shared drive nobody opens. If people can't find it in 10 seconds, it doesn't exist.
8. Collect feedback from your team. After onboarding a new agent, ask them: "What was confusing? What was missing? What would have helped?" Update the handbook with their answers. The people using it daily know what it needs better than the person who wrote it.