If you work in customer support, AI can take the boring 70% of your job — the boilerplate replies, the thread summaries, the macro drafting — and leave you with the parts that actually need a human: judgment, empathy, and the messy edge cases.
I've spent the last year refining prompts for support work. Below are the 10 I use every week. Each one has a structure, a set of constraints that matter, and a real example output so you can see what good looks like.
The pattern across all of them: Role → Context → Constraints → Output format. Skip the constraints and you get generic slop. Keep them and you get something you can actually send.
1. The macro that doesn't sound like a macro
Role: You are a senior support specialist writing a reusable macro.
Context: Product is {product}. Common issue: {issue}. Customer tier: {free/pro/enterprise}.
Constraints:
- Max 4 sentences.
- No "Hi there!" or "Thanks for reaching out!" — open with the answer.
- No apology unless the issue is actually our fault.
- End with one specific next step, not "let us know if you need anything else."
- If a workaround exists, state it before the root-cause explanation.
Output: A macro body, ready to paste into the ticket.
Example (issue: webhook deliveries delayed):
Webhook deliveries are currently running ~15 minutes behind due to a backlog on our processing cluster. Deliveries are not being dropped — they will all complete, just delayed. As a workaround until we clear the backlog, you can poll the
/eventsendpoint on a 60-second interval. We'll post an update in the status page within the hour.
2. De-escalating an angry ticket without sounding robotic
Role: You are a support lead handling an escalated, frustrated customer.
Context: Ticket: {paste ticket}. Customer is {describe emotional state from their message}.
Constraints:
- First sentence acknowledges the specific impact they described — not a generic "I understand your frustration."
- Name the thing we got wrong, plainly. No "seems like there may have been."
- Do not promise a resolution timeline you don't control.
- Offer exactly two options: (a) what we can do right now, (b) what we can do if they want to wait.
- Tone: calm peer, not apologetic subordinate.
Output: A reply draft.
3. Thread summary for engineering (the one that actually gets read)
Role: You are a support engineer summarizing a long ticket thread for the engineering team.
Context: Full thread: {paste thread}. Suspected bug area: {area}.
Constraints:
- Use this structure: What they expected / What happened / Steps to reproduce / Reproduction rate / Account + resource IDs / Already tried.
- "Steps to reproduce" must be numbered and each step must be one action.
- "Reproduction rate" must be a fraction (e.g., 3/5 attempts), not "sometimes."
- Cut every pleasantry, signature, and back-and-forth from the summary. Engineering does not need the "any update?" pings.
- If the customer shared logs, quote the exact error line — do not paraphrase.
Output: A summary under 200 words, formatted for a Slack thread or bug ticket.
4. Changelog entry from a support perspective
Role: You are writing a customer-facing changelog entry for a fix that support has been fielding tickets about.
Context: Fix: {describe}. Tickets this resolves: {count or themes}.
Constraints:
- Lead with what the customer will notice, not what we changed internally.
- One sentence on the symptom, one on the fix, one on what to do if they still see it.
- No version numbers or internal identifiers in the customer-facing line.
- If action is required on their side, flag it in bold at the end.
Output: A changelog entry (3-4 sentences).
5. Churn-save email for an at-risk account
Role: You are a customer success manager writing to an account that has signaled churn risk.
Context: Account: {name}. Signal: {reduced usage / support complaint / downgrade request}. Contract value: {tier}. Last positive interaction: {what it was}.
Constraints:
- Do not offer a discount in the first email. Discounts train customers to threaten churn.
- Reference one specific outcome they've gotten from the product (pull from usage).
- Propose a 20-minute call with a specific agenda — not "to check in."
- Subject line must be lowercase, 5 words or fewer, and not contain the word "touching" or "checking."
- End with a question that requires a substantive answer, not a yes/no.
Output: An email under 120 words.
6. Internal knowledge base article from a resolved ticket
Role: You are turning a resolved ticket into a reusable knowledge base article.
Context: Ticket resolution: {paste}. Product area: {area}.
Constraints:
- Title is phrased as the customer would search for it, not as engineering would name it.
- Structure: Symptom → Cause → Fix → Verification. Each section is its own H2.
- "Fix" steps are numbered and each starts with a verb.
- Include a "When this doesn't apply" section listing 2-3 similar-looking issues that are actually different.
- No internal links or agent-only context.
Output: A KB article in markdown, ready for the help center.
7. Bug report from a vague customer complaint
Role: You are a support agent converting a vague customer complaint into a structured bug report.
Context: Customer message: {paste}. Environment (if known): {browser/OS/plan}.
Constraints:
- Fill the standard bug template: Title / Environment / Steps to reproduce / Expected / Actual / Severity / Frequency / Attachments.
- If the customer didn't provide steps, write "Steps not provided — requesting from customer" rather than inventing them.
- Severity must be justified in one sentence using impact, not urgency ("blocks checkout for 100% of mobile users" not "customer is very upset").
- List the 3 most likely related code areas for engineering to check first.
Output: A filled bug report.
8. Onboarding reply for a confused new user
Role: You are responding to a new user who is confused about where to start.
Context: Product: {product}. Their signup signal: {what they said they want to do}.
Constraints:
- Do not send them to the docs homepage. Link the one specific page that matches their goal.
- Give them exactly one first action, not a list of five things to explore.
- Acknowledge what they're trying to accomplish before telling them how.
- Keep it under 6 sentences. Over-explaining signals the product is complicated.
Output: A reply.
9. Quarterly review of recurring ticket themes
Role: You are a support manager analyzing the last quarter's tickets for product and process improvements.
Context: Ticket themes (paste list or CSV): {themes}. Volume per theme: {counts}.
Constraints:
- Group into 3 buckets: product bugs / documentation gaps / feature requests.
- For each theme, state the likely root cause category (not the specific fix).
- Rank by {volume × severity}, not volume alone.
- Propose one process change that would eliminate the top theme — not a tool, a process.
- Do not recommend "more training" as a solution.
Output: A review under 400 words with a prioritized table.
10. Post-resolution follow-up that earns a reply
Role: You are sending a follow-up 3 days after resolving a ticket to confirm the fix held.
Context: Original issue: {issue}. Resolution: {what we did}.
Constraints:
- Subject references the specific issue, not "following up."
- One sentence confirming it's resolved on our end.
- One direct question: is it still working for them?
- No satisfaction survey link in this email — that belongs in a separate cadence.
- If they don't reply, that's a positive signal; frame the email so non-reply is acceptable.
Output: A 3-sentence email.
How I test prompts like these
Three habits that separate prompts that work from prompts that produce slop:
- Run it 3 times on the same input. If the outputs vary wildly in quality, the prompt is under-specified. Tighten the constraints.
- Generalize one step. After it works for support tickets, try it on a sales email or a PM user story. If the structure breaks, the constraints were too narrow.
- Read it aloud. If the output sounds like an AI wrote it, add a negative constraint ("no em-dashes," "no 'delve', 'leverage', 'seamless'"). The banned-words list is the single biggest quality lever.
The pack these came from
These prompts are pulled from a larger library I built and tested across real support, product, and engineering work. If you want the full set — 50+ prompts covering support, product management, engineering management, marketing copy, and founder workflows — it's here:
- Developer Product-Launch Prompt Pack ($9) — 7 prompts for launching products: gum.co/qevvy
- Developer Productivity Prompt Library ($49) — 30 prompts for engineering + support workflows: gum.co/plytri
- SaaS Marketing Copy Prompt Pack ($49) — 25 prompts for landing pages, emails, ads: gum.co/orcwxs
- AI Startup Operations Prompt System ($199) — 50+ prompts + 10 workflows for running a company with AI: gum.co/aeqnd
- AI Business Transformation Playbook ($999) — 100+ prompts + 12 workflows, the full system: gum.co/boivub
The $9 pack is the cheapest way in — if it saves you one ticket-writing session, it's paid for itself.
The pattern matters more than the specific prompts. Once you internalize Role → Context → Constraints → Output format, you can write your own for any repeatable part of your job. The prompts above are just the ones I've found survive contact with real tickets.
If you've got a support prompt that works for you, I'd genuinely like to see it — the best ones always come from the people closest to the tickets.
Top comments (0)