# Usage: curl -sSL https://seed.show/support.ticket.triage | bash -s <install-path>
# <install-path> is the directory where the file should land.

set -euo pipefail
[ -z "${1:-}" ] && {
  echo "install requires a path: curl -sSL https://seed.show/support.ticket.triage | bash -s <install-path>" >&2
  exit 1
}
TARGET="$1"
mkdir -p "$TARGET"
DEST="$TARGET/seed-fold.uMU1Hg.folded.md"

cat > "$DEST" <<'PORTDOWN_9141F26D'
<!--
This is a `.folded.md` archive — a directory packed into one markdown
file. The markers below are load-bearing; don't edit them directly.

To unpack (requires bash — if you have no shell, tell the user):
  1. curl -sSLf https://fold.dom.vin/skill | bash -s <INSTALL_DIR>
  2. <INSTALL_DIR>/fold/scripts/unfold <this-file>
     (or: unfold <this-file>  if fold/scripts is on your PATH)
-->

---
fold: true
marker: 18f998
at: 2026-05-07T16:16:26Z
root: seed-pack.3LoY5r
---

<!--fold:18f998@file path="README.md" mode="644"-->
# support.ticket.triage

**What this is:** Structural triage logic for classifying, routing, and escalating customer support tickets. For platform-specific configuration (how to set up routing rules in Zendesk, Freshdesk, etc.), fetch those docs at task time — see sources.md.

**What to avoid:** Do not auto-close unresolved tickets, route by keyword rather than intent, or conflate customer sentiment with ticket severity. Triage is a routing decision, not a sentiment analysis task.

---

## Mental model

Triage is a matching problem with two axes:

- **Urgency** — how fast must this reach a resolver? (set by severity + SLA)
- **Complexity** — which resolver tier can actually close it? (set by effort estimate)

The output of triage is an assignment: the right resolver, the right queue, the right deadline. Classification is in service of that assignment, not an end in itself. An agent that labels precisely but routes by keyword has done the easy half.

On one side of the match: a ticket with a severity, an impact profile, and an effort estimate. On the other: a resolver pool — tier 1 generalists, tier 2 specialists, tier 3 engineers, billing agents, account managers, vendor escalation paths. The triage decision connects them.

---

## The triage decision tree

Four questions, in order. Answering them out of order produces misroutes.

**1. Severity — how urgent is resolution?**

Severity is set by degree of service disruption, not by the customer's emotional state or message length. An angry message about a UI annoyance is P3. A calm, brief report of a full outage is P1. Severity drives SLA deadline, which drives queue priority.

Use the P1–P4 framework in taxonomy.md. When the ticket is ambiguous, default to the higher severity and revise downward after first contact. Downgrading is safe; missing an SLA because you started low is not.

**2. Impact — who and what is affected?**

Impact is distinct from severity. A P2 event affecting one user has a different routing profile than the same P2 affecting an enterprise account with 10,000 seats. Impact gates escalation and account-team notification:

- **User-affecting**: one or a few users, non-critical functionality. Route to support queue; no special notification.
- **Business-affecting**: multiple users, revenue-critical function, or an enterprise account. Notify account owner or CSM in parallel with technical routing. Do not wait for the customer to escalate before the account team knows.
- **Platform-affecting**: widespread degradation or data integrity risk. Do not route through the support queue — trigger incident response. Create a status page entry. Escalate to engineering on-call immediately.

**3. Effort — which resolver tier can close this?**

Before routing, estimate whether tier 1 can resolve the ticket without assistance. Tier 1 closes the majority of tickets using documented procedures, FAQ responses, and standard account operations. The routing mistake is escalating anything tier 1 can close — this wastes specialist capacity and inflates resolution time.

Escalate to tier 2 when: non-standard configuration, diagnosis of intermittent behavior, integration troubleshooting, policy exceptions. Escalate to tier 3/engineering when: code-level investigation, database access, confirmed bugs not previously reported, security incidents.

Before escalating, answer: is there a documented procedure for this? Has it been tried? If yes and it failed, document what was tried before handing off. Cold escalations without prior diagnosis extend resolution time.

**4. Assignment — which queue, which person, which SLA?**

With severity, impact, and effort established, the assignment follows from the taxonomy. Map to the queue whose resolver profile matches the effort estimate. Attach the SLA tier corresponding to the severity. Flag for account owner notification if impact is business-affecting.

---

## SLA tiers

SLA tiers are resource allocation signals, not just customer promises. A P1 SLA means the ticket must reach an on-call resolver immediately, bypassing queue depth. A P4 SLA means the ticket can sit in queue until the next available slot.

**P1 — Critical (1-hour first response, 4-hour resolution target)**
Immediate queue bypass. Page on-call resolver. Notify incident coordinator if platform-affecting. Status page update if user-facing. Do not wait for business hours.

**P2 — High (4-hour first response, same business day resolution target)**
Front of queue. Assign to available tier 2 or tier 3. Notify account owner for enterprise accounts. Monitor for P1 reclassification if scope expands.

**P3 — Medium (8-hour first response within business hours, 3 business day resolution target)**
Standard queue. Assign to tier 1 or tier 2. No special notification unless account flags warrant it.

**P4 — Low (2 business day first response, best-effort resolution)**
Backlog queue. Assign to tier 1. Batch with similar tickets if applicable.

**Critical:** The SLA clock starts at ticket creation, not at first agent response. Measuring from first reply is the wrong baseline — you will miss commitments without knowing it.

---

## What agents get wrong

**Urgency vs. priority conflation.**
Urgency is time-sensitive (how fast must this move?). Priority is importance (how much does this matter to the business?). A low-urgency ticket from a strategic account can be high business priority without being P1. Treating them as the same dimension produces misroutes in both directions: over-escalating high-account-value but non-urgent tickets, under-escalating genuinely urgent tickets from small accounts.

**Customer sentiment vs. actual severity.**
An angry or lengthy message does not raise severity. A calm, technical message does not lower it. Set severity on disruption degree alone; track sentiment as a separate signal for tone calibration. An agent that routes by emotional intensity will systematically over-escalate emotional complaints and under-escalate calm reports of serious failures.

**Routing by keyword rather than intent.**
"Can't log in" is not automatically an authentication issue. It may be a billing suspension, a security lockout, a user error (wrong email), or a genuine auth bug. Keyword matching works when keywords reliably predict issue type — which is less often than it appears. Read for intent: what is the user actually experiencing, and what would resolve it?

**Auto-close vs. resolution.**
Closing a ticket after a canned response is not resolution. If the customer's issue is not demonstrably resolved, closing the ticket deflects without resolving — the customer reopens, escalates, or churns. Deflection and abandonment are not the same as resolution. Track resolution rate separately from close rate.

**Escalating before attempting resolution.**
Tier 1 agents — human and AI — underestimate the range of issues they can close. Reflexive escalation of "complex-seeming" tickets without a resolution attempt wastes specialist capacity, increases resolution time, and trains customers that escalation is the path to resolution. Attempt first; escalate with documented results of what was tried.

**Treating SLA as a reporting metric.**
SLA compliance reports tell you what happened. SLA tiers should drive routing decisions in real time. A P1 ticket sitting in a tier 2 queue is already a failure at the moment of assignment, not when the SLA report runs. Route for SLA at assignment time.

**Merging tickets with overlapping symptoms.**
Merging is correct when tickets describe the same user experiencing the same issue in parallel sessions. It is wrong when tickets share a symptom but have different root causes. A wave of "login error" tickets during an outage should not be merged with pre-existing login error tickets from a different bug. Merging conflates resolution paths and corrupts trend analysis.

---

## What AI is changing

**Where AI now handles triage work:**

- *Intent and sentiment classification* — AI reliably classifies issue type and detects sentiment at scale; intent detection is more accurate than keyword routing, sentiment is a useful parallel signal.
- *Auto-resolution for simple cases* — how-to questions with documented answers, password resets, plan change confirmations, standard refunds within policy. Deflection rate on this class is high; check that "deflected" means "resolved" and not "abandoned."
- *Agent assist* — AI surfaces relevant documentation, past similar tickets, and suggested responses to human agents in real time. Reduces handle time and first-contact resolution misses.
- *Anomaly detection* — volume spikes on a specific issue type often signal an emerging incident before users explicitly report an outage. AI can flag this pattern faster than manual queue review.

**What stays human:**

- *Complex escalations* where the resolution path requires judgment about undocumented edge cases, novel bug reproduction, or cross-team coordination.
- *Empathy-requiring interactions* — account-level churn risk, emotionally escalated customers, situations where the response needs to feel personal. AI assist is appropriate here; AI-only response is not.
- *Account-level judgment* — decisions about policy exceptions, credits, contract modifications, or relationship-level escalations require human accountability.
- *Security incidents* — classification of potential security issues and all subsequent handling must route to human security-trained responders. Do not auto-resolve or auto-close anything flagged as a potential security incident.

**AI-human handoff design:**

The critical design point is the handoff, not the AI vs. human split. A well-designed handoff: the AI captures full context before handing off (what the customer said, what was tried, what the AI determined), the human responder doesn't ask the customer to repeat themselves, and the customer doesn't experience a seam. A poorly designed handoff makes the customer feel transferred to an unknowing stranger. Measure handoff quality as a first-class metric alongside deflection rate.
<!--fold:18f998@file path="sources.md" mode="644"-->
# sources

Fetch these at task time. Ordered by importance.

1. **ITIL incident management** — the canonical framework for incident classification, priority matrices, and resolution targets that underlies most enterprise support operations. The P1–P4 severity model and resolver tier structure in this seed derives from ITIL:
   https://www.axelos.com/certifications/itil-service-management/what-is-itil

2. **HDI support practices** — the industry body for support center operations. Practitioner guides define tier definitions, escalation criteria, SLA benchmarks, and the distinction between first-contact resolution and deflection:
   https://www.thinkhdi.com/library/supportworld

3. **Zendesk triage methodology** — Zendesk's framing of ticket prioritization, SLA configuration, routing rules, and intelligent triage (intent, sentiment, language detection). Fetch for platform-specific implementation details:
   https://support.zendesk.com/hc/en-us/articles/4408882070170-About-ticket-routing
   https://support.zendesk.com/hc/en-us/articles/5229019809818-About-Intelligent-Triage

4. **Freshdesk escalation matrix** — concrete escalation tier definitions, routing logic, and matrix configuration for Freshdesk environments:
   https://support.freshdesk.com/support/solutions/articles/37595-setting-up-escalation-emails

5. **Intercom Fin AI** — how Intercom's AI agent handles classification, routing, and handoff decisions. Useful for understanding current AI triage implementation patterns and handoff design:
   https://www.intercom.com/fin

6. **Salesforce Service Cloud Einstein** — AI classification and routing in Salesforce environments, including case classification, next best action, and escalation prediction:
   https://help.salesforce.com/s/articleView?id=sf.einstein_case_classification_overview.htm
<!--fold:18f998@file path="taxonomy.md" mode="644"-->
# taxonomy

The classification dimensions that matter for routing decisions, and how they combine.

## Dimension 1: Issue type

Issue type identifies what the user is asking for. It determines which resolver has the knowledge to close the ticket — not how fast they need to close it.

| Type | Definition | Primary resolver |
|---|---|---|
| **Bug** | Product behavior that does not match documented or expected behavior. Reproducible failure, not user error. | Tier 2 diagnosis → Tier 3 if confirmed code-level |
| **Performance / reliability** | Product works functionally but is slow, intermittently unavailable, or producing inconsistent results. Distinct from bugs because the feature is not broken — it's degraded. | Tier 2; escalate to Tier 3 if infrastructure-level |
| **Integration / API** | Failures in external integrations, webhooks, API calls, or third-party connectors. Often requires joint diagnosis with the customer's technical team. | Tier 2; escalate to Tier 3 for confirmed platform-side API bugs |
| **Security incident** | Unauthorized access, credential compromise, suspicious activity, data exposure, or any customer report that implies a breach. Never auto-resolve or auto-close. | Escalate immediately to security-trained tier 3 or a dedicated security response team |
| **Billing** | Incorrect charges, invoice disputes, subscription changes, refunds, payment failures, or pricing questions. | Billing-specialized tier 1 for standard ops; tier 2 for policy exceptions or disputed amounts above policy threshold |
| **Account / access** | Provisioning, permissions, user management, SSO configuration, or access issues not caused by a bug. Includes seat management, role changes, org-level settings. | Tier 1 for standard operations; tier 2 for non-standard configuration or enterprise org complexity |
| **Onboarding / activation** | Customer is new and cannot complete setup, configure the product for their use case, or get past initial activation. Often looks like a bug but is a documentation or UX gap. | Tier 1 with documentation; escalate to tier 2 if setup requires non-standard configuration |
| **Compliance / data** | Data export requests, deletion requests (GDPR/CCPA), data processing agreements, audit log access, or regulatory inquiries. | Tier 2 or dedicated compliance team; do not route to general support queue |
| **How-to** | Question about how to use existing functionality correctly. No disruption — the user is seeking guidance. | Tier 1 — documentation link and guided walkthrough |
| **Feature request** | Request for functionality that does not currently exist. Not a support issue. | Acknowledge, log to product feedback queue, close support ticket. Do not treat as a bug or escalate to engineering. |

Issue type alone does not determine routing. A billing issue can be P1 (enterprise account suspended, blocking operations) or P4 (question about a line item on an old invoice). Issue type identifies the resolver pool; severity and impact determine the urgency.

### Misclassification patterns to watch

- **Onboarding as bug**: a new customer can't figure out a setup step and reports it as "it doesn't work." Check whether the feature functions correctly for other users before routing to bug diagnosis.
- **Performance as how-to**: a slow product is not a documentation question. If the customer is asking how to make something faster because the product itself is slow, that's performance/reliability.
- **Integration as account**: SSO failures and API authentication errors are often misrouted to account/access. They are integration issues if the configuration is correct and the product is not honoring it.
- **Security as bug**: a customer reporting "someone else logged into my account" is a security incident, not an auth bug. Treat all unauthorized access reports as security incidents until ruled out.
- **Feature request as bug**: a customer saying "it doesn't do X" may mean the product has a bug, or may mean the product was never designed to do X. Verify against documentation before routing as a bug.

---

## Dimension 2: Severity

Severity reflects the degree of service disruption. Set at intake; revise as information arrives.

**P1 — Critical**
- Service is completely unavailable for the affected user or account
- Data loss or data corruption is confirmed or suspected
- Security incident (unauthorized access, credential compromise, data exposure)
- Payment processing is down
- Concrete test: the user cannot perform the core function the product exists to provide

**P2 — High**
- Major feature or workflow is unavailable or severely degraded
- Workaround exists but is painful or time-consuming
- Affects multiple users within an account, or one user on an enterprise account where the function is business-critical
- Concrete test: the user can log in and access the product but cannot complete a primary job-to-be-done

**P3 — Medium**
- Feature is degraded but primary workflows are unaffected
- Cosmetic defects that impair usability without blocking completion
- Single user on a non-enterprise account experiencing intermittent issues
- Concrete test: the user is inconvenienced but can still accomplish their goal

**P4 — Low**
- Informational questions with no active disruption
- Feature requests and enhancement suggestions
- Minor cosmetic defects with no functional impact
- Concrete test: no disruption; the user is seeking information or requesting improvement

When severity is ambiguous, default to the higher severity. Revising downward after first contact is safe. Missing an SLA because you started too low is not.

---

## Dimension 3: Impact

Impact identifies who and what is affected. It gates escalation and account-team notification, independent of severity.

**User-affecting**
One or a few users experiencing an isolated issue. No indication the problem is systemic or account-wide. Route to support queue; no special notification.

**Business-affecting**
Multiple users within an account are affected, or the affected user is on an enterprise or high-tier account where disruption has downstream business consequences. Notify the account owner or CSM in parallel with technical routing. Do not wait for the customer to escalate before the account team knows.

**Platform-affecting**
Widespread degradation, data integrity risk, or confirmed infrastructure-level failure. Do not route through the standard support queue — trigger incident response. Create a status page entry. Escalate to engineering on-call immediately.

---

## Dimension 4: Effort

Effort estimates whether tier 1 can close the ticket independently, and determines initial assignment tier.

**Tier 1 resolvable**
Resolved using documented procedures, standard account operations, or FAQ-level guidance. Covers: password resets, plan changes, refunds within policy, how-to questions with documented answers, configuration guidance from documentation, standard onboarding steps.

Tier 1 should attempt resolution on all tickets before escalating. The escalation threshold is: "I have tried the documented procedure and it did not resolve the issue" — not "this looks like it might be complicated."

**Requires tier 2**
Requires non-standard diagnosis, integration troubleshooting, configuration outside documented patterns, or policy exceptions above tier 1 authority. Covers: intermittent bugs without reproduction steps, custom integration issues, account configuration exceptions, refunds above standard policy threshold, onboarding requiring non-standard setup.

**Requires tier 3 / engineering**
Requires code-level investigation, database access, confirmed bugs not previously reported, or security incidents. Tier 2 should document their diagnosis and what was ruled out before handing to tier 3. Cold escalations to engineering without prior diagnosis extend resolution time and create resolver frustration.

---

## Routing combinations and concrete examples

The four dimensions combine into routing decisions. These examples anchor the logic.

**P1 + Platform-affecting + Tier 3 required**
Multiple enterprise accounts reporting API authentication failures simultaneously.
→ Trigger incident response. Page on-call engineer. Create status page entry. Notify account managers for affected enterprise accounts. SLA clock: 1-hour first response, 4-hour resolution target.

**P1 + Business-affecting + Tier 3 required**
Single enterprise account: API authentication is failing for all users. Core integration is down. No platform-wide pattern.
→ Page on-call engineer. Notify account manager. Open incident. SLA: 1-hour first response, 4-hour resolution target.

**P1 + User-affecting + Security**
Customer reports someone else is logged into their account. No indication of platform-wide breach.
→ Route to security-trained responder immediately. Suspend affected session. Do not auto-close or downgrade. SLA: 1-hour first response.

**P2 + Business-affecting + Tier 2 required**
Mid-market account: bulk export feature returning corrupt files. Affects 3 users. Manual workaround exists but is slow.
→ Front of tier 2 queue. Notify account manager. Same business day resolution target.

**P2 + User-affecting + Tier 1 resolvable**
Single user: dashboard loading slowly. Performance is degraded but functional. No account-wide pattern.
→ Tier 1. Ask for browser and network context. No special notification. Same business day resolution target.

**P2 + Business-affecting + Integration + Tier 2 required**
Enterprise account: webhook delivery is failing for a custom integration. Their engineering team has confirmed correct configuration on their end.
→ Tier 2, with engineering looped in if tier 2 cannot reproduce. Notify account manager. Same business day resolution target.

**P3 + User-affecting + Tier 2 required**
Single user: SSO configuration intermittently failing. Non-reproducible on tier 1's end.
→ Tier 2 after tier 1 documents attempted troubleshooting steps and results. 3 business day resolution target.

**P3 + User-affecting + Onboarding + Tier 1 resolvable**
New user cannot complete account setup; reports that a setup step "doesn't work." Feature functions correctly for others.
→ Tier 1. Verify setup steps against documentation. Walk through configuration. Check for documentation gap. 3 business day resolution target.

**P4 + User-affecting + Tier 1 resolvable**
Single user asking how to configure a webhook. No disruption.
→ Tier 1. Documentation link and guided response. 2 business day first response.

**P4 + Compliance / data**
Customer submits a GDPR data deletion request.
→ Route to compliance team or designated DPO workflow, not general support queue. This is not a support issue; it is a legal obligation with its own SLA governed by regulation (typically 30 days).

**Feature request (any severity)**
User requests functionality that does not exist.
→ Acknowledge, log to product feedback queue, close support ticket. Do not treat as a bug. Do not escalate to engineering.
<!--fold:18f998@end-->
PORTDOWN_9141F26D

# ── post ──
MARKER=$(awk '/^---$/ { f++; if (f==2) exit; next } f==1 && /^marker:[[:space:]]/ { sub(/^marker:[[:space:]]+/, ""); print; exit }' "$DEST")
[ -z "$MARKER" ] && { echo "seed: archive has no marker — corrupt" >&2; exit 1; }
awk -v m="$MARKER" -v outdir="$TARGET" '
  BEGIN {
    # Match <!--fold:<m>@file path="X"--> with an optional mode attr after
    # the path (fold emits  mode="644"  on executables).
    file_re = "^<!--fold:" m "@file path=\"([^\"]+)\"( mode=\"[0-9]+\")?-->$"
    end_re  = "^<!--fold:" m "@end-->$"
  }
  $0 ~ end_re { if (current) close(current); exit }
  $0 ~ file_re {
    if (current) close(current)
    line = $0
    sub(/^<!--fold:[^@]+@file path="/, "", line); sub(/".*$/, "", line)
    current = outdir "/" line
    dir = current; sub(/\/[^\/]*$/, "", dir)
    if (dir != current) system("mkdir -p \"" dir "\"")
    printf "" > current
    next
  }
  current { print >> current }
' "$DEST"
SEED_EXTRACTED=$(find "$TARGET" -type f -not -path "$DEST" 2>/dev/null | wc -l)
if [ "$SEED_EXTRACTED" = "0" ]; then
  echo "seed: archive contained no files — refusing to delete the source" >&2
  echo "  archive preserved at: $DEST" >&2
  exit 1
fi
rm -f "$DEST"

echo "" >&2
echo "✓ seed unpacked → $TARGET ($SEED_EXTRACTED files)" >&2
find "$TARGET" -type f | sort | while IFS= read -r _sf; do
  echo "  ${_sf#${TARGET}/}" >&2
done
echo "" >&2
if [ -f "$TARGET/SKILL.md" ]; then
  echo "This seed contains a skill (SKILL.md). Install it in your agent's skills directory." >&2
  echo "" >&2
fi
echo "Install the seed skill if not already installed:" >&2
echo "  https://seed.show/skill" >&2
echo "" >&2
echo "Publisher prompt:" >&2
sed 's/^/  /' >&2 <<'__SEED_PROMPT_END_AC1F2B__'
Structural triage context for customer support agents: two-axis mental model (urgency × complexity), P1–P4 SLA framework, expanded issue taxonomy with misclassification patterns, escalation logic, what AI is changing in support triage, and AI-human handoff design. Fetch platform-specific docs (Zendesk, Freshdesk, etc.) from sources.md at task time.
__SEED_PROMPT_END_AC1F2B__
exit 0