Support ticket reply
Skill SkillMedev/customer-support-copilot/skills/support-ticket-reply
Six skills to resolve faster, escalate smarter, and turn tickets into self-service.
npx -y skills add SkillMedev/customer-support-copilot --skill support-ticket-replyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Drafts empathetic, accurate, action-first support replies structured to resolve the ticket in one touch - resolution first, context second, one unambiguous next step. Use when someone asks "help me reply to this customer", "draft a response to this ticket", "how do I tell a customer X", or is composing responses to customer issues, complaints, or feature requests. Do NOT use for emotionally charged conversations or refund decisions - use refund-deescalation instead; for building a reusable library of canned responses, use support-macro-library; for diagnosing why satisfaction scores are falling, use csat-root-cause.
SKILL.md
5.8 KB, as published. Nobody here has run it
Support Ticket Reply
Every support reply has one job: give the customer exactly what they need to move forward without writing back. The costly mistake this prevents is the partial answer - a reply that addresses two of the customer's three questions guarantees a follow-up, doubles handle time, and damages CSAT more than a slow-but-complete reply would have. Lead with the resolution, follow with context, close with one clear next step.
Operating procedure
Step 1: Gather inputs
Before drafting, establish:
- The full ticket text, including every distinct question or request in it (count them - this number drives Step 4).
- Ticket severity: is the customer blocked, degraded, or merely curious? Default to "degraded" if unclear and say so.
- What is actually known: is the resolution confirmed, in progress, or unknown? Never draft "will" statements from guesses - label uncertain facts as unconfirmed and write around them.
- The customer's emotional temperature. If the ticket is angry, threatens to cancel, or disputes a charge, stop - route to refund-deescalation.
Step 2: Draft in the fixed structure
Always this order:
- Acknowledge the specific issue in one sentence - name it precisely, never paraphrase vaguely.
- State the resolution or the concrete next action immediately.
- Explain the "why" only if it reduces future confusion or builds trust; cap it at two sentences.
- Close with a single, unambiguous next step: a link, a yes/no question, or a confirmation request.
- Sign off warmly but briefly.
Step 3: Calibrate tone to severity
Match urgency to impact: a blocked customer gets short sentences and a timeline in the first two lines; a curious one can get a friendlier, fuller answer. Use plain language - no jargon, no product-internal terms. For a frustrated customer, name the frustration before the fix: "That should not have happened, and I am sorry it did." Never use hollow openers like "Great question!" or "I totally understand your frustration" without immediately proving it with specifics.
Commit to times, not vibes: if investigation is needed, give an explicit follow-up window ("by Thursday 2pm your time"), and set it at something the team can beat. A follow-up promise without a time is a second ticket waiting to happen.
Step 4: Run the one-touch check before sending
- Does the reply answer every question in the ticket? If the customer asked three things, address all three, numbered.
- If a full answer needs information not yet available, say what is being done to get it and give a time window.
- Is there exactly one next step, and is it something the customer can do in under a minute?
- Would this reply make sense to someone who has not read internal notes? Policy must be translated into what it means for this customer, never pasted verbatim.
Worked contrast pair
Ticket: "I was charged twice this month, my export to CSV is broken, and does your API support webhooks?"
Bad:
Hi! Great question! I totally understand your frustration. I've looked into
your account and it seems there may have been a billing issue. Our team is
aware of some export problems and we should have a fix soon. Let me know if
there's anything else I can help with!
Why it fails: hollow opener, answers zero of three questions concretely, hedges with "may" and "should" on knowable facts, no timeline, no next step.
Good:
Hi Dana - three things, answered in order:
1. Double charge: confirmed. I've refunded the duplicate $49 to your card;
it will appear within 3-5 business days.
2. CSV export: this is a known bug in exports over 10,000 rows. The fix
ships Thursday; until then, filtering to under 10,000 rows exports fine.
3. Webhooks: yes - docs here: [link].
Once the refund lands, reply here to confirm and I'll close this out.
Why it works: names all three issues, resolution first on each, one concrete workaround, one clear next step.
Deliverable
Produce a send-ready reply containing: a specific one-sentence acknowledgment, the resolution or next action up front, numbered answers matching every question in the ticket, any commitment tied to an explicit time, and exactly one closing next step.
Do NOT
- Do not open with "I" - start with the customer or the action; the reply is about them.
- Do not paste policy text verbatim; translate it into what it means for this customer, or it reads as a brush-off.
- Do not hedge with "should" or "might" when the answer is known - use "will" or "is"; hedging on known facts reads as incompetence.
- Do not apologize more than once; repeated apologies shift the reply's center of gravity from resolution to performance.
- Do not answer a subset of the questions - the unanswered one is the follow-up ticket.
- Do not handle refund disputes or visibly angry customers with this structure alone; that is refund-deescalation territory.
Quality bar
Before sending: every question in the ticket has a numbered answer; the resolution appears in the first two sentences; every promise has a time attached; there is exactly one next step; and no sentence exists solely to sound nice. If the same reply is being written for the third time this week, turn it into a macro via support-macro-library.