Ticket Triage

Classify every incoming ticket on two axes:

Priority (by impact):

• P1 Critical: Service completely down, data loss, security incident. All affected.
• P2 High: Major feature broken, significant degradation. Many affected, no workaround.
• P3 Medium: Feature partially broken but workaround exists. Some affected.
• P4 Low: Minor issue, cosmetic, feature request. Few affected.

Category (by type): Bug, feature request, how-to question, account/billing, integration issue, performance, security.

Assign priority based on impact and urgency, not how angry the customer sounds. A polite message about data loss is P1. An angry message about a font color is P4.

Response Structure

Every support response follows this structure:

1. Acknowledge: Show you understood the problem. Restate it in your own words.
2. Answer or update: Provide the solution, a workaround, or a clear status update.
3. Next step: What happens next? What should the customer do? When will they hear back?

Keep responses concise. Customers want solutions, not essays.

Response Guidelines

Tone: Friendly, professional, empathetic. Not overly casual, not robotic.

Do:

• Use the customer's name
• Apologize for the inconvenience when appropriate (once, not repeatedly)
• Provide specific timelines ("We expect a fix by Friday" not "soon")
• Include relevant documentation links
• Offer alternatives when the requested feature does not exist

Do not:

• Blame the customer ("You should have...")
• Make promises you cannot keep ("We will definitely add this")
• Use jargon without explanation
• Copy-paste templates without adapting them to the specific situation
• Say "As I mentioned before" (makes the customer feel they are wasting your time)

Escalation Criteria

Escalate to engineering when:

• You cannot reproduce the issue but the customer provides evidence
• The issue requires code changes or database access
• Multiple customers report the same issue (potential incident)
• The issue involves data integrity or security

Escalate to management when:

• The customer requests a refund or threatens to cancel
• The issue has been unresolved for more than 48 hours (P2+)
• The customer is a key account
• Legal or compliance implications

When escalating: Include the ticket number, a clear problem statement, steps to reproduce, what you have already tried, and the customer's expected outcome.

Knowledge Base Search

Before responding to any ticket:

1. Search the KB for the exact error message or feature name
2. Check recent tickets for the same issue (might be a known bug)
3. Check the changelog for recent changes that could explain new issues
4. Check the status page for ongoing incidents

If the KB article answers the question, link it directly but also summarize the key steps in your response. Do not just paste a link and close the ticket.

If no KB article exists and you solve the issue, draft a KB article for review.

Common Patterns

Account access issues: Verify identity first. Never share credentials via ticket. Reset via the standard flow. Log all access changes.

Integration issues: Ask for the integration name, version, error message, and when it last worked. Check API changelog for breaking changes.

Performance complaints: Ask for specific metrics (load time, response time). Check server-side monitoring for the relevant time period. Distinguish between client-side and server-side issues.

Feature requests: Acknowledge the need. Check if the feature exists under a different name. Log the request with use case details for the product team. Do not promise timelines.

Metrics

• First response time: Time from ticket creation to first human response. Target varies by priority.
• Resolution time: Time from creation to resolution. Track by priority level.
• First contact resolution rate: Percentage resolved in one response. Higher is better.
• Customer satisfaction (CSAT): Post-resolution survey. Track trends, not individual scores.
• Reopen rate: If tickets frequently reopen, solutions are incomplete.