Menu
Customer support workflows — ticket triage, response drafting, knowledge base articles, escalation handling, customer research. Use when triaging support tickets, drafting customer responses, creating KB articles, managing escalations, or researching customer context.
Verify factual claims against sources before publish.
Collect, filter, and freshness-qualify news items.
Generate headlines, titles, and subject lines: charge, volume, tighten.
Generate blog topic ideas: problem mining, gap analysis, expansion.
Create voice profiles from writing samples.
Critique-and-rewrite loop for voice fidelity validation.
| name | customer-support |
| description | Customer support workflows — ticket triage, response drafting, knowledge base articles, escalation handling, customer research. Use when triaging support tickets, drafting customer responses, creating KB articles, managing escalations, or researching customer context. |
| routing | {"triggers":["customer support","ticket triage","support response","knowledge base","KB article","escalation","customer research"],"category":"business","force_route":false,"pairs_with":["csuite"]} |
| user-invocable | true |
Umbrella skill for customer-facing support workflows: triage incoming tickets, draft calibrated responses, convert resolutions into KB articles, package escalations, and research customer context. Each mode loads its own reference files on demand.
Scope: Customer-facing support work. Use professional-communication for internal business formats, csuite for strategic decisions, pr-workflow for code PRs.
Classify the request into exactly one mode. If the request spans modes, choose the primary and note the secondary.
| Mode | Signal Phrases | Core Output |
|---|---|---|
| TRIAGE | New ticket, categorize, prioritize, route, P1-P4, severity, SLA | Structured triage assessment with priority, routing, initial response |
| RESPOND | Draft response, reply to customer, follow up, de-escalate, bad news, decline | Customer-facing message with tone calibration and internal notes |
| KB | Knowledge base, document this, FAQ, write article, how-to guide, troubleshooting doc | Publish-ready KB article with metadata and search optimization |
| ESCALATE | Escalate, engineering attention, SLA breach, churn risk, multiple customers, leadership | Structured escalation brief with impact assessment and repro steps |
| RESEARCH | Look up, investigate, what did we tell them, has this been reported, check history | Research brief with source attribution and confidence scoring |
Load only the references required by the detected mode.
| Mode | Reference |
|---|---|
| TRIAGE | references/triage-methodology.md |
| RESPOND | references/response-drafting.md |
| KB | references/knowledge-base.md |
| ESCALATE | references/triage-methodology.md, references/response-drafting.md |
| RESEARCH | references/knowledge-base.md |
| Any mode | references/llm-support-failure-modes.md (always load -- LLM failure awareness is non-negotiable in support) |
Framework: PARSE -> CLASSIFY -> ROUTE -> RESPOND
Phase 1: PARSE -- Extract the actual problem from the ticket.
Phase 2: CLASSIFY -- Assign category and priority.
Apply the category taxonomy from references/triage-methodology.md:
| Category | When |
|---|---|
| Bug | "It used to work and now it doesn't" |
| How-to | "How do I make it work?" |
| Feature request | "I want it to work differently" |
| Billing | Payment, subscription, invoice, refund |
| Account | Login, permissions, SSO, access |
| Integration | API, webhook, third-party, sync |
| Security | Data exposure, unauthorized access, compliance |
| Performance | Slow, timeout, degraded, unavailable |
Assign priority P1-P4. When in doubt, err higher -- easier to de-escalate than recover from a missed SLA.
| Priority | Criteria | SLA Response |
|---|---|---|
| P1 Critical | Production down, data loss, security breach, all users | 1 hour |
| P2 High | Major feature broken, no workaround, many users | 4 hours |
| P3 Medium | Partial break, workaround exists, small impact | 1 business day |
| P4 Low | Cosmetic, feature request, general question | 2 business days |
Phase 3: ROUTE -- Determine the right team.
| Route to | When |
|---|---|
| Tier 1 | How-to, known issues with docs, billing inquiries, password resets |
| Tier 2 | Bugs needing investigation, complex config, integration troubleshooting |
| Engineering | Confirmed bugs needing code fixes, infrastructure, performance degradation |
| Product | Feature requests with demand, design decisions, workflow gaps |
| Security | Data access concerns, vulnerability reports, compliance (bypasses tier progression) |
Phase 4: RESPOND -- Draft initial response using the category templates from references/triage-methodology.md.
Gate: Triage output includes: category, priority with justification, routing recommendation, suggested initial response, internal notes.
Framework: CONTEXT -> CALIBRATE -> DRAFT -> VERIFY
Phase 1: CONTEXT -- Understand the full situation before writing a word.
Phase 2: CALIBRATE -- Select tone from references/response-drafting.md.
| Situation | Tone | Key Characteristic |
|---|---|---|
| Good news | Celebratory | Forward-looking, enthusiastic |
| Routine update | Professional | Clear, concise, friendly |
| Technical response | Precise | Accurate, patient, structured |
| Delayed delivery | Accountable | Honest, action-oriented |
| Bad news / won't-fix | Candid | Direct, empathetic, alternative-offering |
| Issue / outage | Urgent | Transparent, actionable, reassuring |
| Escalation | Executive | Composed, ownership-taking, plan-presenting |
| Billing | Precise | Factual, resolution-focused |
Adjust by relationship stage:
Phase 3: DRAFT -- Write the response following the structure:
Phase 4: VERIFY -- Run the quality checks before presenting.
Gate: Draft includes internal notes covering: rationale for tone, facts to verify before sending, risk factors, follow-up actions needed.
Framework: SOURCE -> STRUCTURE -> DRAFT -> OPTIMIZE
Phase 1: SOURCE -- Understand what you're documenting.
Phase 2: STRUCTURE -- Choose the right template from references/knowledge-base.md.
| Type | Purpose | Structure |
|---|---|---|
| How-to | Step-by-step task completion | Prerequisites -> Steps -> Verify -> Common Issues |
| Troubleshooting | Diagnose and fix a problem | Symptoms -> Cause -> Solution(s) -> Prevention |
| FAQ | Quick answer to common question | Direct Answer -> Details -> Related Questions |
| Known issue | Document a bug with workaround | Status -> Symptoms -> Workaround -> Fix Timeline |
Phase 3: DRAFT -- Write the article following formatting standards.
Phase 4: OPTIMIZE -- Search optimization and metadata.
Gate: Article includes metadata (title, type, category, tags, audience), full content, publishing notes (source, related articles, review needed, suggested review date).
Framework: CONFIRM -> GATHER -> ASSESS -> PACKAGE
Phase 1: CONFIRM -- Verify this warrants escalation.
Escalate when:
Handle in support when:
Phase 2: GATHER -- Pull together all context.
Phase 3: ASSESS -- Quantify business impact.
| Dimension | Assess |
|---|---|
| Breadth | How many customers/users? Growing? |
| Depth | Blocked vs. inconvenienced? |
| Duration | How long? Getting worse? |
| Revenue | ARR at risk? Deals affected? |
| Contractual | SLA breach? Contractual obligations? |
Severity shorthand:
Phase 4: PACKAGE -- Structure the escalation brief.
Determine target:
Include: severity, target team, impact summary, issue description, what's been tried, reproduction steps, customer communication status, specific ask with deadline, supporting context.
Gate: Escalation brief complete. Follow-up cadence set (Critical: every 2h internal / 2-4h customer. High: every 4h / 4-8h. Medium: daily / 1-2 business days).
Framework: SCOPE -> SEARCH -> SYNTHESIZE -> CAPTURE
Phase 1: SCOPE -- Define what you're looking for.
Research types:
Clarify: factual vs. contextual, audience (internal vs. customer), scope boundaries.
Phase 2: SEARCH -- Work through source tiers systematically.
| Tier | Source Type | Confidence |
|---|---|---|
| 1 | Official docs, KB, policies | High |
| 2 | CRM, support tickets, meeting notes | Medium-High |
| 3 | Chat, email, calendar | Medium |
| 4 | Web, forums, third-party docs | Low-Medium |
| 5 | Inference, analogies, best practices | Low -- flag explicitly |
Cross-reference across multiple sources.
Phase 3: SYNTHESIZE -- Compile findings with attribution.
Phase 4: CAPTURE -- Suggest knowledge preservation.
If the research took significant effort, was a common question, or corrected a misunderstanding, offer to create a KB article or FAQ entry. Knowledge capture prevents duplicate research.
Gate: Research brief includes: direct answer, confidence level, key findings with source attribution, gaps and unknowns, recommended next steps.
These apply regardless of mode. Internalize them.
Empathy is not performance. Acknowledge the customer's situation genuinely. "I understand how frustrating this must be" is fine when they're frustrated. The same phrase when they asked a simple how-to question is patronizing. Match the emotional register. Read references/llm-support-failure-modes.md on tone mismatch.
Own it. Active voice. "We" not "the system." "I'll investigate" not "this will be investigated." Take responsibility where appropriate. Take ownership in all customer-facing communication.
Specificity over reassurance. "I'll update you by Friday at 3pm" beats "I'll get back to you soon." Concrete details build trust. Vague reassurance erodes it.
Close the loop. Every interaction ends with clear next steps: what you will do, what they need to do, when they hear from you next.
Confirm feature existence before stating it. Say 'let me check' when uncertain. A wrong answer that sends a customer down a dead-end path is worse than "let me check and get back to you." See references/llm-support-failure-modes.md.
Limit commitments to actions within your authority. No timeline commitments on behalf of engineering. No policy exceptions without approval. No "we'll definitely build that." The trust cost of a broken promise exceeds the short-term relief of making one.
