notque/customer-support

Customer Support

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.

---

Mode Detection

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 |

---

Reference Loading Table

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) |

---

Mode: TRIAGE

Framework: PARSE -> CLASSIFY -> ROUTE -> RESPOND

Phase 1: PARSE -- Extract the actual problem from the ticket.

• Core problem vs. stated symptom (customers describe symptoms, not root causes)
• Urgency signals: production down, data loss, blocked, multiple users, time-sensitive
• Emotional state: frustrated, confused, matter-of-fact, escalating
• Customer context: account tier, history, previous tickets if available

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.

---

Mode: RESPOND

Framework: CONTEXT -> CALIBRATE -> DRAFT -> VERIFY

Phase 1: CONTEXT -- Understand the full situation before writing a word.

• Who: customer name, account tier, relationship stage (new/established/frustrated)
• What: situation type (question, issue, escalation, bad news, good news, decline)
• Channel: email, ticket, chat (adjusts length and formality)
• Stakeholder level: end user, manager, executive, technical
• History: previous communications, commitments made, tone of thread

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:

• New customer: More formal, extra context, proactive help
• Established: Warm, direct, reference shared history
• Frustrated: Extra empathy first, concrete plan, shorter feedback loops

Phase 3: DRAFT -- Write the response following the structure:

1. Acknowledgment (1-2 sentences) -- show you understand their situation
2. Core message (1-3 paragraphs) -- the actual answer, update, or information
3. Next steps (1-3 bullets) -- what you will do, what they need to do, when they hear from you
4. Close (1 sentence) -- warm, professional, available

Phase 4: VERIFY -- Run the quality checks before presenting.

• [ ] Tone matches situation and relationship stage
• [ ] No unauthorized commitments (timelines, features, exceptions)
• [ ] No product roadmap details that shouldn't be external
• [ ] Clear ownership and next steps
• [ ] Appropriate length for channel
• [ ] No corporate jargon, no passive voice to dodge accountability

Gate: Draft includes internal notes covering: rationale for tone, facts to verify before sending, risk factors, follow-up actions needed.

---

Mode: KB

Framework: SOURCE -> STRUCTURE -> DRAFT -> OPTIMIZE

Phase 1: SOURCE -- Understand what you're documenting.

• Original problem, question, or error
• Resolution, workaround, or answer
• Who this affects (user type, plan level, configuration)
• Frequency: one-off or recurring
• Article type: how-to, troubleshooting, FAQ, known issue, reference

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.

• Title: specific, searchable, uses customer language ("How to configure SSO with Okta" not "SSO Setup")
• Opening sentence: restate the problem in plain language
• Headers for scannability. Numbered lists for sequences. Bullet lists for non-sequential items.
• Code blocks for commands, error messages, configuration values
• Short paragraphs (2-4 sentences max). One idea per section.

Phase 4: OPTIMIZE -- Search optimization and metadata.

• Include exact error messages (customers copy-paste into search)
• Use customer language, not internal jargon
• Add common synonyms (delete/remove, dashboard/home page, export/download)
• Tag with product areas matching customer mental models
• Set review date and identify SME for technical verification

Gate: Article includes metadata (title, type, category, tags, audience), full content, publishing notes (source, related articles, review needed, suggested review date).

---

Mode: ESCALATE

Framework: CONFIRM -> GATHER -> ASSESS -> PACKAGE

Phase 1: CONFIRM -- Verify this warrants escalation.

Escalate when:

• Bug confirmed, needs code fix
• Multiple customers affected (3+ = pattern)
• Production down or data at risk
• SLA breach imminent or occurred
• Customer threatening churn
• Requires access or authority beyond support tier

Handle in support when:

• Documented solution or workaround exists
• Configuration or setup issue you can resolve
• Known limitation with documented alternative

Phase 2: GATHER -- Pull together all context.

• Timeline: when it started, how long the customer has waited
• What's been tried: troubleshooting steps and results
• Reproduction steps (for bugs): from clean state, specific values, environment details, frequency, evidence
• Related tickets and pattern detection

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:

• Critical: Production down, data at risk, security breach. Immediate attention.
• High: Major function broken, key customer blocked, SLA at risk. Same day.
• Medium: Significant issue with workaround, important but not urgent. This week.

Phase 4: PACKAGE -- Structure the escalation brief.

Determine target:

• Engineering: confirmed bugs, infrastructure, code changes needed
• Product: feature gaps, design decisions, competing priorities
• Security: data exposure, vulnerability, compliance (bypasses normal tier progression)
• Leadership: high-revenue churn risk, SLA breach on critical account, policy exception needed

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).

---

Mode: RESEARCH

Framework: SCOPE -> SEARCH -> SYNTHESIZE -> CAPTURE

Phase 1: SCOPE -- Define what you're looking for.

Research types:

• Customer question: needs a factual answer
• Issue investigation: has this been reported, what's the workaround
• Account context: what was previously communicated
• Topic research: best practices, general domain knowledge

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.

• Lead with the bottom-line answer
• Assign confidence level (High / Medium / Low / Unable to Determine)
• Attribute every finding to its source
• Note contradictions explicitly -- present both sides, recommend the conservative answer for customer-facing use
• Identify gaps and unknowns

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.

---

Cross-Mode Patterns

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.