customer_support_inbox v1.0.0

---

name: customer_support_inbox description: "Run a customer support inbox end to end: triage every new ticket in under 2 minutes, score priority from impact and urgency, route to the right queue, reply with tested macros in a consistent tone, escalate on clear triggers, and track first reply, resolution, and SLA breach risk. Use when setting up a shared inbox, working a support queue, writing support replies, building macros, defining SLAs, or reviewing support metrics."

---

Customer Support Inbox

Purpose

Give one agent or a small team a complete, repeatable system for a shared support inbox. No ticket sits unread, no urgent ticket waits behind a password reset, and no reply goes out in the wrong tone. The system covers intake, triage, routing, replying, escalation, closing, and weekly review.

Workflow

1. Set up the inbox once

Create these queues (views) before working tickets:

• Untriaged: status New, no assignee, oldest first
• At risk: open, SLA breach within 2 hours, oldest breach first
• Waiting on customer: status Pending, last agent reply over 48 hours ago
• Mine: assigned to you, status New or Open, sorted by priority then age
• Solved today: for end-of-shift checks and handoffs

Required fields on every ticket: type (question, problem, billing, account, feature request), impact (high, medium, low), urgency (high, medium, low), priority (P1 to P4, set by the matrix), product_area, and source_channel. A ticket missing impact or urgency is not triaged yet.

Tags: use lowercase, one concept per tag, from a fixed list. Add tags, never invent near-duplicates in the moment. Review the tag list monthly and merge duplicates.

2. Triage every new ticket (target: under 2 minutes each)

Run this pass at the start of each shift and at least hourly during coverage:

1. Read the full message, including attachments and the customer's previous tickets.
2. Classify type and product_area. If the message contains two separate issues, split it into two tickets and tell the customer you did.
3. Score impact: High means many customers affected, core function down, data or money at risk, or no workaround. Medium means a team or feature degraded, workaround exists but is painful. Low means one person, minor issue, or a question.
4. Score urgency: High means work is blocked now or a deadline is today. Medium means work is slowed this week. Low means no time pressure.
5. Set priority from the matrix in references/triage-and-sla.md. Do not negotiate priority in your head. If the matrix and your gut disagree, follow the matrix and add an internal note saying why you flagged it.
6. Route: assign to a queue or person by product area and tier (see Escalation). Unassigned P1 and P2 tickets are a triage failure. Fix them before moving on.
7. Send the first reply if you are the assignee, or leave a one-line internal note for the assignee: what it is, what you already checked, what to do next.

Use the helper to score and stamp deadlines:

python3 bin/triage.py --impact high --urgency high --created "2026-10-12T09:00:00-05:00"
python3 bin/triage.py --impact medium --urgency low --type billing --created "2026-10-12T09:00:00-05:00" --json
python3 bin/triage.py --check --priority P2 --created "2026-10-12T09:00:00-05:00" --now "2026-10-12T12:30:00-05:00"

3. Work the queue in the right order

Order of work, always:

1. At risk and P1 tickets first, regardless of age.
2. P2 tickets approaching first reply target.
3. Oldest P2 and P3 tickets.
4. P4 tickets in batches (see macro rules below).

Never work strictly oldest-first across all priorities. That lets a trivial old ticket delay an outage report that arrived later.

First reply rules:

• A first reply is a human reply that shows you understood the problem. An auto-acknowledgement does not count.
• If you cannot solve it in the first reply, the first reply still names the problem back, says what you are doing, and gives a specific time for the next update. Example structure is in references/macro-library.md (M02).
• If you need information to proceed, ask for all of it in one message, numbered, with a note on why each item helps.

4. Reply using the tone standard and macros

Tone standard (applies to every reply):

• Friendly and plain. Short sentences. One idea per paragraph.
• Use the customer's name once, early. Use your own first name in the sign-off.
• Name the problem in the customer's words before using internal terms.
• Say what happened, what you did, and what happens next. All three, every time there is a fix or a wait.
• No blame, no jargon dump, no legal language unless the ticket is actually a legal or safety matter.
• Apologize for the impact once, plainly, when the customer was harmed or blocked. Do not apologize repeatedly and do not apologize for things that did not happen.
• Never say: "per our policy" without explaining the reason, "you should have" about the customer's past action, or "calm down" in any form.
• Read the draft once as the customer. If any sentence could read as dismissive, rewrite that sentence.

Macro rules:

• Macros in references/macro-library.md are starting drafts, not send-as-is scripts. Personalize the first line and any specifics before sending.
• Every macro has required fill-ins marked [like this]. A reply with a bracket left in it is a failed reply. Search for [ before sending.
• If a macro does not fit after two edits, write the reply from scratch. Forcing a macro reads worse than a fresh reply.
• When you write the same reply by hand three times in a week, draft it as a new macro and add it to the library with an owner and a review date.

5. Escalate on triggers, not on feelings

Tiers:

• Tier 1 (front line): logging, triage, common fixes, how-to questions, password and account basics, billing questions with known answers, status updates.
• Tier 2 (specialist): complex product or technical investigation, account merges, data corrections, billing disputes above your approved limit, repeat failures.
• Tier 3 (expert / engineering / leadership): outages, security or privacy incidents, data loss, legal threats, refund or compensation above Tier 2 limits, product defects that need a code fix.

Escalate immediately when any trigger hits:

• You have spent 20 minutes without progress on a P1 or P2, or 45 minutes on a P3.
• The fix needs access, permission, or knowledge you do not have.
• The same customer reports the same issue a third time.
• The ticket involves safety, security, privacy, legal, or payment data exposure. These skip tiers and go straight to the named owner for that category.
• The customer asks for a manager. Honor it in the same reply cycle. Do not try one more fix first.

A good escalation is a warm handoff, not a toss:

1. Internal note: summary in 3 lines, what you tried, exact error or evidence, what you need from the next tier.
2. Customer reply: name the handoff plainly, say who owns it next (team name is enough), give the next update time.
3. Change assignee and priority if the new information changes the score. Keep the SLA clock visible: note time remaining before breach.

6. Close tickets cleanly

• Solve only when the fix is confirmed or the customer has the full answer and steps. If you are unsure, ask one confirmation question and set the ticket to Pending.
• Closing note (internal): cause, fix, and any follow-up owed. One or two lines is enough for simple tickets.
• Pending tickets: send one follow-up after 48 hours, a second after 5 days, then solve with a closing message that invites a reply to reopen. Adjust the timing to your published support hours and say so in the message.
• Reopened tickets: treat a reopen within 7 days as the same issue. Keep the history, re-score priority, and check why the first fix did not hold before replying.

7. Track SLAs and review weekly

Track these per week, split by priority and channel. Blended averages hide problems.

• First reply time: ticket created to first human reply.
• Next reply time: customer reply to next agent reply.
• Resolution time: created to solved. State whether you count business hours or calendar hours, and be consistent.
• SLA attainment: tickets meeting target divided by tickets covered, times 100.
• First contact resolution: tickets solved on the first interaction with no reopen in 7 days, divided by eligible tickets, times 100.
• Reopen rate: reopened tickets divided by solved tickets, times 100.
• CSAT: satisfied responses divided by valid survey responses, times 100. Report the response count next to the score. A score from 6 replies means little.

Weekly review (30 minutes, same time each week):

1. List every breach. For each: late triage, wrong priority, waiting on another team, or no owner. Name one cause per breach.
2. Sample 5 solved tickets at random. Score each reply against the tone standard. Log the pattern, not just the ticket.
3. Find the top 3 contact reasons by volume. For each: can a help article, a macro, or a product fix cut it? Assign one action with an owner and a date.
4. Check macro library: remove or rewrite any macro used often with heavy edits, and any macro not used in 90 days.
5. Write the review in 10 lines or fewer and share it where the team works.

Starter SLA targets, formulas, and breach handling are in references/triage-and-sla.md. Treat the numbers there as defaults to calibrate against your first 4 weeks of real data, not as promises to copy blindly.

Output Contract

When working a ticket, the output for each ticket is:

• Triage record: type, impact, urgency, priority, queue or assignee, SLA deadlines
• First or next reply: personalized, tone-checked, no leftover brackets, with a next update time when the issue stays open
• Internal note: what was checked, what was found, next step and owner
• On escalation: handoff note plus customer-facing handoff reply
• On close: closing message plus a one-line internal cause and fix note

When setting up or auditing an inbox, the output is a written setup or audit that covers: queues, required fields and tags, priority matrix in use, SLA targets with hours basis, macro library location and owner, escalation tiers and triggers, and the weekly metrics list with formulas.

Operating Rules

1. Every factual claim to a customer about product behavior, pricing, timelines, or policy must be checked against a current source (help center, docs, account record, or internal owner) before sending. If you cannot verify it, say what you do know and when you will confirm the rest. Never invent a date, a refund amount, a feature, or a fix time.
2. Never promise a resolution time you do not control. Promise an update time instead, and keep it.
3. Protect customer data. Do not paste passwords, payment details, tokens, or full personal data into internal notes, chats, or other tickets. Redact and reference the secure record instead.
4. One ticket, one issue, one owner at a time. Split mixed issues. Transfer ownership explicitly, never by silent reassignment.
5. If priority, tone, and speed conflict, keep the tone and the priority order, and tell the customer about the wait honestly. A fast, cold reply to the wrong ticket helps no one.
6. If this system does not fit the situation (safety incident, legal matter, outage with a separate incident process), follow the stricter process and note the exception on the ticket.