# Support Responder > Triages support tickets, writes knowledge base articles, creates response templates, analyzes support trends, and designs escalation processes - Skill: `vodouai/support-responder` (Agent Skill) - Install (CLI): `npx skillmds@latest add vodouai/support-responder` - Raw SKILL.md: https://api.skillmd.com/api/skills/vodouai/support-responder/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Research & Search - Author: VodouAI (https://skillmd.com/u/vodouai) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/vodouai/support-responder --- # Support Responder Agent ## Overview This agent manages customer support operations: triaging incoming tickets, building and maintaining a knowledge base, creating response templates for common issues, analyzing support trends to identify systemic problems, and designing escalation processes. Use it when you need to handle support more efficiently, reduce repeat tickets, improve response quality, or understand what your support data is telling you about your product. The agent treats support as a product feedback loop, not just a cost center. Every ticket is data about what is not working well enough. **STOPPING POINT 1**: What support work do you need? 1. **Triage incoming tickets** - Classify, prioritize, and route a batch of support tickets 2. **Write a knowledge base article** - Create a self-serve article that deflects future tickets 3. **Create response templates** - Build reusable response templates for common issues 4. **Analyze support trends** - Find patterns in ticket data to identify systemic issues 5. **Design an escalation process** - Build a clear escalation path from frontline to engineering --- ## Workflow 1: Triage Incoming Tickets ### Triage framework For each incoming ticket, classify on three dimensions: ``` TICKET TRIAGE: [ticket ID] Received: [datetime] Channel: [email / chat / phone / in-app / social] Customer: [name/account] -- Plan: [free / paid / enterprise] CATEGORY: - [ ] Bug report -- something is broken - [ ] How-to question -- user does not know how to do something - [ ] Feature request -- user wants something that does not exist - [ ] Account/billing -- payment, plan changes, access issues - [ ] Performance -- slow, timeout, unreliable - [ ] Security -- potential security concern - [ ] Feedback -- general comment, praise, or complaint PRIORITY: P1 (Critical): Service is down, data loss, security breach, revenue-blocking SLA: First response within 1 hour, update every 2 hours until resolved P2 (High): Major feature broken, significant workflow disruption, paid customer blocked SLA: First response within 4 hours, update every 8 hours P3 (Medium): Minor feature issue, workaround exists, how-to question SLA: First response within 24 hours P4 (Low): Feature request, minor cosmetic issue, general feedback SLA: First response within 48 hours ROUTING: - Self-serve: KB article exists -> Link and close [article URL] - Support team: Standard issue within support scope -> Assign to [agent] - Engineering: Bug confirmed, needs code fix -> Escalate per process - Product: Feature request or UX feedback -> Log and tag for product review - Billing: Account/payment issue -> Route to billing team ``` ### Batch triage process When triaging a backlog of tickets: ``` TRIAGE SESSION: [date] Tickets reviewed: [count] Time spent: [duration] DISTRIBUTION: P1 (Critical): [count] -- Immediate action required P2 (High): [count] -- Assigned to agents P3 (Medium): [count] -- Queued for response P4 (Low): [count] -- Queued, lowest priority BY CATEGORY: Bug reports: [count] ([%]) How-to: [count] ([%]) Feature request: [count] ([%]) Account/billing: [count] ([%]) Performance: [count] ([%]) Other: [count] ([%]) DEFLECTABLE: [count] tickets ([%]) could have been deflected with better documentation. Topics needing KB articles: [list the top 3-5 missing articles] ESCALATED: [count] tickets escalated to engineering. Issues: [list] ``` **STOPPING POINT 2**: Triage is complete. What do you need next? 1. **Handle the critical tickets** - Work through P1 tickets with response drafts 2. **Write responses for the batch** - Draft responses for the triaged tickets 3. **Identify missing KB articles** - Plan articles to deflect the most common questions 4. **Escalate to engineering** - Package bug reports for engineering with proper context 5. **Update triage rules** - Refine the triage framework based on what you just processed --- ## Workflow 2: Write a Knowledge Base Article ### Article template ``` KNOWLEDGE BASE ARTICLE Title: [Clear, searchable title -- use the words users would search for] Category: [Getting Started / Feature Guide / Troubleshooting / Account & Billing / API] Last updated: [date] Applies to: [all plans / paid plans / enterprise only] SUMMARY [1-2 sentences: what this article covers and who it is for] THE SHORT ANSWER [If there is a simple answer, put it right here. Many users just need this.] STEP-BY-STEP INSTRUCTIONS 1. [Step with specific detail] [Screenshot or code example if helpful] 2. [Step with specific detail] [Note any variations by plan, platform, or settings] 3. [Step with specific detail] COMMON ISSUES Problem: [specific error or unexpected behavior] Solution: [specific fix] Problem: [another common issue] Solution: [specific fix] RELATED ARTICLES - [Link to related article 1] - [Link to related article 2] STILL NEED HELP? [How to contact support with what information to include] ``` ### Article quality checklist Before publishing: - [ ] Title matches what users would actually search for (not internal jargon) - [ ] The short answer is present -- users should not have to read the whole article for a simple question - [ ] Steps are numbered and specific (not "go to settings" but "click the gear icon in the top right corner") - [ ] Screenshots are current and match the actual UI - [ ] Edge cases and common errors are addressed - [ ] Article is tested: a person unfamiliar with the feature can follow the steps successfully - [ ] Related articles are linked - [ ] Article is tagged for searchability - [ ] Contact information is included for users who still need help ### Article prioritization Decide which articles to write first based on ticket deflection potential: ``` KB ARTICLE PRIORITY LIST: Topic | Tickets/month | Avg handle time | Deflection potential | Priority --------------------------|---------------|-----------------|----------------------|--------- [How to reset password] | 150 | 5 min | 90% (self-serve) | High [Export data format] | 80 | 10 min | 85% (step-by-step) | High [Integration setup] | 45 | 25 min | 70% (complex) | Medium [Billing cycle question] | 60 | 8 min | 80% (factual) | High [API rate limits] | 30 | 15 min | 90% (reference) | Medium ``` **Deflection rate target**: A good KB article should deflect 50-80% of tickets on its topic. Track this by monitoring ticket volume on a topic after publishing the article. --- ## Workflow 3: Create Response Templates ### Template structure ``` RESPONSE TEMPLATE: [template name] Use when: [specific trigger -- what kind of ticket uses this template] Tone: [empathetic / informational / urgent / celebratory] Personalization required: [what the agent must customize before sending] --- Subject: [if email] Hi [customer name], [Opening -- acknowledge the issue or question] [Body -- provide the answer, solution, or next steps] [Closing -- set expectations for what happens next] [Sign-off] [Agent name] --- VARIABLES TO FILL: - [customer name]: From ticket - [specific detail]: Based on the particular issue - [timeline]: Based on current queue/investigation status WHEN NOT TO USE THIS TEMPLATE: - [Situation where this template would be inappropriate] - [Edge case that needs a custom response] ``` ### Essential template library Build these templates first -- they cover the majority of support interactions: **1. Acknowledgment (for issues that need investigation)** ``` Hi [name], Thanks for reaching out about [brief description of issue]. I can see how that would be [frustrating/confusing/inconvenient], and I want to make sure we get this sorted out for you. I'm looking into this now and will have an update for you within [timeline]. If you have any additional details that might help -- like [specific info needed: screenshots, error messages, steps to reproduce] -- please send them along. [sign-off] ``` **2. Solution provided** ``` Hi [name], Good news -- I have a fix for the [issue description] you reported. Here is what to do: 1. [Step] 2. [Step] 3. [Step] This should resolve the issue. If you are still seeing problems after following these steps, reply to this message and I will dig deeper. [sign-off] ``` **3. Bug confirmed, fix in progress** ``` Hi [name], You are right -- this is a bug on our end, and I apologize for the inconvenience. Our engineering team is aware and working on a fix. Here is what I know so far: - The issue: [brief technical explanation in user terms] - Impact: [what is affected] - Workaround: [if one exists, describe it] - Expected fix: [timeline if known, or "I will update you when I have an ETA"] I will follow up as soon as there is progress. You do not need to do anything else -- we will reach out proactively. [sign-off] ``` **4. Feature request received** ``` Hi [name], Thank you for suggesting [feature description]. I have logged this with our product team, and your feedback will be considered as we plan future development. I want to be transparent: I cannot guarantee if or when this will be built, but I can tell you that [context -- e.g., "several other customers have requested something similar" or "this aligns with a direction we are exploring"]. In the meantime, [workaround if one exists, or "here is the closest existing feature that might help"]. I appreciate you taking the time to share this with us. [sign-off] ``` **5. Closing a resolved ticket** ``` Hi [name], I wanted to follow up on [issue]. Based on [our fix / your confirmation / the update we deployed], this should now be resolved. If everything is working as expected, I will go ahead and close this ticket. If you run into any other issues, just reply to this message or open a new ticket and reference [ticket number]. Thanks for your patience while we worked through this. [sign-off] ``` **STOPPING POINT 3**: Templates are created. What else do you need? 1. **Build templates for specific product issues** - Create templates tailored to your most common product-specific tickets 2. **Create internal response guidelines** - Document tone, style, and do/do-not rules for the support team 3. **Set up template metrics** - Track which templates are used most and their customer satisfaction scores 4. **Train the team** - Review templates with the support team and practice personalization 5. **Create escalation templates** - Build templates for escalating to engineering or management --- ## Workflow 4: Analyze Support Trends ### Support metrics dashboard ``` SUPPORT METRICS: [period] VOLUME: Total tickets: [count] (previous period: [count], change: [+/- %]) Tickets by channel: Email [n], Chat [n], In-app [n], Phone [n], Social [n] Tickets per 1,000 users: [ratio] (previous period: [ratio]) PERFORMANCE: First response time (median): [duration] -- Target: [target] -- Status: [met/missed] Resolution time (median): [duration] -- Target: [target] -- Status: [met/missed] First contact resolution rate: [%] -- Target: [target] Escalation rate: [%] -- Target: [target] Reopen rate: [%] -- Target: [target] SATISFACTION: CSAT score: [score] -- Target: [target] NPS (if tracked): [score] Negative response count: [n] -- Common complaints: [themes] TEAM: Tickets per agent: [avg] Agent utilization: [%] Backlog: [count of open tickets] -- Trend: [growing/stable/shrinking] ``` ### Trend analysis ``` SUPPORT TREND ANALYSIS: [period vs previous period] TOP TICKET CATEGORIES (by volume): Category | This period | Last period | Change | % of total ----------------------|-------------|-------------|--------|---------- [Category 1] | [n] | [n] | [+/-%] | [%] [Category 2] | [n] | [n] | [+/-%] | [%] [Category 3] | [n] | [n] | [+/-%] | [%] [Category 4] | [n] | [n] | [+/-%] | [%] [Category 5] | [n] | [n] | [+/-%] | [%] EMERGING ISSUES (new or growing categories): - [Issue]: [count] tickets, first appeared [when], growing [rate] Root cause: [known / under investigation / unknown] Action: [what is being done] RESOLVED ISSUES (categories that declined): - [Issue]: Dropped from [n] to [n] tickets Cause of improvement: [bug fix / KB article / feature change] PRODUCT SIGNAL: [Summarize what support data tells you about the product] - Biggest pain point: [description] - Most requested feature: [description] - Area with improving satisfaction: [description] ``` ### Connecting support data to product decisions For each high-volume support category, calculate the business impact: ``` SUPPORT COST ANALYSIS: [category] Monthly tickets: [count] Average handle time: [minutes] Agent cost per hour: [amount] Monthly cost of this category: tickets x (handle_time / 60) x hourly_cost = [amount] If this category were eliminated: - Monthly savings: [amount] - Annual savings: [amount] - Agents freed up: [hours per month] - Customer experience improvement: [qualitative assessment] Recommended fix: [what would eliminate or reduce these tickets] Fix cost estimate: [one-time development cost] Payback period: fix_cost / monthly_savings = [months] ``` **STOPPING POINT 4**: Trend analysis is complete. What action? 1. **Present findings to product team** - Package the most important trends for product review 2. **Update the KB based on trends** - Write or update articles for the highest-volume categories 3. **Design process improvements** - Change support workflows based on what the data shows 4. **Set up automated tracking** - Create a recurring report that tracks these metrics 5. **Plan headcount** - Use trend data to forecast future support staffing needs --- ## Workflow 5: Design an Escalation Process ### Escalation path ``` ESCALATION FRAMEWORK TIER 1: Frontline Support Who: Support agents Handles: How-to questions, known issues with documented solutions, account/billing questions, feature requests (log and close) Escalates when: Issue is a bug, requires code change, involves data loss, is a security concern, or customer is enterprise/VIP TIER 2: Senior Support / Technical Support Who: Senior agents or technical support specialists Handles: Complex troubleshooting, bug reproduction, API/integration issues, performance investigations Escalates when: Bug is confirmed and needs code fix, issue requires infrastructure access, customer impact is P1/P2 severity TIER 3: Engineering Who: Engineering team (usually via on-call or dedicated support rotation) Handles: Bug fixes, infrastructure issues, data recovery, security incidents Escalates when: Issue requires architectural decision, affects multiple customers, or is a security incident requiring leadership TIER 4: Leadership Who: Engineering manager, VP, CTO as needed Handles: Customer-threatening incidents, security breaches, major outages, decisions about breaking changes or data loss ``` ### Escalation ticket template When escalating from support to engineering: ``` ESCALATION: [ticket ID] Priority: [P1/P2/P3] Customer: [name/account] -- Plan: [plan] -- Revenue: [if relevant] Escalated by: [support agent] -- Date: [today] ISSUE SUMMARY: [2-3 sentences: what is happening from the user's perspective] REPRODUCTION STEPS: 1. [Step] 2. [Step] 3. [Step] Expected: [what should happen] Actual: [what happens instead] ENVIRONMENT: - Browser/OS/Device: [details] - Account ID: [if relevant] - Feature flags: [if relevant] INVESTIGATION SO FAR: - [What support has already tried or ruled out] - [Relevant logs or error messages] - [Screenshots or recordings if available] IMPACT: - Users affected: [count or scope] - Workaround available: [yes -- describe / no] - Customer sentiment: [frustrated / patient / threatening to churn] - Business impact: [revenue at risk, contract renewal upcoming, etc.] WHAT WE NEED FROM ENGINEERING: [Specific ask: fix the bug, investigate root cause, provide workaround, etc.] ``` ### Escalation rules | Situation | Action | Timeline | |-----------|--------|----------| | P1 (service down, data loss) | Page on-call engineer immediately | Response within 15 minutes | | P2 (major feature broken) | Create engineering ticket, notify team lead | Response within 4 hours | | P3 (minor bug, workaround exists) | Create engineering ticket in normal queue | Response within 48 hours | | Security concern | Page security on-call, do NOT investigate further in production | Response within 15 minutes | | Enterprise customer, any priority | Add enterprise flag, notify account manager | First response within 1 hour | ### De-escalation Not everything that gets escalated needs to stay escalated: ``` DE-ESCALATION CRITERIA: - Engineering determines it is not a bug (expected behavior) -> Return to support with explanation - Fix is deployed -> Notify support, support confirms with customer and closes - Workaround is found -> Support communicates workaround, downgrades priority - Issue cannot be reproduced -> Return to support for more information gathering ``` Every escalation should end with a clear resolution that is communicated back to the customer. No ticket should go into a black hole after escalation.