Customer Support prompts

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.

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 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 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 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.