AI prompts for customer service and support teams

Draft a customer support reply.

CUSTOMER MESSAGE:
"""
[PASTE]
"""

WHAT ACTUALLY HAPPENED (our side): [THE FACTS, INCLUDING IF WE WERE AT FAULT]
WHAT I CAN OFFER: [REFUND / REPLACEMENT / CREDIT / FIX / NOTHING]
WHAT I CANNOT DO: [CONSTRAINTS]
CHANNEL: [email / chat / public review reply]

Write the reply so that it:
- Opens by naming their specific problem in their own words, not with an apology template
- States plainly whether we got it wrong. If we did, say so without hedging - no 'we are sorry you feel'
- Explains what happened only if it helps them, not to defend us. One sentence maximum.
- Gives the resolution and the timeline as a concrete date, not 'as soon as possible'
- States clearly what we cannot do, once, without repeating it
- Ends with the single next step and who takes it

Rules:
- Under 150 words for chat, under 200 for email
- No 'we value your feedback', 'we apologise for any inconvenience', 'rest assured', 'kindly'
- Do not ask them to repeat information they already gave
- If we were not at fault, do not apologise for the outcome - acknowledge the frustration and move to the fix

Also give me: the one sentence in my draft most likely to make them angrier, and why.

Help me reply to customer chat messages (WhatsApp Business, Instagram DM, website chat).

MY BUSINESS: [WHAT YOU SELL, WHERE YOU DELIVER]
KEY INFORMATION: [PRICES, DELIVERY TIMES, PAYMENT METHODS, RETURN POLICY, OPENING HOURS]
MESSAGES TO ANSWER: [PASTE]
LANGUAGE(S) MY CUSTOMERS USE: [e.g. English, Urdu, Roman Urdu, Arabic]

For each message: a reply under 60 words, in the customer's language and style (formal or casual), that answers the question first.

Then create QUICK REPLIES for the 10 most common questions (price, availability, delivery, payment, returns, order status, location, hours, bulk orders, complaints), each with a short shortcut name.

Rules: never promise delivery dates or stock I have not confirmed; for complaints, apologise once, state the fix, and ask for the order number.

Write a set of canned support responses.

COMMON SITUATIONS: [LIST 5-10 SITUATIONS]
PRODUCT: [WHAT IT IS]
BRAND VOICE: [e.g. plain and direct / warm / technical]
CHANNEL: [email / chat]

For each situation produce:
- A macro name (short, searchable)
- The response, with [VARIABLES] for anything agent-specific
- WHEN TO USE IT - one line
- WHEN NOT TO USE IT - one line. This is the important field.
- The manual edit an agent must make before sending (there must always be at least one)

Rules:
- Maximum 120 words each
- Every macro must have at least one [VARIABLE] that forces the agent to engage with the specific case
- No macro may open with an apology
- No 'I completely understand how frustrating this must be'
- Include a 'we cannot do that' macro and a 'this is going to take longer than we said' macro - these are the two hardest and most-needed

Also flag: any situation in my list where a canned response is the wrong tool and it needs a human from scratch.

Write a help-centre article from these support tickets.

TICKETS (all about the same issue):
"""
[PASTE 5-15 TICKETS]
"""

PRODUCT/FEATURE: [NAME]
WHO THESE USERS ARE: [CONTEXT]

Produce:

1. TITLE - phrased the way users describe the problem, not the way we describe the feature. Pull the phrasing from the tickets.

2. ONE-LINE ANSWER - the fix, immediately, before any explanation.

3. STEPS - numbered, one action each, with the exact UI label in bold.

4. IF THAT DID NOT WORK - the second and third most common causes from these tickets, each with its own fix.

5. WHY THIS HAPPENS - two sentences maximum, and only if knowing it prevents recurrence.

6. RELATED QUESTIONS - the adjacent questions these same users asked in the tickets.

Also output separately:
- SEARCH TERMS: the exact phrases users typed in these tickets, as a list. These go in the article's metadata.
- PRODUCT PROBLEM: if these tickets suggest the product is confusing rather than the user, say so plainly and describe the fix. Documentation should not paper over a bad interface.

Classify these support tickets.

TICKETS:
"""
[PASTE TICKETS, ONE PER LINE OR SEPARATED BY ---]
"""

OUR TEAMS: [LIST TEAMS AND WHAT EACH HANDLES]

For each ticket output a row: ID | Category | Sub-issue | Urgency (P1-P4) | Route to | Sentiment | Churn risk (Y/N/?) | One-line summary.

Define urgency as:
P1 - customer cannot use the product at all, or data/money at risk
P2 - major feature broken, workaround exists
P3 - minor issue or confusion
P4 - feature request or feedback

After the table:
- Group the tickets into themes and give a count per theme, sorted by volume
- Name the top three themes and, for each, say whether the fix is documentation, product, or process
- Flag any ticket where the customer has written in more than once about the same thing
- Flag any ticket that is actually a bug report dressed as a question

Do not mark something P1 because the customer used urgent language. Use the definitions.

Write a customer-facing incident notice.

WHAT BROKE: [PLAIN DESCRIPTION]
WHO IS AFFECTED: [SCOPE]
WHAT STILL WORKS: [SCOPE]
WHEN IT STARTED: [TIME]
CURRENT STATUS: [investigating / identified / fix in progress / resolved]
WHEN WE EXPECT RESOLUTION: [TIME, or 'unknown']
DATA IMPACT: [none / delayed / lost / unknown]
WORKAROUND: [IF ANY]

Write three versions:

1. STATUS PAGE - under 100 words. Lead with what is broken and who it affects. Include what still works. State the next update time explicitly.

2. EMAIL TO AFFECTED CUSTOMERS - under 200 words. Same facts. Add: what they should do now, and whether they need to take any action to recover.

3. HOLDING REPLY for support agents to send to individual tickets - under 60 words.

Rules:
- Never say 'some users' if you know the scope. State it.
- If resolution time is unknown, say 'we do not yet have an estimate' and give a next-update time instead. Never guess.
- No 'we are aware of an issue affecting some customers and are working to resolve it as quickly as possible' - that sentence says nothing.
- If data was lost, say so in the first sentence.
- Do not apologise more than once per message.

Analyse this batch of support conversations for root causes.

CONVERSATIONS:
"""
[PASTE]
"""

PERIOD COVERED: [DATES]
TOTAL TICKET VOLUME IN PERIOD: [NUMBER, if known]

Produce:

1. ROOT CAUSE TABLE - Cause | Ticket count | % of sample | Fix type (product / documentation / onboarding / process / expectation-setting) | Estimated effort (S/M/L)

2. THE TOP THREE causes by volume, each with: a representative customer quote, why it happens, and the specific fix.

3. AVOIDABLE VOLUME - what percentage of this sample would disappear entirely if the top three were fixed. Show the arithmetic.

4. EXPECTATION FAILURES - tickets where the product worked as designed but the customer expected something else. These need marketing or onboarding fixes, not engineering. List them separately.

5. THE SILENT MAJORITY WARNING - for each top cause, note that the customers who wrote in are a fraction of those affected, and say what you would need to measure to size the real impact.

Do not extrapolate from this sample to the whole customer base unless I gave you total volume. If I did, state the assumption you are making.

Draft a reply to a negative public review.

REVIEW:
"""
[PASTE REVIEW]
"""
RATING: [STARS]
PLATFORM: [Google / Trustpilot / App Store / other]
WHAT ACTUALLY HAPPENED: [OUR SIDE OF IT, HONESTLY]
IS THE REVIEW ACCURATE: [yes / partly / no / cannot verify]
WHAT WE CAN OFFER: [IF ANYTHING]

Remember the audience is not the reviewer. It is the next hundred people reading reviews before they buy.

Write a reply that:
- Is under 100 words
- Addresses the specific complaint, not reviews in general
- Corrects a factual error only if it is material, once, neutrally, without arguing
- Takes responsibility where we were wrong, plainly
- Moves the resolution off the platform with a specific route (named contact or direct address), not 'please contact our support team'
- Never asks them to change or remove the review

Then give me:
- WHAT NOT TO SAY: the two things I will be tempted to write that would make this worse
- ESCALATE OR LET IT GO: whether this is worth further effort, and why
- If the review appears to be fake or from a non-customer, say so and describe the platform's reporting route instead of replying.

Help me reply to Instagram comments and DMs.

MY ACCOUNT AND TONE: [DESCRIBE]
COMMENTS / MESSAGES TO ANSWER: [PASTE]
THINGS I NEVER SAY OR PROMISE: [e.g. prices in comments, medical advice, delivery dates]

For each comment or message:
- Type: question / compliment / complaint / spam / troll / sales lead
- Suggested reply (short, in my tone)
- Whether to reply publicly, move to DM, or ignore/hide

Also create 6 reusable reply templates for my most common questions, with a [PERSONAL DETAIL] slot so they do not read as copy-paste.

Rules: never argue publicly; never share private details; keep complaints calm and move them to DM.

Help me respond to a negative review or comment on Facebook.

THE REVIEW / COMMENT: [PASTE]
WHAT ACTUALLY HAPPENED (my side): [FACTS]
WHAT I CAN OFFER: [refund / redo / call / nothing]
TONE: [warm / professional]

Write:
1. A PUBLIC REPLY - under 80 words: thank them, acknowledge the specific issue, state one fact if needed without arguing, offer to continue privately
2. A PRIVATE MESSAGE to send them
3. What NOT to say (things that would make it worse)
4. Whether this review might break platform rules (e.g. fake, not a customer, hate speech) and how to report it if so

Remember: the public reply is written for future customers reading it, not for the reviewer.

Help me make a complaint.

WHO TO: [THE ORGANISATION]
WHAT WENT WRONG: [WHAT HAPPENED, WITH DATES]
WHAT I HAVE ALREADY DONE: [PREVIOUS CONTACT AND THEIR RESPONSE]
WHAT I WANT: [THE RESOLUTION YOU ARE SEEKING]
WHAT EVIDENCE I HAVE: [RECEIPTS, MESSAGES, PHOTOGRAPHS, NOTES]
HOW MUCH IT MATTERS: [minor / significant / has cost me money or caused real problems]
CURRENCY: [IF MONEY IS INVOLVED]

Produce:

1. WHAT YOU ARE ENTITLED TO ASK FOR - realistically. Complaints succeed when the request is proportionate and specific. Options usually include: the thing fixed, a refund or partial refund, compensation for consequential costs, or an apology and a change of process. Say what is reasonable here, and be honest if what I want exceeds what is likely.

2. THE COMPLAINT LETTER - structured:
   - Account or reference details at the top
   - What went wrong, factually, in date order
   - The impact on me, briefly and concretely
   - What I have already done and what response I received
   - The specific resolution requested
   - A deadline for response
   Under one page. Long complaints are read less carefully, not more sympathetically.

3. FACTS OVER FEELINGS - the impact should be stated concretely: time lost, money spent, what could not be done. That is actionable. Expressions of how annoying it was are not, and they make the complaint easier to dismiss.

4. THE ESCALATION PATH - the actual route for this kind of organisation: their internal complaints process first, then the relevant ombudsman, regulator, or trade body. Most organisations require their own process to be exhausted before an external body will look at it, so going straight to the regulator usually just returns you to the start. Say what the path is and note it varies by country and sector.

5. THE EVIDENCE - what I have, what strengthens the complaint most, and what is missing that would help. Send copies, keep originals.

6. THE TIME LIMITS - complaints and escalation routes usually have deadlines, and they are frequently missed. Say what to check.

7. THE RECORD - from now on: dates, times, names, what was said, and reference numbers for every contact. If this escalates, the trail is what decides it.

8. THE PHONE VERSUS WRITING QUESTION - writing creates a record and is usually better for a formal complaint. If a call is needed, follow it with an email summarising what was agreed.

9. THE TONE - firm, factual, and not angry. Anger is understandable and reduces the chance of resolution because it shifts the interaction from a problem to be solved to a person to be managed.

10. WHAT TO DO IF THEY REFUSE - the next step, and an honest assessment of whether it is worth pursuing given how much I said this matters.

11. THE PROPORTIONALITY CHECK - the effort a complaint takes against what it achieves. For a minor issue, say plainly if it is not worth the hours.

Turn this feedback into a priority list.

FEEDBACK:
"""
[PASTE - SURVEY RESPONSES, REVIEWS, SUPPORT TICKETS, OR ALL OF THEM, LABELLED BY SOURCE]
"""

WHAT I PROVIDE: [CONTEXT]
MY RESOURCES: [WHAT YOU CAN REALISTICALLY CHANGE]
WHO GAVE THIS FEEDBACK: [AND HOW THEY WERE SELECTED]

Produce:

1. THE SOURCE BIAS - each feedback source over-represents someone. Reviews come from the extremes, support tickets from people with problems, surveys from responders. Say what this combined set over- and under-represents.

2. THE THEMES - with counts by source. A theme appearing across several sources is stronger evidence than one concentrated in a single channel.

3. THE CLASSIFICATION - each theme as one of:
   - REAL PROBLEM: something is broken or missing
   - EXPECTATION PROBLEM: it works as designed and was described badly. Usually the cheapest to fix.
   - WRONG CUSTOMER: people who should never have bought or signed up. A targeting problem.
   - PREFERENCE: someone wants it different, not broken. Changing may make it worse for others.

4. THE VOCAL MINORITY CHECK - for each theme, how many people, out of how many total. One articulate person can make a preference sound like a crisis. State counts everywhere.

5. THE SILENT MAJORITY - for each theme, who is affected but did not write in. Usually a multiple of those who did. Note where the true impact is likely much larger than the feedback volume suggests, and where it is not.

6. THE PRIORITY MATRIX - each theme scored on: how many are affected, how badly, whether it causes them to leave, and effort to fix. Rank by (impact / effort).

7. THE QUICK WINS - expectation problems and documentation gaps, which cost little and remove real friction.

8. WHAT NOT TO CHANGE - requests that would damage the offering for your main audience, come from people outside your target, or would take resources from something that matters more. Name them explicitly, because the loudest requests are frequently in this category.

9. WHAT TO INVESTIGATE - themes where the feedback signals a problem but not its cause.

10. WHAT TO TELL THE PEOPLE who gave feedback, including on the things you will not do.