When support volume grows, /support-operations designs SLA policies and tier structures, so you can scale without quality drops. — Claude Skill

---

title: Section Organization

1. Ticket Management (ticket)

Impact: CRITICAL Description: Ticket prioritization, queue management, triage workflows, and assignment rules. The foundation of efficient support operations.

2. SLA Design (sla)

Impact: CRITICAL Description: Service level agreement creation, compliance monitoring, business hours configuration, and breach prevention strategies.

3. Support Tier Structure (tier)

Impact: CRITICAL Description: L1/L2/L3 tier design, skill-based routing, specialization paths, and escalation criteria between tiers.

4. Knowledge Base Strategy (knowledge)

Impact: HIGH Description: Self-service optimization, article structure, deflection measurement, and knowledge maintenance workflows.

5. Support Metrics (metrics)

Impact: HIGH Description: CSAT, FRT, TTR, FCR measurement, quality scoring, agent performance, and operational dashboards.

6. Escalation Procedures (escalation)

Impact: CRITICAL Description: Severity definitions, escalation paths, incident management, on-call rotations, and war room protocols.

7. Support Tool Stack (tooling)

Impact: MEDIUM-HIGH Description: Help desk configuration, integrations, automation rules, and multi-channel orchestration.

8. Support-to-CS Feedback Loops (feedback)

Impact: HIGH Description: Voice of customer programs, product feedback channels, at-risk customer handoffs, and cross-functional insights sharing.

9. Quality Assurance (quality)

Impact: HIGH Description: Ticket review processes, agent coaching, quality scoring rubrics, and continuous improvement programs.

10. Workforce Management (workforce)

Impact: MEDIUM-HIGH Description: Capacity planning, scheduling, forecasting ticket volume, and optimizing agent utilization.

---

title: Agent Onboarding & Training Programs impact: HIGH tags: onboarding, training, development, certification, enablement

Agent Onboarding & Training Programs

Impact: HIGH

Well-trained agents resolve issues faster, create better customer experiences, and stay longer. Poor onboarding creates knowledge gaps that persist for months. Invest in training early and continuously for long-term support excellence.

The Agent Development Journey

┌─────────────────────────────────────────────────────────────────┐
│                     ONBOARDING (Week 1-8)                        │
│  Company culture, product training, tools, shadowing, ramp      │
├─────────────────────────────────────────────────────────────────┤
│                     PROFICIENCY (Month 2-6)                      │
│  Independent work, specialty development, quality improvement   │
├─────────────────────────────────────────────────────────────────┤
│                     MASTERY (Month 6-18)                         │
│  L2 skills, mentoring, process improvement, specialization      │
├─────────────────────────────────────────────────────────────────┤
│                     LEADERSHIP (Year 2+)                         │
│  Team lead, trainer, specialist, or management track            │
└─────────────────────────────────────────────────────────────────┘

Onboarding Program Structure

Day 1 Checklist

Pre-Arrival:
□ Workstation/laptop ready
□ System access provisioned
□ Email and Slack accounts created
□ Training schedule shared
□ Buddy/mentor assigned
□ Welcome kit prepared

Day 1 Schedule:
9:00  - Welcome from manager
9:30  - HR orientation
10:30 - IT setup and access
11:30 - Lunch with team
1:00  - Company overview presentation
2:00  - Support team overview
3:00  - Product intro (high level)
4:00  - Tour and introductions
4:30  - Wrap up with manager, questions

Good Onboarding Practices

✓ Structured curriculum
  → Clear learning path
  → Defined milestones
  → Assessment at each stage

✓ Blended learning
  → Mix of self-paced and instructor-led
  → Videos, docs, hands-on practice
  → Live Q&A sessions

✓ Gradual ramp
  → Don't throw into queue day 1
  → Shadowing before handling
  → Supervised before independent

✓ Assigned mentor
  → Go-to person for questions
  → Regular check-ins
  → Safe space to learn

✓ Early feedback
  → Weekly 1:1s during onboarding
  → QA on all tickets initially
  → Course corrections early

Bad Onboarding Practices

✗ Drink from firehose
  → Too much info in week 1
  → Retention is minimal

✗ Sink or swim
  → "Here's the queue, good luck"
  → Mistakes damage customer experience

✗ Tribal knowledge only
  → Learn from whoever's around
  → Inconsistent information

✗ No documentation
  → "Ask Sarah about that"
  → Single points of failure

✗ Same for everyone
  → Experienced hires treated like new grads
  → New grads expected to know basics

✗ Training then forgotten
  → No ongoing development
  → Skills stagnate

Product Training Curriculum

Soft Skills Training

Training Content Types

Certification Program

Certification Levels:

LEVEL 1: Foundational (Week 8)
├── Product fundamentals
├── Core tools proficiency
├── Basic troubleshooting
└── Assessment: 80% quiz + 75% QA

LEVEL 2: Proficient (Month 4)
├── Advanced features
├── Integration knowledge
├── Complex troubleshooting
└── Assessment: 85% quiz + 85% QA + case study

LEVEL 3: Specialist (Month 8+)
├── Deep specialty area
├── Escalation handling
├── Mentoring capability
└── Assessment: 90% quiz + 90% QA + presentation

LEVEL 4: Expert (Year 2+)
├── Cross-functional knowledge
├── Process improvement
├── Training delivery
└── Assessment: Peer review + manager recommendation

Ongoing Training Program

Knowledge Assessment Methods

Training Metrics

Mentor Program

Mentor Responsibilities:
├── Daily check-in during onboarding
├── Answer questions without judgment
├── Review first 20 tickets together
├── Provide feedback on approach
├── Escalate concerns to manager
└── Be available for ad-hoc support

Mentor Selection:
├── 6+ months tenure
├── QA score 85+
├── Interest in developing others
├── Patient communication style
└── Time allocated for mentoring

Training Resources Checklist

Documentation:
□ Product documentation (internal and customer-facing)
□ Troubleshooting guides
□ Process documentation
□ FAQ and common issues
□ Escalation procedures

Tools:
□ LMS or training platform
□ Product sandbox/test environment
□ Recording/video tools
□ Quiz/assessment platform
□ Knowledge base

People:
□ Assigned mentor
□ Training facilitators
□ Subject matter experts for sessions
□ Manager for 1:1s

Career Development Paths

                    ┌─────────────────┐
                    │  Support Agent  │
                    └────────┬────────┘
                             │
         ┌───────────────────┼───────────────────┐
         ▼                   ▼                   ▼
  ┌─────────────┐    ┌─────────────────┐   ┌──────────────┐
  │ Specialist  │    │ Team Lead/Mgr   │   │ Trainer      │
  │ Track       │    │ Track           │   │ Track        │
  ├─────────────┤    ├─────────────────┤   ├──────────────┤
  │ L2 Specialist│   │ Team Lead       │   │ Training Spec│
  │ L3 Engineer │    │ Support Manager │   │ Enablement   │
  │ Solutions   │    │ Support Director│   │ Trainer Lead │
  │ Architect   │    │ VP Support      │   │ Content Lead │
  └─────────────┘    └─────────────────┘   └──────────────┘

Common Onboarding Mistakes

Anti-Patterns

• Training as checkbox — Completed but not learned
• Firehose approach — All information in week 1
• No hands-on practice — Reading without doing
• Tribal knowledge only — "Ask Bob"
• One-time training — No ongoing development
• Ignoring soft skills — Technical only
• No assessment — Assume learning happened
• Senior agent = trainer — Good agent ≠ good teacher

---

title: Escalation Procedures & Severity Definitions impact: CRITICAL tags: escalation, severity, incident, on-call, war-room, crisis

Escalation Procedures & Severity Definitions

Impact: CRITICAL

Clear escalation procedures ensure critical issues reach the right people fast. Vague severity definitions lead to under-escalation (customers suffer) or over-escalation (alert fatigue). Get this right and crises become manageable incidents.

Severity Level Definitions

Severity Decision Matrix

                    ┌─────────────────────────────────────┐
                    │            USERS AFFECTED           │
                    ├──────────┬──────────┬───────────────┤
                    │ One User │ Multiple │ All Users     │
┌───────────────────┼──────────┼──────────┼───────────────┤
│ Complete Block    │   SEV3   │   SEV2   │     SEV1      │
├───────────────────┼──────────┼──────────┼───────────────┤
│ Major Impairment  │   SEV4   │   SEV3   │     SEV2      │
├───────────────────┼──────────┼──────────┼───────────────┤
│ Minor Impairment  │   SEV5   │   SEV4   │     SEV3      │
└───────────────────┴──────────┴──────────┴───────────────┘

Escalation Paths by Severity

Escalation Response Requirements

Good Escalation Practices

✓ Clear severity criteria
  → Written definitions with examples
  → Decision tree for ambiguous cases
  → Regular calibration across team

✓ No-blame escalation culture
  → Better to escalate than miss
  → Learning from near-misses
  → Celebrate good catches

✓ Context travels with escalation
  → Full ticket history
  → Troubleshooting already done
  → Customer impact documented

✓ Defined communication templates
  → Internal update format
  → Customer communication format
  → Status page update process

✓ Post-incident review
  → Every SEV1/SEV2 gets review
  → Blameless root cause analysis
  → Action items tracked to completion

Bad Escalation Practices

✗ Escalation as punishment
  → "You should have handled this"
  → Agents afraid to escalate

✗ No severity definitions
  → Everything is SEV1 or nothing is
  → Inconsistent customer experience

✗ Escalation black holes
  → Tickets go up, never come back
  → Engineering ignores queue

✗ Context-free handoffs
  → "It's broken" with no details
  → Customer re-explains 3 times

✗ No update cadence
  → Customer in the dark
  → Internal teams unaware

✗ Skip-level escalations
  → Everyone emails the CEO
  → Process bypassed

On-Call Structure

On-Call Rotation Best Practices

Rotation Schedule:
├── 1-week rotations (not longer)
├── Minimum 2 people per rotation
├── Time zone coverage consideration
├── Holidays covered and compensated
└── Handoff at consistent time (e.g., Monday 9am)

On-Call Expectations:
├── Respond to page within 5 minutes
├── Acknowledge or escalate within 15 minutes
├── Laptop and internet access required
├── Not impaired (alcohol, etc.)
└── Backup coverage for personal conflicts

Incident Command Structure (SEV1/SEV2)

War Room Protocol (SEV1)

Initiation (0-15 minutes):
□ Page on-call and backup
□ Open incident bridge (Zoom/Slack)
□ Assign Incident Commander
□ Initial impact assessment
□ Post to status page

Active Incident:
□ Update status page every 15 minutes
□ Scribe maintains timeline
□ IC coordinates investigation
□ Parallel workstreams if needed
□ All changes announced before made

Resolution:
□ Confirm customer impact resolved
□ Update status page to resolved
□ Send all-clear internally
□ Draft customer communication
□ Schedule post-incident review

Customer Communication Templates

SEV1 - Initial Notification:

Subject: [Service Name] - Service Disruption

We are currently experiencing an issue affecting [description].

Impact: [What customers are experiencing]
Status: Our team is actively investigating
Next Update: Within 30 minutes

We apologize for the inconvenience and will keep you updated.

[Link to status page]

SEV1 - Resolution:

Subject: [Service Name] - Issue Resolved

The issue affecting [description] has been resolved.

Duration: [Start time] to [End time]
Impact: [What was affected]
Resolution: [Brief explanation]

We apologize for any inconvenience caused. A detailed
post-incident report will be shared within 48 hours.

[Link to status page]

Internal Escalation Template

## Escalation Summary

**Severity:** [SEV1/2/3/4]
**Time Detected:** [Timestamp]
**Escalated By:** [Name]
**Escalated To:** [Name/Team]

### Issue Description
[2-3 sentences describing the problem]

### Customer Impact
- Affected customers: [Number or percentage]
- Impact type: [Outage/Degradation/Error]
- Customer-facing symptoms: [What they're seeing]

### Investigation So Far
- [Step 1] → [Result]
- [Step 2] → [Result]
- [Current hypothesis]

### Immediate Actions Needed
1. [Action 1]
2. [Action 2]

### Communication Status
- Status page: [Updated/Pending]
- Customer notification: [Sent/Pending/Not needed]
- Internal channel: [Posted in #channel]

Post-Incident Review Template

## Post-Incident Review: [Incident Title]

**Date:** [Date]
**Duration:** [Start to End]
**Severity:** [SEV level]
**Incident Commander:** [Name]

### Summary
[1-2 paragraph summary of what happened]

### Timeline
- [HH:MM] First customer report
- [HH:MM] On-call paged
- [HH:MM] Incident declared
- [HH:MM] Root cause identified
- [HH:MM] Fix deployed
- [HH:MM] Customer impact resolved

### Impact
- Customers affected: [Number]
- Duration of impact: [Time]
- Revenue impact: [If applicable]
- SLA impact: [Breaches if any]

### Root Cause
[Technical explanation of what went wrong]

### What Went Well
- [Positive 1]
- [Positive 2]

### What Could Be Improved
- [Improvement 1]
- [Improvement 2]

### Action Items
| Action | Owner | Due Date | Status |
|--------|-------|----------|--------|
| [Action 1] | [Name] | [Date] | Open |
| [Action 2] | [Name] | [Date] | Open |

Anti-Patterns

• Severity inflation — Everything is SEV1, real emergencies ignored
• Escalation avoidance — Agents sit on critical issues too long
• Hero culture — One person handles all incidents alone
• No post-mortems — Same issues repeat without learning
• Customer last — Internal comms before customer updates
• War room theater — 50 people on a call, 3 doing work
• Blame-focused reviews — "Who did this?" instead of "How do we prevent?"
• On-call burnout — Same people always on call, no rotation

---

title: Support-to-CS Feedback Loops impact: HIGH tags: feedback, voice-of-customer, product-feedback, handoffs, insights

Support-to-CS Feedback Loops

Impact: HIGH

Support is on the front lines of customer experience. Every ticket is a data point. When feedback flows to CS, Product, and Engineering, the entire organization improves. When it doesn't, support becomes a cost center instead of a strategic asset.

The Feedback Loop Ecosystem

┌─────────────────────────────────────────────────────────────────┐
│                        SUPPORT TEAM                              │
│  Tickets, chats, calls, patterns, sentiment                     │
└──────────────────────────┬──────────────────────────────────────┘
                           │
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
    ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
    │  CUSTOMER   │ │   PRODUCT   │ │ ENGINEERING │
    │   SUCCESS   │ │    TEAM     │ │    TEAM     │
    │             │ │             │ │             │
    │ At-risk     │ │ Feature     │ │ Bug reports │
    │ accounts    │ │ requests    │ │ Priority    │
    │ Expansion   │ │ Pain points │ │ Patterns    │
    │ signals     │ │ Use cases   │ │ Root cause  │
    └─────────────┘ └─────────────┘ └─────────────┘
           │               │               │
           └───────────────┼───────────────┘
                           ▼
              ┌───────────────────────┐
              │   IMPROVED PRODUCT    │
              │   BETTER EXPERIENCE   │
              │   REDUCED TICKETS     │
              └───────────────────────┘

Feedback Types

Good Feedback Loop Practices

✓ Structured capture
  → Standard fields for feedback type
  → Linked to customer and ticket
  → Searchable and reportable

✓ Regular synthesis
  → Weekly top themes shared
  → Monthly trend analysis
  → Quarterly deep dives

✓ Closed loop
  → Product responds to feedback
  → Support informed of outcomes
  → Customer notified when fixed

✓ Cross-functional visibility
  → Product sees real customer words
  → Engineering understands impact
  → CS sees patterns before escalation

✓ Metrics on feedback impact
  → Tickets reduced by product fixes
  → NPS improved by changes
  → Feature adoption from requests

Bad Feedback Loop Practices

✗ Feedback graveyard
  → Collected but never reviewed
  → No one reads the reports

✗ Lost in translation
  → Support paraphrases poorly
  → Customer voice lost

✗ One-way communication
  → Product never responds
  → "We'll pass it along" forever

✗ No aggregation
  → Individual tickets, no patterns
  → Same issue reported 100 times separately

✗ Credit hoarding
  → "This was my idea"
  → Collaboration suffers

Support-to-CS Handoff Triggers

At-Risk Account Alert Template

## At-Risk Alert: [Account Name]

**Date:** [Date]
**Flagged By:** [Support Agent]
**CSM:** [CSM Name]
**Account Tier:** [Tier]
**MRR:** [Amount]

### Risk Indicators
- [Indicator 1: e.g., "3 escalations in past 2 weeks"]
- [Indicator 2: e.g., "Champion expressing frustration"]
- [Indicator 3: e.g., "Mentioned evaluating competitors"]

### Recent Ticket Summary
| Ticket | Date | Issue | Status |
|--------|------|-------|--------|
| #1234 | [Date] | [Issue] | [Status] |
| #1235 | [Date] | [Issue] | [Status] |

### Customer Sentiment
[Direct quotes from recent tickets showing frustration]

### Recommended Actions
1. [Suggested CS intervention]
2. [Suggested exec outreach if needed]
3. [Product team involvement if needed]

### Supporting Links
- [Link to customer account]
- [Link to tickets]
- [Link to health score]

Product Feedback Submission

## Product Feedback: [Brief Title]

**Feedback Type:** [Feature Request / Bug / UX Issue / Other]
**Submitted By:** [Support Agent]
**Date:** [Date]

### Customer Context
- Customers requesting: [Number]
- Segments: [Enterprise/SMB/Startup]
- Revenue represented: [$ or %]
- Notable accounts: [Names if relevant]

### The Request
[Clear description of what customers are asking for]

### Customer Voice
> [Direct quote from customer 1]

> [Direct quote from customer 2]

### Use Case
[Why customers need this, what problem it solves]

### Current Workaround
[How customers are working around this today, if any]

### Business Impact
- Churn risk: [Low/Medium/High]
- Expansion blocker: [Yes/No]
- Competitive gap: [Yes/No]

### Related Tickets
- [Link to ticket 1]
- [Link to ticket 2]

Weekly Voice of Customer Report

## Voice of Customer: Week of [Date]

### Top Themes This Week

**1. [Theme 1]** — [X] tickets
   Impact: [High/Medium/Low]
   Sample: "[Customer quote]"
   Action: [Assigned to Product/Eng/None yet]

**2. [Theme 2]** — [X] tickets
   Impact: [High/Medium/Low]
   Sample: "[Customer quote]"
   Action: [Assigned to Product/Eng/None yet]

**3. [Theme 3]** — [X] tickets
   Impact: [High/Medium/Low]
   Sample: "[Customer quote]"
   Action: [Assigned to Product/Eng/None yet]

### Bug Impact
| Bug | Tickets | Customers | Est. Resolution |
|-----|---------|-----------|-----------------|
| [Bug 1] | [X] | [Y] | [Date/Unknown] |
| [Bug 2] | [X] | [Y] | [Date/Unknown] |

### Feature Requests Trending
1. [Feature] — [X] requests
2. [Feature] — [X] requests

### Wins This Week
- [Positive feedback or success story]

### At-Risk Accounts Flagged
- [Account 1] — [CSM notified]
- [Account 2] — [CSM notified]

### Ticket Trends
- Total tickets: [X] ([+/-]% vs last week)
- Avg CSAT: [X] ([+/-] vs last week)
- Top category: [Category]

Cross-Functional Meetings

Measuring Feedback Loop Effectiveness

Technology for Feedback Loops

Anti-Patterns

• Feedback theater — Collected but ignored
• Lost customer voice — Paraphrased beyond recognition
• Siloed insights — Support knows things no one else does
• Feature factory — Building what's loudest, not what's important
• Blame forwarding — "Product needs to fix this" without partnership
• No closed loop — Customer never hears outcome
• Anecdote over data — One customer drives roadmap
• Handoff and forget — CS gets alert, support never follows up

---

title: Knowledge Base & Self-Service Strategy impact: HIGH tags: knowledge-base, self-service, deflection, documentation, help-center

Knowledge Base & Self-Service Strategy

Impact: HIGH

A well-maintained knowledge base deflects 30-50% of support tickets while improving customer satisfaction. Customers prefer instant answers over waiting for human responses. Self-service is a win-win when done right.

The Self-Service Hierarchy

┌─────────────────────────────────────────────────────────────────┐
│                      IN-APP CONTEXTUAL HELP                      │
│  Tooltips, inline guidance, smart suggestions at point of need  │
│  Deflection: Highest | Effort: Lowest                           │
├─────────────────────────────────────────────────────────────────┤
│                          CHATBOT / AI                            │
│  Instant answers, guided troubleshooting, intelligent routing   │
│  Deflection: High | Personalization: Medium                     │
├─────────────────────────────────────────────────────────────────┤
│                       KNOWLEDGE BASE                             │
│  Searchable articles, how-to guides, troubleshooting docs       │
│  Deflection: Medium-High | Depth: High                          │
├─────────────────────────────────────────────────────────────────┤
│                      COMMUNITY FORUMS                            │
│  Peer-to-peer help, discussions, shared solutions               │
│  Deflection: Medium | Engagement: High                          │
├─────────────────────────────────────────────────────────────────┤
│                        VIDEO TUTORIALS                           │
│  Visual guides, product walkthroughs, feature deep-dives        │
│  Deflection: Medium | Learning: High                            │
└─────────────────────────────────────────────────────────────────┘

Knowledge Base Metrics

Good Knowledge Base Structure

✓ Clear information architecture
  → Logical categories that match user mental models
  → Max 3 levels deep
  → Featured/popular articles visible

✓ Search-first design
  → Prominent search bar
  → Synonym support
  → Suggested articles while typing

✓ Scannable content
  → Clear headings and subheadings
  → Bullet points and numbered lists
  → TL;DR at the top

✓ Visual aids
  → Screenshots with annotations
  → Video embeds for complex processes
  → GIFs for quick demonstrations

✓ Actionable troubleshooting
  → Problem → Cause → Solution format
  → Step-by-step instructions
  → "If this doesn't work, try..." fallbacks

✓ Cross-linking
  → Related articles linked
  → Prerequisites linked
  → Next steps suggested

Bad Knowledge Base Design

✗ Buried search
  → Categories-first navigation
  → Users can't find search

✗ Technical jargon
  → Internal terminology
  → No plain language

✗ Wall of text
  → No formatting or structure
  → Users give up reading

✗ Outdated content
  → Screenshots don't match UI
  → Steps no longer work
  → Confusion and distrust

✗ No feedback mechanism
  → Can't report problems
  → Can't request missing content

✗ Desktop-only
  → Not mobile responsive
  → Bad mobile experience

Article Template

# [Task User Wants to Accomplish]

[1-2 sentence summary of what this article covers]

## Quick Answer
[TL;DR - the most common solution in 1-2 sentences]

## Before You Start
- [Prerequisite 1]
- [Prerequisite 2]

## Step-by-Step Instructions

### Step 1: [Action]
[Description of what to do]

[Screenshot with annotation]

### Step 2: [Action]
[Description of what to do]

> **Note:** [Important callout if needed]

### Step 3: [Action]
[Description of what to do]

## Troubleshooting

**Problem:** [Common issue]
**Solution:** [How to fix]

**Problem:** [Another common issue]
**Solution:** [How to fix]

## Related Articles
- [Link to related article 1]
- [Link to related article 2]

## Still Need Help?
[Contact support CTA]

---
*Last updated: [Date] | Was this article helpful? [Yes] [No]*

Content Categories

Deflection Strategies

Content Maintenance Workflow

Measuring Self-Service ROI

Ticket Deflection Value:
─────────────────────────
Deflected Tickets = KB Visits × Deflection Rate
Savings = Deflected Tickets × Cost Per Ticket

Example:
10,000 monthly KB visits × 35% deflection = 3,500 deflected tickets
3,500 × $15 per ticket = $52,500/month saved

Knowledge Creation from Support

Search Optimization

Good Search Practices:
├── Use customer language, not internal terms
├── Add synonyms and alternate phrasings
├── Include common misspellings
├── Tag with related topics
├── Optimize titles for search
└── Include question-format titles (How do I...?)

Search Analytics to Monitor:
├── Top searches (are we covering these?)
├── Zero-result searches (content gaps)
├── Search refinements (poor initial results)
├── Exit after search (didn't find answer)
└── Ticket creation after search (deflection failure)

Chatbot Integration

Anti-Patterns

• Write once, never update — Stale content worse than no content
• Internal voice — Writing for support team, not customers
• No search analytics — Flying blind on content gaps
• Support as gatekeepers — Hiding KB behind login
• Article graveyards — Thousands of articles, none maintained
• All or nothing chatbot — Bot handles everything or nothing
• Duplicate content — Same info in multiple places, different versions
• No escalation path — Self-service dead end, can't reach human

---

title: Support Metrics (CSAT, FRT, TTR, FCR) impact: HIGH tags: metrics, CSAT, FRT, TTR, FCR, NPS, analytics, performance

Support Metrics (CSAT, FRT, TTR, FCR)

Impact: HIGH

What gets measured gets managed. The right metrics drive the right behaviors. Wrong metrics create perverse incentives. Support metrics should measure customer outcomes, not just agent activity.

Core Metrics Overview

Metric Formulas

CSAT = (Satisfied Responses / Total Responses) × 100
Target: 90%+ | Warning: <85%

FRT = Sum(First Response Times) / Total Tickets
Target: <1 hour | Warning: >4 hours

TTR = Sum(Resolution Times) / Total Resolved Tickets
Target: <24 hours | Warning: >72 hours

FCR = (Tickets Resolved on First Contact / Total Tickets) × 100
Target: 70%+ | Warning: <50%

NPS = % Promoters (9-10) - % Detractors (0-6)
Target: 30+ | Warning: <10

Reopen Rate = (Reopened Tickets / Resolved Tickets) × 100
Target: <5% | Warning: >10%

The Metrics Hierarchy

┌─────────────────────────────────────────────────────────────────┐
│                     BUSINESS OUTCOMES                            │
│  Customer retention, expansion, advocacy, cost efficiency        │
├─────────────────────────────────────────────────────────────────┤
│                     CUSTOMER EXPERIENCE                          │
│  CSAT, NPS, CES, Customer Lifetime Value                         │
├─────────────────────────────────────────────────────────────────┤
│                     OPERATIONAL METRICS                          │
│  FRT, TTR, FCR, SLA compliance, backlog, escalation rate        │
├─────────────────────────────────────────────────────────────────┤
│                     ACTIVITY METRICS                             │
│  Tickets handled, handle time, utilization, replies per ticket  │
└─────────────────────────────────────────────────────────────────┘

Good Metric Practices

✓ Measure outcomes, not just activity
  → CSAT over tickets closed
  → FCR over speed alone
  → Quality over quantity

✓ Context with metrics
  → Segment by ticket type
  → Compare similar complexity
  → Account for team differences

✓ Balanced scorecard
  → Speed + Quality + Volume
  → No single metric obsession
  → Trade-offs acknowledged

✓ Agent-level + Team-level
  → Individual accountability
  → Team collaboration visible
  → Neither in isolation

✓ Regular calibration
  → Define what "good" looks like
  → Review outliers
  → Adjust targets based on data

Bad Metric Practices

✗ Vanity metrics
  → "We closed 1000 tickets!"
  → (But 400 were reopened)

✗ Speed at all costs
  → Racing to respond/close
  → Quality sacrificed

✗ Gaming the system
  → Closing to hit targets
  → Solving easy tickets only
  → Marking pending to pause clock

✗ Metrics without context
  → Comparing unlike tickets
  → Ignoring complexity factors

✗ Punishment-focused
  → Metrics used to punish
  → Fear-based culture
  → Hide problems instead of solve

✗ Single metric obsession
  → Optimize FRT, ignore quality
  → Hit FCR, don't escalate (badly)

CSAT Deep Dive

CSAT Survey Best Practices:

✓ Send within 24 hours of resolution
✓ Keep survey short (1-3 questions)
✓ Include open-ended comment field
✓ Follow up on low scores within 24 hours
✓ Track CSAT by agent, category, complexity

Sample Survey:
1. How satisfied are you with your support experience? (1-5)
2. [Optional] What could we have done better?
3. [Optional] Anything else you'd like to share?

Agent Performance Dashboard

Team Performance Dashboard

Quality Assurance Scoring

Sample QA Rubric:

□ Greeting was professional and personalized
□ Issue was correctly understood and restated
□ Troubleshooting was logical and complete
□ Solution was correct and clearly explained
□ Next steps were provided
□ Ticket was properly categorized and documented
□ Tone was empathetic and appropriate
□ Handle time was reasonable for complexity

Reporting Cadence

Benchmarks by Company Stage

Diagnosing Metric Problems

Metric Improvement Playbook

CSAT Improvement:
1. Analyze low-score tickets for patterns
2. Implement service recovery for 1-2 scores
3. Train on communication and empathy
4. Add quality checkpoints before closure
5. Recognize and share high-CSAT behaviors

FCR Improvement:
1. Identify common escalation reasons
2. Create KB articles for top escalations
3. Train L1 on frequently escalated topics
4. Empower L1 with more resolution authority
5. Add decision trees for complex issues

Anti-Patterns

• CSAT gaming — Only surveying easy tickets
• FRT racing — Copy-paste first response to hit metric
• Premature closure — Closing to hit TTR, causing reopens
• FCR inflation — Not escalating when you should
• Metric of the month — Constantly changing focus
• Comparison without context — Ignoring ticket complexity
• Activity over outcomes — Celebrating tickets closed, not problems solved
• Individual over team — Missing collaborative behaviors

---

title: Quality Assurance & Agent Coaching impact: HIGH tags: quality, QA, coaching, training, performance, reviews

Quality Assurance & Agent Coaching

Impact: HIGH

Quality assurance ensures consistent, excellent customer experiences. Without QA, agent performance varies wildly and issues go undetected. Done right, QA is a coaching tool that elevates the entire team.

The QA Framework

┌─────────────────────────────────────────────────────────────────┐
│                    QUALITY MEASUREMENT                           │
│  Ticket reviews, score tracking, trend analysis                 │
└──────────────────────────┬──────────────────────────────────────┘
                           │
           ┌───────────────┼───────────────┐
           ▼               ▼               ▼
    ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
    │  INDIVIDUAL │ │    TEAM     │ │   PROCESS   │
    │   COACHING  │ │   TRENDS    │ │ IMPROVEMENT │
    │             │ │             │ │             │
    │ 1:1 feedback│ │ Common gaps │ │ KB updates  │
    │ Training    │ │ Best sharing│ │ Tool fixes  │
    │ Development │ │ Calibration │ │ Workflow    │
    └─────────────┘ └─────────────┘ └─────────────┘
                           │
                           ▼
              ┌───────────────────────┐
              │  IMPROVED CUSTOMER    │
              │     EXPERIENCE        │
              └───────────────────────┘

QA Scorecard Dimensions

Detailed Scoring Rubric

Solution Quality (30 points)

30: Perfect - Correct, complete, first-time resolution
25: Good - Correct, minor details missing
20: Adequate - Mostly correct, needed follow-up
15: Needs Work - Partially correct, customer confused
10: Poor - Wrong solution, customer frustrated
0:  Fail - Critical error, escalation required

Communication (25 points)

25: Excellent - Clear, warm, professional, personalized
20: Good - Clear and professional, minimal personalization
15: Adequate - Understandable, somewhat impersonal
10: Needs Work - Confusing or too casual/formal
5:  Poor - Unclear, rude, or unprofessional
0:  Fail - Inappropriate, offensive, or damaging

Process Adherence (20 points)

20: Perfect - All procedures followed, complete documentation
15: Good - Minor documentation gaps
10: Adequate - Some steps skipped, functional documentation
5:  Needs Work - Multiple steps skipped
0:  Fail - Critical process violation

Efficiency (15 points)

15: Excellent - Optimal time for complexity level
12: Good - Slightly over/under optimal time
9:  Adequate - Noticeably inefficient but reasonable
6:  Needs Work - Significant time waste
3:  Poor - Extreme inefficiency or rushing
0:  Fail - SLA breach due to handling

Customer Experience (10 points)

10: Delightful - Went above and beyond
8:  Good - Met expectations, professional
6:  Adequate - Functional, impersonal
4:  Needs Work - Customer had to work hard
2:  Poor - Frustrating experience
0:  Fail - Customer explicitly complained

Good QA Practices

✓ Random sampling
  → Representative ticket mix
  → Multiple categories reviewed
  → Both good and problematic tickets

✓ Calibrated reviewers
  → Regular calibration sessions
  → Same ticket, compare scores
  → Align on standards

✓ Timely feedback
  → Reviews within 48 hours
  → Coaching within a week
  → Real-time flags for critical issues

✓ Growth-focused
  → Celebrate improvements
  → Actionable feedback
  → Development plans

✓ Data-driven
  → Track trends over time
  → Identify systemic issues
  → Measure improvement

Bad QA Practices

✗ Gotcha culture
  → Looking for mistakes to punish
  → Agents fear QA

✗ Inconsistent standards
  → Different reviewers, different scores
  → No calibration

✗ Delayed feedback
  → Reviews from months ago
  → Issues already repeated

✗ Score obsession
  → Number without context
  → No coaching conversation

✗ Cherry-picking
  → Only reviewing easy tickets
  → Missing complex cases

✗ No positive feedback
  → Only hear about problems
  → Demotivating

QA Review Workflow

Weekly QA Process:
┌─────────────────────────────────────────────────────────────────┐
│ Day 1-2: Ticket Selection                                        │
│  □ Pull random sample (3-5 tickets per agent)                   │
│  □ Include mix of categories and complexity                     │
│  □ Add any flagged tickets from previous week                   │
├─────────────────────────────────────────────────────────────────┤
│ Day 3-4: Review and Score                                        │
│  □ Apply scorecard to each ticket                               │
│  □ Document specific feedback points                            │
│  □ Flag exceptional (good or bad) examples                      │
├─────────────────────────────────────────────────────────────────┤
│ Day 5: Calibration and Coaching                                  │
│  □ Calibration meeting with reviewers                           │
│  □ Share scores and feedback with agents                        │
│  □ Schedule 1:1 coaching for low scores                         │
└─────────────────────────────────────────────────────────────────┘

Sample Size Guidelines

Calibration Session Format

Monthly Calibration (1 hour):
1. Pre-work: All reviewers score same 3 tickets
2. Compare scores and discuss differences
3. Align on correct interpretation of rubric
4. Update guidelines if needed
5. Document decisions for reference

Calibration Metrics:
- Score variance should be <5 points
- Major discrepancies discussed until aligned
- Track calibration quality over time

Coaching Conversation Template

## 1:1 Coaching: [Agent Name]

**Date:** [Date]
**Review Period:** [Dates]
**Average QA Score:** [X/100]

### Strengths (Lead with positives)
- [Specific strength with example]
- [Another strength with example]

### Ticket Review
Let's look at [Ticket #X] together...
- What went well: [Specific feedback]
- Opportunity: [Specific feedback]

### Development Focus
This week, let's focus on: [One specific area]
- Why it matters: [Impact explanation]
- How to improve: [Specific actions]
- Resources: [Training, shadowing, documentation]

### Goals for Next Week
1. [Specific, measurable goal]
2. [Specific, measurable goal]

### Follow-up
- Next 1:1: [Date]
- Check-in on: [Specific item]

Common Coaching Scenarios

Performance Improvement Plan

## Performance Improvement Plan: [Agent Name]

**Start Date:** [Date]
**Review Date:** [30/60/90 days out]
**Manager:** [Name]

### Current Performance
- QA Score: [X/100] (vs team avg [Y/100])
- Specific concerns:
  - [Issue 1]
  - [Issue 2]

### Performance Standards Required
- QA Score: [Target, e.g., 80+]
- CSAT: [Target]
- Handle time: [Target]

### Support Provided
- Weekly 1:1 coaching
- Buddy system with [Name]
- Additional training: [Specific courses]
- Reduced ticket load for [X weeks]

### Milestones
- Week 2: [Milestone and measure]
- Week 4: [Milestone and measure]
- Week 6: [Milestone and measure]
- Week 8: [Final review]

### Success Criteria
[Clear definition of what success looks like]

### Signatures
Agent: ________________  Date: _______
Manager: _______________  Date: _______

QA Metrics Dashboard

Recognition Program

Excellence Recognition:
├── Weekly: "Ticket of the Week" - shared in team meeting
├── Monthly: Top performer award - tangible recognition
├── Quarterly: Quality champion - career development opportunity

Peer Recognition:
├── Shout-outs in Slack
├── Best practice sharing
├── Mentorship opportunities

Anti-Patterns

• Punitive QA — Used for discipline, not development
• Score inflation — Everyone gets 90+, no differentiation
• Random rubric — Different scores for same quality
• Feedback void — Scores given, never discussed
• Perfectionism — Only 100% acceptable
• Recency bias — Only recent tickets reviewed
• Volume over quality — Too many reviews, shallow feedback
• Ignoring top performers — Only coaching struggling agents

---

title: SLA Design & Compliance impact: CRITICAL tags: sla, service-level, compliance, response-time, resolution

SLA Design & Compliance

Impact: CRITICAL

Service Level Agreements define customer expectations and team accountability. Well-designed SLAs balance customer needs with operational capacity. Poorly designed SLAs create false promises, stressed agents, and dissatisfied customers.

SLA Components

SLA by Priority Level

SLA by Customer Tier

Good SLA Design

✓ Realistic targets
  → Based on historical data and capacity
  → Buffer for complexity variation
  → Achievable 95% of the time

✓ Clear definitions
  → What counts as "response"?
  → What counts as "resolution"?
  → When does clock start/stop?

✓ Business hours clarity
  → Defined time zones
  → Holiday calendars
  → 24/7 for critical only

✓ Escalation automation
  → Warning at 80% of SLA
  → Auto-escalate at breach
  → Visibility to managers

✓ Regular review
  → Monthly SLA performance analysis
  → Adjust based on capacity
  → Customer feedback incorporation

Bad SLA Design

✗ Promise more than you can deliver
  → 15-minute response with 2 agents
  → Creates breach patterns

✗ Same SLA for all priorities
  → P4 tickets block P1 attention
  → Resources misallocated

✗ Vague definitions
  → "We'll get back to you soon"
  → No measurable commitment

✗ 24/7 claims without 24/7 staff
  → SLA breaches overnight/weekends
  → Angry customers Monday morning

✗ No pause mechanism
  → Clock runs while waiting on customer
  → Unfair agent metrics

✗ SLA as punishment
  → Metrics used to penalize, not improve
  → Gaming behavior emerges

SLA Clock Rules

SLA Breach Prevention

SLA Compliance Dashboard

SLA Reporting Cadence

SLA Exception Handling

SLA Template

## [Company Name] Support SLA

### Coverage Hours
Support is available Monday-Friday, 9:00 AM - 6:00 PM [Timezone].
Critical (P1) issues receive 24/7 coverage.

### Response Time Commitments

| Priority | Description | First Response | Resolution Target |
|----------|-------------|----------------|-------------------|
| Critical | System outage | 15 minutes | 4 hours |
| High | Major feature broken | 1 hour | 8 hours |
| Medium | Feature impaired | 4 hours | 24 hours |
| Low | Minor issue | 8 hours | 72 hours |

### Definitions
- **First Response**: Initial acknowledgment from support agent
- **Resolution**: Issue resolved or workaround provided
- **Business Hours**: Clock pauses outside coverage hours (except P1)

### Escalation
Tickets approaching SLA are automatically escalated to team leads.
SLA breaches are reported to management for review.

### Exclusions
SLA does not apply to: feature requests, out-of-scope issues,
or delays caused by customer unresponsiveness.

SLA Implementation Checklist

Design Phase:
□ Analyze historical ticket data
□ Calculate current response/resolution times
□ Set targets based on capacity + 20% buffer
□ Define clear priority criteria
□ Document business hours and holidays
□ Create customer tier matrix

Configuration Phase:
□ Set up SLA policies in help desk
□ Configure clock pause rules
□ Create escalation workflows
□ Build breach notifications
□ Set up reporting dashboards

Launch Phase:
□ Train agents on SLA expectations
□ Communicate SLA to customers
□ Monitor closely for first 2 weeks
□ Adjust unrealistic targets
□ Celebrate compliance wins

Anti-Patterns

• Vanity SLAs — Impressive numbers no one can meet
• Clock manipulation — Pausing for illegitimate reasons
• Resolution without resolution — Closing tickets to hit SLA
• One SLA fits all — Same targets for all ticket types
• SLA without capacity — Promises without staffing to deliver
• Breach normalization — Accepting regular breaches as normal
• Customer tier opacity — Customers don't know their SLA level

---

title: Ticket Management & Prioritization impact: CRITICAL tags: tickets, prioritization, queue, triage, workflow

Ticket Management & Prioritization

Impact: CRITICAL

Effective ticket management is the foundation of support operations. Without proper prioritization and queue management, critical issues get buried, customers wait too long, and agents waste time on low-impact work.

The Ticket Prioritization Matrix

Triage Decision Tree

New Ticket Received
        │
        ▼
Is it a system-wide outage?
    YES → P1 Critical → Immediate escalation
    NO  ↓
        ▼
Is revenue or data at risk?
    YES → P2 High → Priority queue
    NO  ↓
        ▼
Is core functionality blocked?
    YES → P3 Medium → Standard queue
    NO  ↓
        ▼
Is it a how-to or feature request?
    YES → P5 Request → Knowledge base + backlog
    NO  → P4 Low → Low priority queue

Good Ticket Prioritization

✓ Customer impact determines priority
  → Multiple users affected = higher priority
  → Revenue impact = escalated path
  → Severity based on business impact, not loudness

✓ Clear priority definitions
  → Written criteria everyone understands
  → Examples for each level
  → Edge case guidance

✓ Dynamic reprioritization
  → Tickets age into higher priority
  → Customer tier adjusts SLA
  → Pattern detection for trending issues

✓ Fair queue management
  → First-in-first-out within priority
  → No cherry-picking easy tickets
  → Visibility into all queues

✓ Smart auto-assignment
  → Skill-based routing
  → Workload balancing
  → Customer-agent continuity when helpful

Bad Ticket Prioritization

✗ Loudest customer wins
  → Squeaky wheel gets attention
  → Strategic customers ignored

✗ All tickets are P1
  → When everything's urgent, nothing is
  → True emergencies get buried

✗ Manual triage bottleneck
  → Single person assigns all tickets
  → Delays before work begins

✗ Cherry-picking
  → Agents grab easy tickets first
  → Complex issues age indefinitely

✗ No aging escalation
  → Old tickets stay low priority
  → SLA breaches pile up

✗ Priority by customer emotion
  → Angry ≠ urgent
  → Business impact should drive priority

Queue Health Metrics

Ticket Assignment Models

Ticket Field Requirements

Automation Opportunities

Ticket Tagging Strategy

Good Tags:
├── Product area (auth, billing, integrations)
├── Issue type (bug, how-to, feature-request)
├── Root cause (user-error, product-bug, documentation)
├── Outcome (resolved, known-issue, feature-logged)
└── Customer segment (enterprise, startup, trial)

Bad Tags:
├── Agent names
├── One-time-use tags
├── Overlapping meanings
├── Free-form text
└── Too granular (hundreds of rarely-used tags)

Queue Management Checklist

Daily Queue Review:
□ Check P1/P2 tickets first
□ Review aged tickets (>24 hours)
□ Identify trending issues
□ Reassign from OOO agents
□ Balance workload across team

Weekly Queue Review:
□ Analyze backlog trends
□ Review priority accuracy
□ Check for stuck tickets
□ Identify training needs
□ Update automation rules

Anti-Patterns

• Priority inflation — Everything marked P1 to get attention faster
• Queue hiding — Tickets moved to personal views, invisible to team
• Status limbo — Tickets sit "in progress" without updates
• Duplicate sprawl — Same issue creates multiple tickets
• Tag chaos — Inconsistent or excessive tagging
• Assignment hoarding — Agents claim more than they can handle
• Triage delay — New tickets sit unassigned too long

---

title: Support Tier Structure (L1/L2/L3) impact: CRITICAL tags: tier, escalation, L1, L2, L3, skill-routing, specialization

Support Tier Structure (L1/L2/L3)

Impact: CRITICAL

A well-designed tier structure ensures tickets reach the right expertise level efficiently. Too flat and specialists drown in simple questions. Too layered and customers wait through unnecessary handoffs.

The Three-Tier Model

┌─────────────────────────────────────────────────────────────────┐
│                          TIER 3 (L3)                             │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │ Engineering, product, security specialists                  │ │
│  │ Code-level debugging, custom development, architecture     │ │
│  │ Target: <5% of tickets                                     │ │
│  └─────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│                          TIER 2 (L2)                             │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │ Technical specialists, senior support engineers            │ │
│  │ Complex troubleshooting, integrations, edge cases          │ │
│  │ Target: 15-25% of tickets                                  │ │
│  └─────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│                          TIER 1 (L1)                             │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │ Frontline support agents, customer service                 │ │
│  │ Common issues, how-to, documentation, basic troubleshooting│ │
│  │ Target: 60-80% first-contact resolution                    │ │
│  └─────────────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────────┤
│                        TIER 0 (Self-Service)                     │
│  ┌─────────────────────────────────────────────────────────────┐ │
│  │ Knowledge base, chatbots, community, in-app help           │ │
│  │ Instant answers, guided troubleshooting, FAQs              │ │
│  │ Target: 30-50% deflection rate                             │ │
│  └─────────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘

Tier Responsibilities

Tier Metrics by Level

Good Tier Design

✓ Clear escalation criteria
  → Documented triggers for each tier transition
  → No ambiguity about who handles what
  → Decision trees for common scenarios

✓ Skill-based routing
  → Tickets auto-route to right tier
  → Specialists handle specialty topics
  → Generalists handle breadth

✓ Information flows with ticket
  → Full context passes on escalation
  → Customer doesn't re-explain
  → Prior troubleshooting documented

✓ Feedback loops
  → L2/L3 trains L1 on patterns
  → Common escalations become L1 capable
  → Knowledge base grows from escalations

✓ Career progression
  → L1 → L2 → L3 path defined
  → Skills assessment for promotion
  → Training programs at each level

Bad Tier Design

✗ L1 as gatekeepers only
  → No resolution authority
  → Customers forced through hoops

✗ Escalation = handoff
  → Original agent disappears
  → Context lost, customer frustrated

✗ All-or-nothing expertise
  → No middle ground specialists
  → L1 overwhelmed or L3 drowning

✗ Tier hopping
  → L2 bounces back to L1
  → L1 escalates without trying
  → Tickets ping-pong

✗ No escalation documentation
  → Agent intuition only
  → Inconsistent customer experience

✗ L3 as ticket graveyard
  → Engineering never responds
  → Tickets age indefinitely

Escalation Triggers

Escalation Handoff Template

## Escalation Summary

**Ticket ID:** [ID]
**Customer:** [Name] | [Company] | [Tier]
**Original Agent:** [Name]
**Escalation Time:** [Timestamp]

### Issue Summary
[2-3 sentences describing the customer's problem]

### Troubleshooting Completed
- [Step 1] - [Result]
- [Step 2] - [Result]
- [Step 3] - [Result]

### Relevant Information
- Product version: [X.X.X]
- Environment: [Production/Staging]
- Error logs: [Link or attached]
- Screenshots: [Link or attached]

### Why Escalating
[Clear explanation of why L1/L2 cannot resolve]

### Customer Expectation
[What customer expects and timeline discussed]

### Suggested Next Steps
[Agent's hypothesis or recommendation for L2/L3]

Skill-Based Routing Matrix

Tier Staffing Ratios

L3 Engineering Integration

Career Progression Framework

L1 Support Agent (0-12 months)
├── Product knowledge certification
├── Communication skills
├── Basic troubleshooting
└── Ready for L2: 70% FCR, consistent CSAT, technical curiosity

L2 Support Specialist (1-3 years)
├── Advanced technical training
├── Debugging and log analysis
├── Integration expertise
└── Ready for L3: Complex case leadership, mentoring L1

L3 Support Engineer (3+ years)
├── Engineering collaboration
├── Code-level debugging
├── Product feedback influence
└── Paths: Engineering, Support Management, Solutions Architect

Anti-Patterns

• Escalation as avoidance — L1 escalates instead of learning
• L3 bottleneck — Engineering never prioritizes support tickets
• Context-free handoffs — "Here's a ticket" without details
• Tier rigidity — Cannot skip tiers even when obvious
• No cross-training — Tiers operate in silos
• Specialist overload — One person handles all of a specialty
• Escalation shame — Agents afraid to escalate, take too long

---

title: Support Tool Stack Optimization impact: MEDIUM-HIGH tags: tooling, help-desk, zendesk, intercom, freshdesk, integrations, automation

Support Tool Stack Optimization

Impact: MEDIUM-HIGH

The right tool stack amplifies team effectiveness. The wrong stack creates friction, workarounds, and data silos. Optimize for agent efficiency, customer experience, and operational insights.

The Support Technology Stack

┌─────────────────────────────────────────────────────────────────┐
│                     ANALYTICS & BI LAYER                         │
│  Looker, Tableau, Mode, Metabase, native reporting               │
├─────────────────────────────────────────────────────────────────┤
│                      HELP DESK CORE                              │
│  Zendesk, Intercom, Freshdesk, HubSpot Service, Salesforce      │
├─────────┬─────────────┬──────────────┬─────────────┬────────────┤
│ CHAT    │ PHONE       │ KNOWLEDGE    │ AUTOMATION  │ QUALITY    │
│ Intercom│ Aircall     │ Guru         │ Zapier      │ MaestroQA  │
│ Drift   │ Dialpad     │ Notion       │ Workato     │ Klaus      │
│ Crisp   │ Talkdesk    │ Confluence   │ Tray.io     │ Playvox    │
├─────────┴─────────────┴──────────────┴─────────────┴────────────┤
│                    CUSTOMER DATA LAYER                           │
│  CRM (Salesforce, HubSpot), CDP, Product Analytics              │
├─────────────────────────────────────────────────────────────────┤
│                    COMMUNICATION LAYER                           │
│  Email (SendGrid, Postmark), SMS (Twilio), In-app               │
└─────────────────────────────────────────────────────────────────┘

Tool Selection Criteria

Help Desk Platform Comparison

Essential Integrations

Good Tool Stack Design

✓ Single pane of glass
  → All customer context visible in one view
  → No tab-switching to find information
  → CRM + Product + Billing integrated

✓ Automation-first
  → Repetitive tasks automated
  → Routing rules, not manual assignment
  → Macros for common responses

✓ Channel unification
  → Email, chat, phone in one queue
  → Customer history across channels
  → Seamless channel switching

✓ Scalable foundation
  → Can handle 10x volume
  → Easy to add new agents
  → Performance doesn't degrade

✓ Data accessibility
  → Easy reporting and exports
  → API access for custom needs
  → Real-time dashboards

Bad Tool Stack Design

✗ Tool sprawl
  → 10 tools for 5 functions
  → Constant context switching
  → Data in silos

✗ Manual everything
  → Copy-paste between systems
  → No automation rules
  → Human routing all tickets

✗ Channel silos
  → Separate tools for email vs chat
  → No unified customer history
  → Agent retraining per channel

✗ Integration nightmares
  → Custom code breaking
  → No native connectors
  → IT bottleneck for changes

✗ Reporting gaps
  → Can't answer basic questions
  → Excel exports for everything
  → No real-time visibility

Automation Opportunities

Workflow Automation Examples

Auto-Categorization:

IF subject contains "password" OR "login" OR "can't access"
THEN set category = "Authentication"
AND route to "Authentication Team"
AND suggest KB article "Password Reset Guide"

Escalation Automation:

IF priority = "High"
AND status = "Open"
AND hours since created > 2
THEN send Slack alert to #support-escalations
AND add internal note "Approaching SLA breach"
AND assign to on-call manager

CSAT Trigger:

IF status changed to "Resolved"
AND channel != "Internal"
AND not tagged "no-survey"
THEN wait 2 hours
AND send CSAT survey

Macro/Template Best Practices

Agent Workspace Optimization

Ideal Agent View:
┌─────────────────────────────────────────────────────────────────┐
│  Customer Info          │  Ticket Details                       │
│  ─────────────────────  │  ───────────────────────────────────  │
│  Name: John Smith       │  Subject: Cannot export data          │
│  Company: Acme Inc      │  Priority: Medium                     │
│  Plan: Enterprise       │  Status: Open                         │
│  MRR: $5,000           │  Assigned: You                        │
│  Health: At Risk        │  Channel: Email                       │
│  CSM: Jane Doe          │                                       │
├─────────────────────────┤                                       │
│  Recent Tickets (3)     │  Conversation                         │
│  - Export bug (open)    │  ───────────────────────────────────  │
│  - SSO setup (closed)   │  [Customer message]                   │
│  - Pricing Q (closed)   │                                       │
├─────────────────────────┤  [Reply box]                          │
│  Account Activity       │                                       │
│  - Last login: Today    │  Suggested Articles:                  │
│  - Feature use: High    │  - Data Export Guide                  │
│  - NPS: 8 (Passive)     │  - Troubleshooting Exports            │
└─────────────────────────┴───────────────────────────────────────┘

Tool Implementation Checklist

Pre-Implementation:
□ Define requirements and success metrics
□ Evaluate 3+ options with demos
□ Check integration compatibility
□ Calculate total cost of ownership
□ Plan data migration strategy

Implementation:
□ Configure workflows and automations
□ Set up integrations
□ Import historical data
□ Create macros and templates
□ Build reporting dashboards

Training & Launch:
□ Train agents on new workflows
□ Document processes and edge cases
□ Soft launch with subset of tickets
□ Monitor for issues
□ Iterate based on feedback

Post-Launch:
□ Review automation effectiveness
□ Optimize based on usage data
□ Gather agent feedback
□ Regular workflow audits
□ Plan for scale

Cost Optimization

Anti-Patterns

• Shiny object syndrome — Switching tools for new features
• Over-customization — Too complex to maintain
• Under-utilization — Paying for features not used
• Integration debt — Custom code no one understands
• Vendor lock-in — Can't migrate data out
• Agent workarounds — Using Excel because tool doesn't work
• No governance — Everyone creates their own automations
• Metric blindness — Can't measure what matters

---

title: Workforce Management & Capacity Planning impact: MEDIUM-HIGH tags: workforce, capacity, scheduling, forecasting, staffing, utilization

Workforce Management & Capacity Planning

Impact: MEDIUM-HIGH

Right-sizing your support team is a constant balancing act. Too few agents and customers wait too long. Too many and you're burning budget. Workforce management turns ticket volume into staffing decisions.

The Capacity Planning Equation

                    Ticket Volume × Handle Time
Required Agents = ─────────────────────────────────────
                   Available Hours × Utilization Rate

Example:
    500 tickets/day × 20 min/ticket = 10,000 minutes
    8 hours × 60 min × 75% utilization = 360 min/agent/day
    10,000 ÷ 360 = 28 agents needed

Capacity Variables

Utilization Breakdown

Good Workforce Planning

✓ Data-driven forecasting
  → Historical patterns analyzed
  → Seasonality accounted for
  → Growth factored in

✓ Flexible staffing
  → Part-time for peak hours
  → Cross-trained backups
  → Contractor buffer available

✓ Real-time monitoring
  → Queue visibility
  → Quick response to spikes
  → Adjust on the fly

✓ Forward-looking
  → 3-month rolling forecast
  → Hiring lead time included
  → Training time planned

✓ Agent wellbeing
  → Sustainable utilization
  → Predictable schedules
  → Burnout prevention

Bad Workforce Planning

✗ Reactive staffing
  → Hire after crisis
  → Always behind

✗ One-size schedules
  → Same coverage all hours
  → Peaks understaffed

✗ 100% utilization target
  → No buffer for spikes
  → Agent burnout

✗ Ignoring seasonality
  → January staff for December volume
  → Surprised every year

✗ Training as afterthought
  → New hires unproductive for months
  → Existing team can't grow

Forecasting Methods

Seasonal Patterns to Watch

Staffing Model by Channel

Scheduling Best Practices

Schedule Design:
├── Cover peak hours with full staff
├── Stagger start times for coverage
├── Allow schedule preferences within limits
├── Plan for timezone coverage
└── Build in overlap for handoffs

Shift Examples:
├── Early: 6am-2pm (catch Asia-Pacific overlap)
├── Core: 9am-5pm (highest volume)
├── Late: 12pm-8pm (West Coast coverage)
└── Split: 9-1pm + 4-8pm (two peaks)

Schedule Template

Real-Time Management

Hiring Planning

New Hire Ramp Schedule

Capacity Dashboard

Cost Per Ticket Analysis

Full Cost Calculation:
─────────────────────
Agent salary/benefits:     $60,000/year
Tools/systems (per seat):   $5,000/year
Training/development:       $2,000/year
Management overhead:        $8,000/year
Total per agent:          $75,000/year

Tickets per agent/year: 6,000 (25/day × 240 days)

Cost per ticket: $12.50

Reducing handle time by 10% = $1.25/ticket savings
Improving FCR by 5% = 300 tickets avoided = $3,750/agent/year

Capacity Planning Calendar

Monthly:
□ Review previous month actuals vs forecast
□ Update 3-month rolling forecast
□ Adjust schedules for known events
□ Review hiring pipeline status

Quarterly:
□ Deep analysis of volume trends
□ Headcount planning for next 2 quarters
□ Training calendar planning
□ Budget review

Annually:
□ Annual volume forecast
□ Headcount budget request
□ Tool/vendor contract reviews
□ Strategic capacity planning

Scenario Planning

Anti-Patterns

• Heroic unsustainable effort — Team working overtime constantly
• Understaffed normal — Always behind, never catching up
• Over-hiring for peak — Paying for capacity used 10% of time
• Ignoring ramp time — New hires counted as full capacity
• Static schedules — Same coverage regardless of patterns
• Utilization obsession — 95% target burns out team
• No forecast review — Never learning from actuals
• Last-minute scramble — Emergency scheduling constantly