• Needs to design or improve a ticket triage system or priority matrix
• Wants to define or audit SLAs by customer tier or ticket priority
• Is building or standardizing a macro and response template library
• Needs to design or document escalation workflows and trigger conditions
• Wants to optimize queue management or reduce queue aging
• Is setting up VIP or enterprise support lanes
• Needs to design a support on-call or follow-the-sun rotation
• Is measuring or improving first response time or resolution time

• Production incident management or war room coordination (use incident-management skill)
• Writing individual customer replies without a process context (use a writing assistant skill)

1. First response time is king - The metric customers feel most is how quickly someone acknowledges their problem. A fast FRT buys goodwill and time. Every SLA must prioritize FRT above all others. Measure it first; everything else is secondary.
2. Triage before solving - An untriaged queue is a random queue. Agents working in random order guarantee high-priority problems wait behind low-priority ones. Triage assigns priority, tier, and routing - it does not solve the problem.
3. Macros save hours, not minutes - One macro used 50 times a day saves 50x the time invested in writing it. Expand the library whenever agents write the same reply more than once a week. Review quarterly. A bad macro is worse than no macro.
4. Escalation paths must be clear - Ambiguous escalation is the leading cause of tickets stalling. Every agent must know, without asking, exactly when and where to escalate. If an agent has to think about whether to escalate, the path is not clear.
5. Measure everything - Support intuition degrades under volume. Track FRT, resolution time, CSAT, first contact resolution rate, escalation rate, and queue age. Review weekly. Data surfaces problems before customers do.

• FRT clock starts immediately on ticket creation, including nights and weekends, unless the tier contract specifies business hours only.
• Clock pauses when a ticket enters "Pending Customer" status (waiting on customer).
• Clock never pauses for internal notes or transfers between agents.

P1 - Critical:  Service down, data loss, security issue, or revenue blocked.
                FRT target: 1 hour. Assign immediately. Page on-call if needed.

P2 - High:      Core feature broken, workaround difficult, or VIP affected.
                FRT target: 4 hours. Pull from queue before P3/P4.

P3 - Normal:    Feature degraded, workaround exists, standard customer.
                FRT target: per tier SLA (8h or 24h).

P4 - Low:       Cosmetic issue, how-to question, feature request.
                FRT target: 48 hours. May be batch-processed.

1. Assign priority using the matrix above.
2. Confirm customer tier from CRM. Upgrade priority if enterprise.
3. Check for duplicate tickets from the same account - merge if found.
4. Apply tags: product area, issue type, channel source.
5. Route to the correct queue or agent group.
6. Set SLA clock based on tier and priority.

• At 75% of FRT window: auto-flag the ticket as "at-risk" in the queue view.
• At 100% of FRT window: alert the team lead via Slack and mark as breached.
• At 150% of FRT window: escalate to support manager, log as SLA violation.

Acknowledgment:
  - First response: issue received
  - First response: investigating
  - First response: needs more info

Status Updates:
  - Update: investigating root cause
  - Update: fix in progress, ETA known
  - Update: fix in progress, ETA unknown
  - Update: escalated to engineering

Resolution:
  - Resolution: issue fixed, steps to verify
  - Resolution: workaround provided
  - Resolution: known issue, linked to status page

Closures:
  - Closing: no response from customer (7 days)
  - Closing: duplicate ticket
  - Closing: feature request logged

VIP and Escalations:
  - VIP: acknowledgment with named CSM
  - Escalation received: enterprise path

• Every macro must have a human-review checkpoint. Never send blind.
• Macros must include placeholder fields for: customer name, product area, ticket number, and agent name.
• Review and update the full library every quarter.
• Retire macros with a < 2% usage rate after 90 days.

references/macro-templates.md

Tier 1 (Front-line) -> Tier 2 (Technical Support) -> Engineering
       |                         |                        |
   General issues           Complex bugs             Code-level bugs,
   How-to questions         Integrations             data issues,
   Account issues           Advanced config          security incidents

1. Summary of the issue in 2-3 sentences.
2. Steps already tried and their outcomes.
3. Customer tier and sentiment (calm / frustrated / at churn risk).
4. Relevant screenshots, logs, or error messages attached.
5. Proposed priority for the receiving team.

• Morning triage burst: First 30 minutes of each shift: triage all new tickets before agents pick up personal queues.
• Aging sweep: Every 4 hours, a lead scans for tickets with no activity in 24h and reassigns or prompts.
• Tag-based batching: Group similar tickets and batch-reply after one root-cause investigation.
• Deflection loop: Top 10 ticket topics each week. 5+ recurrences means a help article is needed.

• Contract value above a defined threshold (e.g., > $50k ARR).
• Named in the contract as a "premium support" account.
• Manually flagged by Sales or CS at deal close.

1. SLA clock running during "Pending Customer" status - Many ticketing system configurations keep the SLA clock running even when a ticket is waiting on the customer. This inflates resolution time metrics and creates false SLA breaches. Verify your ticketing platform pauses the clock correctly when status changes to "Pending Customer" or equivalent.
2. Macros that skip populated placeholder fields - A macro template with

   {customer_name}

   that sends as-is when the field is empty sends customers an email that starts "Hi ," - a CSAT disaster. Every macro must require agent review before send; never configure auto-fire on macros with dynamic fields.
3. Enterprise tickets routed into the shared queue - An enterprise customer submitting a ticket via the same channel as a free-tier user will wait behind a backlog of low-priority tickets unless routing is automated. VIP/enterprise tier identification must happen at ticket creation via CRM lookup, not manual agent review.
4. On-call rotations without minimum coverage rules - An on-call rotation with only two engineers per region means one calling in sick leaves a single person covering P1s. Define a minimum viable coverage threshold and have a clear escalation path when it cannot be met (pool from a secondary region, use a support-on-call vendor, etc.).
5. Escalation handoffs without context transfer - Escalating a ticket with only "customer is unhappy" forces the Tier 2 agent to re-investigate everything already discovered. Every escalation must include: the issue summary, steps already tried with outcomes, customer tier and sentiment, and all relevant logs or screenshots. Missing any of these doubles the resolution time.

references/

• references/macro-templates.md

  - ready-to-use support response templates covering acknowledgment, status updates, resolution, and closure scenarios

On first activation of this skill in a conversation: check which companion skills are installed by running

ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null

. Compare the results against the

recommended_skills

field in this file's frontmatter. For any that are missing, mention them once and offer to install:

npx skills add AbsolutelySkilled/AbsolutelySkilled --skill <name>

Skip entirely if

recommended_skills

is empty or all companions are already installed.