Playbook

Playbook: Build a Support Escalation Summary Skill

A Tier 1 support rep hits an escalation. They open their personal Claude account, paste in the ticket, type their version of "summarize this for the Tier 2 e...

Agent Skillsagent-skills / playbook-support-escalation-summary

A Tier 1 support rep hits an escalation. They open their personal Claude account, paste in the ticket, type their version of "summarize this for the Tier 2 engineer," and forward the result. The next rep does the same thing, except their prompt is slightly different — it asks for "what the customer wants" instead of "what the customer is blocked on," and it leaves out the field your engineers actually rely on. A third rep copies a prompt from a Notion doc that hasn't been touched in eight months. The doc still tells the model to promise a fix timeline.

None of these reps are doing anything wrong. They are doing the work, with the tools they have, to keep customers moving. The problem is that the work belongs to the company and it lives in three personal chat histories. This playbook walks you through replacing that with one reviewed Agent Skill, attached to your support agent, that produces a consistent escalation summary every time — with the customer-data rules, the required fields, and the human-review triggers the support function actually needs.

What you will build

By the end of this playbook, you will have:

  • A workspace Agent Skill named Support Escalation Summary with a SKILL.md procedure, a customer-data policy, an escalation summary template, examples of good and bad output, and the qualification fields your Tier 2 engineers actually use.
  • An approved version of that skill, attached to your Support Agent with a readable mount path.
  • A repeatable workflow: a support rep asks the agent to summarize an escalation, the agent applies the reviewed procedure, the rep gets back a structured summary in the format the Tier 2 team expects.
  • A versioning pattern so the skill can improve as the team learns, without silently changing how escalations get summarized overnight.

What you need before you start

  • An Assist workspace where you can create workspace-scoped Agent Skills.
  • A workspace admin who can review and approve versions.
  • A Support Agent in your workspace — the operational agent your support team already uses, with access to your ticketing system (Zendesk, Intercom, Freshdesk, whatever you actually use). If you do not have one, create a subagent and connect the ticketing tools first.
  • A support lead willing to validate the skill on real escalations before rollout. This is non-negotiable — escalation summaries touch customer trust, and a bad rollout produces bad handoffs across the company for as long as the skill is mounted.
  • Three to five real (sanitized) escalation tickets the team can use for validation. Cover the variety: a billing dispute, a technical outage, a feature gap, a customer-relationship issue.

Step 1: Collect the scattered prompts first

Before authoring anything, find the prompts the team is already using. Ask the support reps:

"Show me the prompt you actually use when you escalate a ticket. Copy it from whatever account or doc you use. Don't clean it up first."

Collect three to six versions. You will see the pattern: most of them ask for a summary of the issue, the customer impact, what's been tried. Most of them have one or two phrasing tics that are wrong — telling the model to "sound confident" or "promise a resolution timeline" or "be empathetic to the customer." A few of them include customer names in the example text the rep pastes alongside the prompt.

Save the source prompts in a draft doc. They become the input to your skill's authoring step — the agent learns what "scattered" looks like by reading actual scattered text, and you get to point at specific failure modes when you write the cleanup rules.

Step 2: Create the draft skill

Open Assist and go to Workspace > Agent Skills. Click New Skill and set:

  • Name: Support Escalation Summary
  • Slug: support-escalation-summary
  • Scope: Workspace
  • Description: Produces a consistent Tier 2 escalation summary from a support ticket, applying the company's customer-data rules, required fields, and review triggers.

Or drive it from chat against your operations agent:

"Create a workspace Agent Skill called Support Escalation Summary. Slug: support-escalation-summary. It produces a structured escalation summary from a support ticket for the Tier 2 engineering team. Start a draft SKILL.md and folders for templates, policies, and examples."

The skill is a draft. Nothing is attached to any agent yet. Author every file safely.

Step 3: Write the main procedure

Open /SKILL.md. The first line tells Assist when to pick this skill up:

Use this skill when a user asks to summarize a support ticket for a Tier 2 escalation, an engineering handoff, or an internal escalation review.

Then walk through the procedure. A useful SKILL.md for this skill includes:

  1. Confirm the ticket identifier (ticket ID, link, or full ticket text). Refuse to proceed without it — escalation summaries that hallucinate ticket context are worse than no summary.
  2. Read the full ticket including the customer's messages, the rep's responses, and any internal notes.
  3. Identify the customer impact in one sentence. Not the technical symptom — the impact on the customer's job.
  4. Identify the current severity using the team's severity definitions in /policies/severity-rules.md.
  5. List what has already been tried, in order.
  6. List the open questions the Tier 2 engineer needs answered to make progress.
  7. Apply the customer-data policy in /policies/customer-data-rules.md — redact account identifiers, contract details, and PII according to the company's escalation handoff rules.
  8. Produce the summary in the strict format defined by /templates/escalation-summary.md.
  9. Flag the summary for human review before sending if any of these conditions are true: the customer references legal action, the customer is in churn risk, the impact is revenue-affecting, or the issue involves a security or compliance concern.

The procedure is what stops the skill from drifting into "model writes whatever it thinks an escalation looks like." Every step has a check the agent must apply.

Step 4: Add the supporting files

  • /templates/escalation-summary.md — the exact output format. Required sections: Customer Impact (one sentence), Current Severity, Account Identifier (redacted per policy), Issue Summary, Steps Tried, Open Questions for Tier 2, Suggested Next Action, Review Triggers Hit. A strict format gives Tier 2 a predictable shape to read.
  • /policies/severity-rules.md — your team's severity definitions. Be explicit: what makes something Sev 1 vs Sev 2 vs Sev 3, what evidence the agent must cite for each. Do not let the agent guess severity.
  • /policies/customer-data-rules.md — what gets redacted and how. Examples: customer names appear as the first initial + last name (or full redaction depending on policy); account IDs replaced with last-four; contract dollar figures stated as ranges; PII never appears in the summary text.
  • /examples/good-summary.md — one fully worked example summary, end to end, with the cleanup commentary. Show how the customer-data redaction is applied. Show what a clear "Open Questions" section looks like.
  • /examples/bad-summary.md — one example of the failure modes you saw in the scattered prompts: leaked customer names, hallucinated severity, vague "next steps," promised timelines. Annotate why each is wrong.

Drive the file work from chat if helpful:

"Draft /policies/severity-rules.md for the Support Escalation Summary skill. Include Sev 1 (revenue-affecting or compliance), Sev 2 (customer blocked but workaround exists), Sev 3 (degraded experience). Spell out what evidence the agent must cite to justify each severity."

Review every file before submitting. The agent applies what you write — vague rules produce vague summaries.

Step 5: Submit for review and approve

From the skill detail page, click Submit for review. A workspace admin and the support lead walk through the files together:

  • Does the procedure match how Tier 2 actually wants escalations handed off?
  • Are the severity rules consistent with what the support team uses today?
  • Does the customer-data policy match the company's data-handling rules?
  • Does the good-output example pass the bar — would a Tier 2 engineer actually pick this up and run?

When approved, the version becomes available to mount. If rejected, the feedback comes back as comments on the version, and you author a new draft addressing the points. Skip the temptation to fix things in chat instead of in the skill — the file is the contract.

Step 6: Attach the skill to the Support Agent

Open the Support Agent and go to its skills view. Click Attach skill, pick Support Escalation Summary, choose the approved version, and set the mount path:

/skills/support-escalation-summary

The Support Agent is now pinned to this version. Every escalation summary the support team asks the agent to produce will follow this reviewed procedure. The personal Claude accounts and the eight-month-old Notion doc stop being the source of truth — the approved skill is.

Step 7: Validate on real escalations

Pick three to five real (sanitized) escalation tickets. Run them through the Support Agent with prompts like:

"Summarize ticket #18432 for a Tier 2 handoff. It's a billing dispute that's been open four days with three message exchanges and one prior escalation."

"Produce an escalation summary for ticket #19012. The customer is referencing potential churn if this isn't resolved this week."

"Summarize ticket #19577 for engineering. The customer mentioned a security concern in their latest message."

The support lead reads the output and compares it to what they would write themselves. Two questions matter:

  • Did the agent apply the policies, or did it just produce "professional-looking" text? The "Review Triggers Hit" section is the tell — if the agent missed the churn flag in the second example or the security flag in the third, the procedure needs to be more explicit.
  • Does the format match what Tier 2 actually wants? Bring a Tier 2 engineer into the validation. If they say "I'd want the Open Questions section first," that's a real change to push back into the skill.

Iterate by updating the skill files, not by giving the agent feedback in chat. The point of an Agent Skill is that the next escalation gets the improved version automatically — but only if the improvement lives in the reviewed file.

Step 8: Roll out to the support team

Once validation passes, announce the change to the support team. Two sentences is enough:

"Starting Monday, when you ask the Support Agent to summarize an escalation, it uses the reviewed Support Escalation Summary workflow. Stop using your personal accounts for this — the agent produces a better summary, and Tier 2 expects this format now."

Stop maintaining the eight-month-old Notion doc. Link reps from the doc to the agent instead. The point is for the personal prompts and the stale doc to atrophy because the agent is genuinely better.

Step 9: Improve the skill from real escalations

After two weeks of real use, patterns emerge. Maybe the agent is over-flagging "security" review triggers. Maybe Tier 2 wants a new field added (linked tickets, related incidents). Maybe the severity rules need a Sev 0 for outages that affect more than one customer.

Open a new draft of the skill, fix the files, submit for review. When the admin approves the new version, deliberately upgrade the Support Agent's attachment using the workflow in Governing Agent Skill versions. Existing escalations in flight finish on the old version. New escalations get the new one.

What you built

You have a reviewed Agent Skill that produces escalation summaries the way the company decided escalation summaries should look. The skill has:

  • A specific procedure with refusal conditions — no ticket ID, no summary.
  • A customer-data policy that gets applied to every summary, not just remembered by the rep who happens to be careful.
  • Severity rules the agent must cite evidence for, not guess at.
  • An output format Tier 2 can read consistently across hundreds of escalations.
  • Review triggers for the situations where a human must look at the output before it goes anywhere.
  • A clear path to improve the skill deliberately, with version control and announced upgrades.

More importantly, you replaced three personal Claude accounts and one stale Notion doc with one reviewed workflow that belongs to the company. The next new hire on the support team does not invent their own escalation prompt — they use the support agent. The next Tier 2 engineer reading an escalation does not have to guess what format it's in. The next time a customer references legal action in a ticket, the review-trigger fires whether the rep noticed it or not.

This is what bringing scattered AI use under one platform looks like in the support function: one approved skill, one operational agent, one consistent handoff, with the customer-data rules actually enforced.

Where to go from here

  • Build a Tier-2 → Tier-3 handoff skill. The same pattern works one layer up: the engineer escalating to an SRE or product team has their own scattered prompts. Repeat the playbook.
  • Add a "customer reply draft" skill. Once you have escalation summaries handled, the customer-facing reply is the natural next workflow to standardize. The customer-data policy you wrote here applies, with stricter rules.
  • Connect a sandcastle dashboard. Build a sandcastle that shows escalation patterns over time — severity trends, common categories, review-trigger frequency. The summaries from this skill are the input.
  • Schedule a quarterly drift review. Have the support lead re-run validation prompts every quarter on fresh sanitized tickets. If the output drifts, update the skill. Skill governance is ongoing, not one-time.