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.