Skip to content
Prompt Library

Customer Support Prompts

Complaint resolution, reusable macros, and de-escalating unhappy customers. Replace the bracketed variables with your specific context. Copy the prompt or launch it directly in the chat.

  • 50 Customer Support prompts
  • Copy or open in chat

Responding to an Unhappy Customer

A response that acknowledges the issue and retains the customer without over-apologizing.

Draft a response to the following message from a customer of [company]: [customer message].

Context: The issue stems from [origin: our error, a vendor, a misunderstanding, the customer]. What we can offer: [options: refund, credit, replacement, discount]. What we cannot do: [limitations].

Structure: Acknowledge the specific problem by mirroring their words (avoid generic phrases). Briefly explain what happened without shifting blame or throwing a colleague under the bus. State the concrete solution and the timeline. Mention what is being done to prevent recurrence if applicable.

Tone: Human and direct. Prohibited: "We apologize for any inconvenience caused," passive phrasing like "we should have," repetitive apologies, or promising anything outside of [options].

Building Your Support Macro Library

The 10 standard responses for your business, customizable in 30 seconds each.

Create a library of 10 response macros for [company] support, selling [product or service] to [target audience]. Our channels: [channels: email, chat, phone]. Most frequent contact reasons: [reasons, e.g., order tracking, login issues, refund requests, billing questions].

For each macro: Provide an explicit internal name, precise usage situation, full text with placeholders in brackets ([First Name], [Order #], [Deadline]...), and the specific condition that requires exiting the macro for a custom response.

Requirements: Each macro must fully address the reason (no "we will get back to you" without a dated commitment). Tone should match our style [style: formal/casual, sober/warm]. Include a short version for chat where applicable.

Announcing an Incident or Outage

The incident communication sequence: announcement, status update, resolution, and post-mortem.

We have an ongoing incident at [company]: [nature of incident, e.g., service down, shipping delays, billing error]. Impact: [who is affected and how]. Cause: [known / under investigation]. Estimated fix: [estimate or unknown].

Draft the full sequence: Initial announcement (sent within the hour: what is happening, who is affected, what we are doing, when the next update is coming: do not speculate on cause). Status update (reusable structure every [frequency]). Resolution message (what was fixed, any compensation: [planned gesture]). Post-incident follow-up for customers who opened tickets.

Rules: Never minimize (avoid "slight slowdowns" if it is broken). Always provide the time for the next update even if there is no new info. Use one voice across all channels. Provide the initial announcement in 3 formats: email, website banner (1 sentence), and a standard response for the support team.

Saying No to a Request Without Losing the Customer

A clear, reasoned refusal with a real alternative when one exists.

A customer of [company] is asking for [request, e.g., out-of-policy refund, a feature we don't have, an exceptional discount]. We must refuse because [real reason for refusal]. Customer value: [context: tenure, spend, history]. Possible alternative: [alternative or none].

Draft the response: Acknowledge the request to show it was understood. Refuse clearly by the second paragraph (do not bury the 'no' under fluff). Give the real reason in simple terms (a rule applied to everyone is easier to defend than a pretext). Offer the alternative if it exists without overselling it. Leave the door open.

Tone: Firm and respectful. Prohibited: Using "unfortunately" more than once, false hope ("we will look into it"), or referring them to another department without a hand-off. Add a variation for if the customer threatens to switch to [competitor].

Analyzing Tickets to Reduce Volume

An analysis of contact reasons leading to root-cause reduction actions.

Analyze the contact reasons for [company] support to identify what can be reduced at the source. Data: [export or summary of tickets: reasons, volumes, handle time, channel, period]. Support headcount: [staff count]. Current documentation: [status of FAQ / Help Center].

Produce: A ranking of reasons by volume and cost (volume × handle time). For each of the top 5 reasons, identify the likely root cause and the appropriate reduction action: product fix, UX clarification, better confirmation email, help article, or proactive messaging.

For "help article" actions, draft the article outline. For "proactive message" actions, draft the message. End with an estimate of the percentage of avoidable tickets and the top 3 actions to launch this week. Highlight what the provided data does not allow you to conclude.

Responding to a Public Negative Review

A public response to Google or Trustpilot, written for future readers as much as the author.

Draft the public response for [company] to this negative review on [platform: Google, Trustpilot, App Store]: [review text].

Internal context: What actually happened: [internal version of facts]. What we can offer: [possible gesture or nothing].

Rules: The response is for the hundreds of future readers as much as the reviewer. Acknowledge valid points without admitting unproven faults. Never counter-attack or publicly doubt the customer's good faith. Suggest moving to a private channel with a specific contact ([dedicated email or phone]) without making it look like an escape. Do not include customer personal data in the response.

Constraints: Max 120 words, signed with a first name and title. Provide a variation for cases where the review contains factual inaccuracies: correct them factually without calling the customer a liar.

Responding to Positive Reviews (No Copy-Paste)

Five templates for positive reviews, customizable and free of empty clichés.

Create 5 response templates for positive reviews for [company], selling [product or service]. Platforms: [platforms]. Our tone: [style: professional, warm, casual].

Each template corresponds to a type of review: detailed review citing a specific element, short "great job" review, review mentioning an employee by name, positive review that includes a small critique, and a review from a loyal returning customer.

Rules: Reference a concrete element from the review to prove a human read it (placeholder [cited element]). Thank them without being sycophantic. Never include a sales pitch in the response. Address the critique in the mixed review instead of ignoring it. Max 50 words per response.

Output format: The 5 templates with placeholders, plus an internal rule: which reviews deserve a response within 24 hours and which can wait.

De-escalating an Aggressive Customer

Methods and phrasing to handle interactions that turn hostile, both in writing and on the phone.

You are a trainer for difficult customer relations. A customer of [company] is being aggressive on [channel: phone, email, chat]: [summary of situation and tone]. Their core request: [request]. Our room for maneuver: [options].

Provide a 4-step de-escalation method: Let them speak without interrupting or justifying too early. Validate the emotion without validating the accusations (provide exact phrasing). Refocus on what can be solved. Lock in a dated commitment.

Draft word-for-word phrasing to: Politely interrupt a looping monologue. Respond to a personal attack against the agent. Refuse to continue if insults persist (2 warnings then end the interaction, phrasing for each stage). Resume the conversation later once calm is restored.

Specify the differences between phone and written communication, and the exact moment an agent should hand off to a supervisor.

Handling Legal Action Threats

Protocol and holding responses when a customer mentions lawyers or regulatory bodies.

A customer of [company] is threatening to [threat: call their lawyer, report to the FTC/Better Business Bureau, contact the press, start a lawsuit]. The dispute is over [subject, amount]. History: [summary of exchanges].

Help support handle this without playing lawyer: Draft a holding response that acknowledges receipt, stays factual and polite, admits no fault, does not contest the customer's right to act, and announces a specific timeframe for a full response.

Include: An internal checklist before responding (freeze data deletion related to the file, gather timeline and evidence, notify [manager to alert]). List 3 phrases to absolutely ban in this context (anything admitting liability or promising a specific outcome). Define the simple criteria for handing the file to management or legal counsel instead of continuing in support. Do not provide legal advice on the merits.

Responding to Refund Requests

Three standard responses for approved, partial, or denied refunds, including concrete next steps.

Draft responses for refund requests for [company], selling [product or service]. Our policy: [rules: deadlines, conditions, exceptions]. Request received: [customer message and reason].

Produce 3 versions: Approved refund (confirm exact amount, payment method credited, real timeline in business days, what the customer should do if they see nothing). Partial refund or credit (explain the calculation without accounting jargon, present the credit clearly). Denied (the applicable rule, why it exists, what options remain).

Common rules: State the decision in the first two lines. No vague phrasing like "should be refunded." Avoid repetitive "exceptional gestures" that undermine the policy. Format: 3 full emails with placeholders, plus the internal note to log in the ticket for each case.

Setting a Commercial Gesture Framework

An internal scale to ensure consistency between agents and avoid over-discounting.

You are the Customer Service Manager for [company] ([product or service], average order value [amount], indicative margin [level]). Agents currently offer discounts or credits based on 'gut feeling' without consistency.

Build an internal commercial gesture grid: 5 to 8 standard situations ([frequent issues: delay, product defect, our error, subjective disappointment, unhappy loyal customer]). For each, define the standard gesture, the maximum gesture without approval, and the threshold requiring a manager's sign-off.

Principles: The gesture repairs actual harm, it doesn't buy silence. A customer who yells louder should not get more than a polite customer in the same situation. Offer credit before a refund when legitimate, but never as a trap.

Format: Table of situation / standard gesture / agent cap / escalation. Include phrasing to announce each gesture without overselling it, and 3 monthly KPIs to verify the grid is being followed.

Responding to a Billing Complaint

A clear response to a customer incorrectly billed, with a fix, timeline, and honest explanation.

A customer of [company] is disputing a charge: [nature of issue: double charge, incorrect amount, billed after cancellation, promo not applied]. Internal verification: [what our system shows: confirmed error, partial error, correct billing but misunderstood].

Draft the response based on the verification. If the error is confirmed: Acknowledge it directly, state the exact amount refunded, the timeline in business days, and what has been fixed to prevent recurrence. If billing is correct: Explain line-by-line where the amount comes from pedagogically, without making the customer feel stupid, and show them where to find this detail themselves next time.

Constraints: No billing jargon ([examples of internal terms to ban]). Use exact figures only. Never say "the charge will show up soon" without a date. Add a short version for chat and the internal log note.

Managing Shipping Delays

Tiered responses based on the delay, from simple tracking updates to likely lost packages.

Build standard responses for [company] regarding shipping delays. Our delivery promise: [timeline]. Carriers: [carriers]. What we can do: [levers: reship, refund shipping costs, gesture, carrier investigation timeline].

Produce 4 responses based on the stage: Slight delay of a few days with active tracking. Tracking stalled for [duration] with no movement. Package marked delivered but not received (checklist for the customer: check with neighbors, building manager, without treating them as a suspect). Package likely lost (trigger reship or refund without waiting for the carrier investigation if policy allows).

Rules: Never shift 100% of the blame to the carrier (the customer paid us). Always provide the next specific date we will follow up. Format: 4 emails with placeholders.

Responding to a Defective Product Report

Full handling of a broken or non-compliant product, from diagnosis to solution.

A customer of [company] reports a defective or non-compliant product: [description of issue]. Product: [product, price]. Our process: [options: return with prepaid label, direct replacement, refund, repair; who pays for return].

Draft the first response: Brief and sincere empathy (one sentence, not three). Ask the 2 or 3 questions or for photos needed for diagnosis (only the essentials; every back-and-forth costs a day). Clearly state the possible solutions based on the diagnosis so the customer knows what to expect.

Then draft the solution response once the defect is confirmed: The chosen solution, concrete steps for the customer (numbered, with return label attached), and the timeline for each step.

Rules: Never ask the customer to prove their good faith beyond reason. Do not make them bear the cost of our defect. Use placeholders, 2 full emails.

Responding to Order Status Inquiries

Status updates that provide real information instead of just repeating the tracking link.

Create standard "where is my order" responses for [company]. Our order flow: [stages: validation, picking, shipped, delivered, with timelines for each]. Tools: [what the agent sees in the back-office].

Produce one response per stage, each providing: Exactly where the order is, what happens next, and the next date something visible will happen for the customer. Prohibited: Copying raw carrier status ("processed at hub") without translating it, and responses that teach nothing ("your order is being processed").

Add: A response for an order the agent sees is blocked internally ([frequent causes: out of stock, payment verification, incomplete address]): Tell the truth about the cause, give a realistic timeline, and provide an exit option (modify or cancel). Format: Full responses with placeholders, email and chat versions.

Requesting Info Without Driving the Customer Away

Grouped and justified info requests to resolve issues in one exchange instead of three.

You are a Support Quality Manager. Our agents at [company] ask questions one by one: each ticket takes 3 exchanges instead of 1. Affected reasons: [reasons, e.g., technical bug, incomplete file, shipping claim].

For each reason, build the ideal information request message: All necessary questions grouped at once, numbered, phrased for precise answers (closed questions or choices rather than "can you tell me more?"). Include a line for each question explaining why we need it if it's not obvious.

Rules: Max 5 questions per message. Never ask for info already in the ticket or account (the #1 cause of frustration). State what will happen once the answers are received. Format: One message per reason with placeholders, plus an internal "Did I ask everything?" checklist per reason.

Following Up on a Non-Responsive Customer

A two-step follow-up sequence before closing, making it easy to reply rather than demanding it.

Draft the follow-up sequence for [company] for a customer who opened a ticket and stopped responding. Ticket context: [reason]. We are waiting for: [info or action]. Silence for: [duration].

Produce 3 messages. Follow-up 1 (at [delay 1]): Brief reminder of what we need, minimizing effort (rephrase the question in one line, offer choices if possible). Follow-up 2 (at [delay 2]): Signal that the ticket will close without a response by [date], clarifying that nothing is lost and how to reopen. Closing message: Close politely, summarize where the file stood, and provide the simplest way to resume.

Rules: No guilt-tripping (avoid "since you haven't responded..." in a threatening tone). Adapt timelines to the severity of the issue (e.g., different for a blocking bug vs. a general question). Use placeholders.

Properly Closing Resolved or Inactive Tickets

Closing messages that confirm resolution without making the customer feel brushed off.

Create ticket closing messages for [company] support. Our tool: [ticketing tool]. Satisfaction survey sent at close: [yes/no, which one].

Produce 4 messages: Closing after customer-confirmed resolution (summarize the solution in 2 lines for future reference). Closing after presumed resolution without customer confirmation (phrasing that doesn't claim it's fixed, but closes due to lack of feedback, with easy reopening). Closing a duplicate ticket (point to the main ticket). Closing an out-of-scope request (clearly state we don't do this, redirect to [alternative] if it exists).

Rules: Never use "don't hesitate to contact us" as a filler. Provide the specific link or action to reopen THIS file without re-explaining everything. The message must remain understandable if read 6 months later. Use placeholders, email and chat versions.

Responding to a Feature Request

An honest response to a customer requesting a feature, depending on whether it's planned, under review, or rejected.

A customer of [company] is asking for a feature our product lacks: [request]. Real internal status: [status: planned for QX, under review/no commitment, intentionally rejected, never evaluated]. Existing workaround: [workaround or none].

Draft the response adapted to the real status. If planned: give the horizon without promising a firm date, offer to notify them at launch. If under review: honestly state no commitment exists, explain how requests influence our choices. If rejected: give the real reason in simple terms (product choice, not disregard for the need) and detail the workaround. If never evaluated: thank them and log it, without false hope.

Rules: NEVER imply "it's coming soon" to buy peace. Thank them for the detail. Log the request in [tracking tool] with the exact verbatim. Provide the 4 full variations and the standard log entry line.

Simplifying Technical Answers for Non-Experts

Translating a technical diagnosis into a clear response without being condescending or losing accuracy.

Here is the technical diagnosis provided by our team for a [company] customer ticket: [raw technical diagnosis]. The customer: [profile, e.g., non-technical business owner, senior individual, power user]. Original question: [customer question].

Translate this diagnosis into a customer response: Start with the concrete consequence for them (what works, what doesn't, what they need to do). Explain the cause using an everyday analogy if it truly helps (otherwise skip it). Provide numbered resolution steps with an estimated time for each.

Rules: No condescension (avoid "it's very simple" if it isn't for them). No technical terms without an immediate translation in parentheses. Do not simplify to the point of being incorrect: tell me if a simplification you make sacrifices accuracy. Format: Full response, then the list of technical terms you translated and how.

Writing a Knowledge Base Article

A help article that solves the problem independently, written to be found and followed without an agent.

Write a help center article for [company] on: [subject, e.g., changing password, returning a product, understanding your first bill]. Source: [standard agent responses or internal procedure]. Audience: [customer profile].

Structure: A title phrased as a customer search query (not internal jargon). The answer to the question within the first 3 lines for those in a hurry. Detailed numbered steps (one action per step, where to click, and what should appear). A "Didn't work?" section with 2 or 3 frequent blockers and their solutions. A bridge to support with the context needed for fast help.

Rules: No assumed screenshots (indicate where to insert them with [screenshot: description]). Use customer vocabulary, not internal ([internal terms to ban]). Short sentences. No "simply click." Provide 3 title variations for search optimization.

Building a Product or Service FAQ

An FAQ built on real questions received, sorted by frequency and customer journey stage.

Build the FAQ for [product or service] by [company]. Raw material: [actual questions from support, customer emails, sales objections]. Customer journey: [stages: pre-purchase, ordering, usage, billing, cancellation].

Produce: A list of 15 to 20 selected questions, phrased as customers ask them (use their vocabulary). Group by journey stage. Provide a complete but short answer for each (max 80 words, include specific data where it exists: deadlines, amounts, conditions: [exact data to integrate]).

Rules: A real answer for every question (never use "contact support" as the only answer). Own the difficult answers (fees, delays, product limits) rather than omitting them: an FAQ that dodges generates tickets. Flag questions where the answer requires me to invent info: list them at the end as "to be completed" instead of guessing. Format: Organized by section, ready to publish.

Structuring Your Help Center Hierarchy

A help center plan organized by customer problems, not internal org charts.

You are the Customer Experience Lead. Structure the help center for [company] ([product or service], audience [audience]). Current state: [status: none, messy FAQ, scattered articles]. Primary contact reasons: [reasons by volume].

Produce the full hierarchy: 5 to 7 categories named by customer intent ("My Order," "Payments & Refunds"...) and never by internal departments. For each category, list articles to create, ranked by priority (avoidable ticket volume first). Define the format for each (step-by-step, timeline table, short video) and a search-oriented title.

Add: The top 5 articles to write first with justification. Maintenance rules (who reviews what, how often, update triggers when the product changes). Placement of human support contact points (visible without sabotaging self-care). Format: Indented hierarchy + action plan.

Writing Support Chatbot Scenarios

Chatbot flows that resolve simple requests and hand off to humans at the right time.

Write the support chatbot scenarios for [company]. Requests to cover: [3 to 5 simple, frequent reasons, e.g., order status, hours, return procedure]. Technical capabilities: [what the bot can do: read order status, create a ticket, provide links]. Human escalation: [agent availability].

For each reason, write the full dialogue tree: Path welcome message, bot questions with clickable choices (2 to 4 options, never open questions when a choice suffices), final drafted answers, and the human exit point.

Non-negotiable rules: The bot introduces itself as a bot (no fake human names). The exit to an agent remains accessible at every step. The bot passes everything the customer already said to the agent (customer NEVER repeats). On the 2nd failure to understand, offer a human. Format: One tree per reason with drafted lines.

Creating Live Chat Response Templates

Short messages adapted to chat rhythm: greeting, waiting, resolution, closing.

Create live chat message templates for [company] ([product or service], tone [style]). Situations to cover: Greeting and intake, asking for patience while the agent searches (with a specific delay, not just "one moment" that lasts 8 minutes), info request, solution announcement, transfer to a colleague (explaining why and passing context), closing with summary, and out-of-office message with alternatives.

Chat constraints: Max 2 sentences per message. One piece of info per message rather than a block of text. Warn before any silence longer than 2 minutes. No fake immediacy ("I'll look into that right now" followed by 10 minutes of void).

For each template: Text with placeholders, exact usage situation, and the classic error it avoids. Add the transition rule: 3 signals that indicate it's time to offer a call rather than continuing in writing.

Managing a Customer Complaint on Social Media

A fast public response and a move to private messaging, without creating a public spectacle.

A customer publicly tags [company] on [network: X, Instagram, Facebook, LinkedIn]: [content of public message]. Internal context: [what we know about the file]. Visibility: [reach: a few views, trending, influencer].

Draft: The public response (max 2 sentences: acknowledge, show it's being handled, invite to DM without looking like you're hiding; the public judges the company on this response, not the initial fault). The first private message that picks up the file without making the customer repeat themselves. The public closing response once resolved if the thread remains visible.

Rules: Respond fast even without a solution (intake confirmation is written before knowing the facts). No file details in public (personal data). Never use a defensive or ironic tone even if the customer is in bad faith. Do not delete the comment unless it contains specific insults. Add the internal alert criteria: when this thread should be escalated to [manager].

Defining Ticket Queue Prioritization Rules

A priority system based on customer impact, applicable in 10 seconds by any agent.

You are the Support Manager for [company] ([product or service], [volume] tickets per [period], team of [size]). Currently, the queue is first-come, first-served, and true emergencies wait behind general questions.

Build our prioritization system: 3 or 4 priority levels defined by real customer impact (blocked in activity, hindered with workaround, non-urgent question). For each level, provide concrete examples from our reasons ([frequent reasons]), target first-response and resolution times, and the tie-breaking rule when everything seems urgent.

Add: Criteria that upgrade a ticket (customer in a critical period [context, e.g., wedding, moving, tax deadline], recurrence of the same issue, missed commitment by us). Criteria that do NOT upgrade (the customer who yells loudest, order value alone). Include the 10-second test: an agent must be able to categorize without thinking. Format: Grid + 10 example tickets categorized and justified.

Setting Realistic Service Level Agreements (SLAs)

First-response and resolution SLAs by channel and priority, achievable with real headcount.

Help me set the support SLAs for [company]. Situation: [ticket volume by channel and period], headcount [staff and coverage hours], current observed delays [current delays if known]. Customer expectations: [competitive context or current promise].

Propose: First-response and resolution SLAs by channel (email, chat, phone, social) and priority level, consistent with real headcount. Be honest: tell me if an ambition is unattainable with the described resources and what would be needed to meet it.

Distinguish: Internal SLA (team goal) vs. public promise (always more conservative). Define "useful first response" (real intake, not an auto-reply that cheats the clock). Add: Measurement (KPIs, how to count business hours), weekly review ritual, and protocol when an SLA is about to be missed: notify the customer before the deadline, not after. Format: SLA table + application rules.

Apologizing for an Abnormal Response Delay

Picking up a ticket left too long without a reply, with a brief apology and a real answer.

A [company] ticket has been left for [duration] without a response, beyond our standard ([usual delay]). Real cause: [cause: volume spike, lost in transfer, human error]. Customer's request: [initial request].

Draft the pickup response: The apology in ONE sentence, sincere and without pathos (the customer wants their answer, not our self-flagellation). An honest one-sentence explanation if it exists (without detailing internal mess or blaming a colleague). Then IMMEDIATELY provide the full answer to the initial request: the answer repairs the relationship, not the apology. If a full answer isn't possible yet: state what is being done, what remains, and a firm date for the next update.

Add: Any gesture if the delay caused real harm ([gesture policy]). A variation for when the customer followed up multiple times with annoyance. A variation for when the delay was due to info WE needed from them but asked for poorly. Max 120 words per version.

Escalating a Ticket to Tier 2 Without Info Loss

An internal escalation template that prevents the customer from repeating themselves and Tier 2 from re-asking.

Create the ticket hand-off template from Tier 1 to Tier 2 (or [technical team]) at [company]. Current problem: Escalated tickets go back with questions already asked, and Tier 2 wastes time rebuilding the history.

The template must include: 2-line problem summary (observed symptom, not interpretation). Customer impact (blocked or not, since when, occurrences). Environment and references ([useful fields: order #, version, browser, account ID]). What has already been tried and the result of each attempt. What the customer has already provided (attachments, screenshots). The specific question for Tier 2 (escalation without a question is just shifting work). The commitment given to the customer (promised timeline).

Add: 3 objective criteria justifying escalation (and 2 cases that don't). The message to the customer announcing the hand-off without internal jargon. The ownership rule: who replies to the customer during escalation. Format: Template with fields + filled example.

Documenting Internal Refund Procedures

The operational step-by-step for a refund: checks, entry, promised timelines, and traceability.

Document the internal refund procedure for [company] support agents. Tools: [tools: payment platform, back-office, ticketing tool]. Commercial policy: [eligibility rules and caps per agent profile].

Draft the full step-by-step: Preliminary checks (eligibility per policy, refund already processed on this order, original payment method still valid). Entry in [tool] step-by-step. Exact amount (product only, shipping, partial payment by credit or gift card). The message to the customer with realistic bank processing times by payment method. Traceability (what to log in the ticket: amount, reason, authorization).

Add: 4 specific tricky cases ([frequent cases, e.g., expired card, partial return, installment payments]) and their handling. Include the authorization threshold table by agent level. Format: Numbered procedure, "Warning" boxes for traps, final checklist.

Building a Response Quality Scorecard

A ticket review grid that grades what matters to the customer, not just script compliance.

Build the response quality scorecard for [company] support ([channels], brand voice [style]). Usage: Review of [volume, e.g., 5 tickets per agent per month] by [reviewer].

Build criteria around what matters to the customer: Request truly understood (not a generic answer). Complete answer on the first try (all customer questions addressed). Accuracy of info. Clarity (readable by the specific customer). Tone consistent with style without being robotic. Dated commitment when resolution isn't immediate. Correct ticket logging.

For each criterion: Provide a justified weight, a rating scale with observable descriptions for each level, and examples of 'good' vs 'bad.' Usage rules: The grid is for growth, not punishment; every deduction must be demonstrable in the ticket. Format: Scorecard + 1-page reviewer guide.

Giving Quality Feedback to a Support Agent

An individual debrief built on real tickets, balanced and growth-oriented.

Prepare my monthly quality debrief with [Agent Name], a support agent at [company] for [tenure]. Material: [monthly quality scorecard results: strengths observed, gaps found with ticket references]. Context: [context: high volume, new reasons, difficult period].

Structure the 30-minute meeting: Start with their self-assessment (specific questions to kick it off). Highlight strengths with specific ticket examples (vague praise is worthless). Focus on ONE priority growth area (not five) illustrated by 2 tickets. Search for the root cause with them (lack of info, fuzzy procedure, habit) before prescribing. Define a concrete action with a deadline. State what I (the manager) will fix if the cause is a tool or documentation failure.

Draft phrasing for difficult moments: A repeated gap despite a previous debrief, or an agent contesting the scorecard. Tone: Direct and supportive, never paternalistic.

Building a New Agent Onboarding Plan

A 4-week skill-building plan, from product knowledge to autonomous ticket handling.

Build the onboarding path for a new support agent at [company] ([product or service], channels [channels], tools [tools]). Target time to full autonomy: [duration]. Trainer available: [who trains and for how long per day].

Break it down by week: Week 1, Know the product as a customer (actually use it, order, encounter problems) and shadow agents. Week 2, Handle simple reasons ([simple reasons]) with 100% review of responses before sending. Week 3, Expand to complex reasons with sampled reviews. Week 4, Supervised autonomy and handling first sensitive tickets with help.

For each week: Define observable goals, concrete exercises (including responding to anonymized real tickets), criteria for moving to the next week, and the trainer check-in. Add a list of 10 core knowledge points to validate ([house specifics]) and the validation quiz format. Format: Weekly schedule + validation checklist.

Writing the Support Tone of Voice Guide

A team style guide with before-and-after examples to ensure consistency without sounding like robots.

Write the support tone of voice guide for [company] ([product or service], audience [audience], brand positioning [positioning]). Current state: Every agent writes differently, from too dry to overly casual.

Produce: 4 or 5 principles of our voice (each in one sentence, with its implication AND its limit: e.g., "Warm" without excessive emojis, "Direct" without being blunt). Finalized choices (formal vs casual, emojis, exclamation points, humor limits, "I" vs "We"). Lexicon (house words to use, internal terms to ban with customer-facing translations). 6 before-and-after examples for real situations: announcing a delay, refusal, apology, good news, angry customer, technical question.

Golden rule: The guide frames the tone, never the substance; an agent must be able to deviate when humanity requires it. Format: Max 2-page guide, applicable tomorrow.

Creating a Post-Ticket Satisfaction Survey

A short CSAT survey sent at the right time, with questions that produce actionable data.

Create the post-ticket satisfaction survey for [company] ([support channels], delivery tool: [tool]). Goal: Measure support quality AND gather actionable feedback without survey fatigue.

Produce: The timing (after closing, with relevant delay: immediate for simple questions, delayed if the solution needs customer verification). The main satisfaction question with its scale (justify the scale choice and stick to it: changing it breaks history). ONE well-phrased open question ("What could we have done better?" rather than "Any comments?"). A conditional question for low scores (offer a callback: a bad score without follow-up is a lost opportunity).

Draft: The full delivery email (max 40 words before the question; rating should be one-click from the email). Anti-fatigue frequency rule (e.g., an active customer doesn't get 5 surveys a month). Internal response circuit: who reads, who calls back dissatisfied customers, and within what timeframe.

Launching an NPS Campaign and Follow-ups

The full NPS survey: question, follow-up, and differentiated handling of responses.

Prepare the NPS campaign for [company] ([product or service], base of [volume] customers, last NPS: [previous score or first measure]).

Produce: The survey email (standard "How likely are you to recommend..." 0-10 scale, an intro sentence giving a real reason to reply, a 30-second time commitment promise). A single follow-up to non-responders ([delay] later, different angle, no guilt-tripping). The treatment plan by segment: Thanking Promoters with a concrete next step ([action: public review request, referral program]: without immediate follow-up, a declared promoter is wasted). Follow-up question for Passives (what's missing for a 9?). Personal callback for Detractors within [delay] with a call script (listen, don't defend, one concrete commitment).

Rules: Never solicit a specific score ("give us a 9 or 10"). Respect anonymity if promised. Format: Emails + call script + campaign calendar.

Analyzing Customer Survey Verbatims

A synthesis of verbatims sorted by theme and severity, separating facts from impressions.

Analyze these customer verbatims for [company], from [source: NPS, CSAT, online reviews, tickets] over [period]: [pasted verbatims].

Produce: Categorization by emerging themes (don't force pre-set categories). For each theme, provide mention volume, dominant sentiment, and 2 exact representative quotes (never rephrased). Distinguish between factual friction (bugs, delays, broken promises) and perceptions (feeling expensive, complex) which are handled differently. Identify "weak signals": rare but serious mentions ([examples: mention of leaving, named competitor comparison, security issue]) to be escalated even if volume is low.

End with: Top 3 actions suggested by the verbatims (each linked to the quotes justifying it). State what this corpus does NOT allow you to conclude (sample size, collection bias, missing silent customers). Do not invent verbatims or missing data.

Retaining a Customer Requesting to Cancel

A respectful retention script: understand the root cause before offering anything.

A customer of [company] is asking to cancel [subscription or service, tenure, amount]. Stated reason: [reason]. Account history: [usage, past incidents, recent exchanges]. What I can offer: [levers: price adjustment, plan change, pause, onboarding help].

Build the retention exchange flow: Acknowledge receipt WITHOUT obstructing (confirm cancellation will be done if they proceed: the customer must feel free, not trapped). Ask ONE sincere question to understand the real cause (the stated reason is often the short version). Based on the revealed cause, provide the response: Solvable problem (solve it first, retention second). Plan mismatch (offer the right one, even if cheaper: an honest sale today is a customer tomorrow). Price (one-time price lever with clear duration, never a forever discount that punishes loyal customers). Decided departure (cancel cleanly and leave a good last impression).

Draft phrasing for each branch and list 3 prohibited practices (forced retention, guilt-tripping, intentionally difficult procedures).

Designing a Non-Trap Cancellation Flow

An honest cancellation flow that attempts legitimate retention without being an obstacle course.

Design the online cancellation flow for [subscription or service] at [company]. Constraints: Cancellation must be as simple as signing up, but we have the right to attempt honest retention during the process.

Map the flow screen-by-screen: Confirmation of intent with a factual summary of what the customer loses (data, history, earned benefits: informative, not threatening). ONE question on the reason (clickable choices + optional text field). ONE proposal tailored to the chosen reason (lower plan if too expensive, pause if temporarily unneeded, help if usage issue: never more than one counter-offer). Then one-click cancellation confirmation with effective date and summary email.

Draft all screen text. Prohibited: Deceptive buttons (bright "Stay," hidden gray "Leave"), repetitive steps, mandatory phone calls, or guilt-tripping ("your team will be sad"). Add the confirmation email and a "welcome back" message for the future.

Writing a Win-Back Campaign for Former Customers

Segmented win-back emails based on departure reason, with a real reason to return.

Write the win-back campaign for [company] targeting customers who left [duration] ago. Segments by known departure reason: [segments: price, missing feature, poor experience, need disappeared, unknown]. What has changed since: [real, verifiable improvements].

For each segment, draft a specific email: Acknowledge the departure without drama. Announce what has changed LINKED to their reason (for the "missing feature" segment, talk about the new feature, not a discount; do not promise anything not in the real improvement list). A simple return offer ([return offer if planned]). A clean exit (unsubscribe link: never write to those who ask again).

Constraints: Max 90 words per email. No sappy "we miss you." No automatic discounts that teach customers to leave to get better prices. Add: Sending order of segments and campaign stop criteria.

Checking Satisfaction After a Sensitive Resolution

A Day+7 follow-up message for difficult cases to confirm the problem hasn't returned.

Create post-resolution follow-up messages for [company] for sensitive cases: [types: major incident, customer who threatened to leave, commercial gesture granted, recurring issue finally fixed].

For each type, draft the message sent [delay, e.g., 7 days] after closing: Verify the solution holds up (specific question about the original problem, not a vague "is everything okay?"). Show the file isn't forgotten just because the ticket is closed. Reopen the channel without friction if the issue returned.

Rules: Max 60 words. Explicit reference to the fixed problem ([field: file summary]). Signed by the person who handled it (human continuity matters). No sales pitches in this message (a follow-up that ends in a promo destroys its own effect).

Add: Triggering rule (which files deserve this follow-up to avoid diluting it). Protocol if the customer responds that the problem is back: treatment priority and who takes the file.

Notifying Customers Before They Complain

Proactive messages about internally detected issues, sent before the wave of tickets hits.

We have detected an issue at [company] before most customers noticed: [issue: shipping delay, batch defect, pricing error, failed maintenance]. Affected customers: [identifiable scope]. Fix: [plan and timeline]. History: Affected customers haven't reported anything yet.

Draft the proactive message: Announce the problem simply before they discover it (notifying them first turns a future detractor into a respected customer). State exactly who is affected and how to check. State what we are doing and the timeline. State what the customer needs to do if there is an action on their part ([action if any]). State the gesture applied automatically if harm is certain ([gesture]): without the customer having to ask.

Provide 3 formats: Email to affected customers, standard response for support when questions arrive, website notice if scope is broad. Rules: No minimizing ("slight hiccup"), no internal jargon, date of next update if ongoing.

Setting Boundaries with Abusive Customers

A progressive written framework for insulting or litigious customers that protects the team.

You are the Support Manager for [company]. A customer is repeatedly crossing boundaries: [behaviors: insults to agents, harassment/spamming, threats, out-of-scope demands, documented bad faith]. History: [dated facts]. Commercial value: [context, noting it doesn't justify abuse].

Build the progressive boundary framework: Level 1, Polite mid-interaction correction (exact phrasing: address the request AND name the unacceptable behavior without negotiating). Level 2, Formal boundary letter (dated facts without emotional language, what we will continue to provide, new interaction rules: single channel, single point of contact, standard timelines). Level 3, Termination of business relationship if contractually possible ([contract status]), phrased factually with what remains due on both sides.

Add: Team protection (right to end an insulting call/chat, visible management support, incident logging). Always distinguish: A customer who is rightfully frustrated (to be fixed) vs. an abusive customer (to be bounded).

Reacting to a Payment Dispute (Chargeback)

A response to a customer who initiated a chargeback, aimed at resolving it directly without escalation.

A customer of [company] has disputed a payment with their bank (chargeback) instead of contacting us: [context: amount, product/service, apparent reason, customer history]. Our position: [our view: our error, misunderstanding, service delivered, suspected friendly fraud].

Draft the message to the customer: Reach out without blame (many customers don't know a chargeback is a formal dispute and not just a refund). Rephrase our understanding of their dispute. Offer direct resolution based on our position (immediate refund if we are at fault: faster for them than the bank process; factual explanation with proof if service was delivered). State what happens next based on their reply.

Rules: No threats or accusatory tone (the file may end in arbitration: every word must be presentable). No promises to waive our rights. Factual throughout. Add internal note: Evidence to gather now for the dispute response ([types of proof available]).

Announcing Changes to Terms or Operations

An announcement for changes impacting customers: full info, notice period, and reaction management.

Draft the communication for [company] to announce: [change: updated Terms of Service, feature modification, support hour changes, new ordering process]. Concrete impact: [what changes in their daily life, who is affected]. Effective date: [date]. Contractual notice period: [obligations].

Structure the email: The change must be clear in the subject line and first sentence (avoid "we are evolving our services"). List what changes concretely FOR THEM (before / after). State why (the real reason in one sentence, even if prosaic). State what they must do if an action is required ([required action or none]). State where to ask questions.

Add: Standard support response for 3 predictable reactions ([expected reactions]). A variation for customers truly penalized by the change (acknowledge it, state the offer: [compensation or alternative]). Include the timeline: Announcement, reminder before effective date, Day-of message if necessary.

Announcing Product or Service End-of-Life

An end-of-life announcement that organizes customer transition rather than abandoning them.

Draft the end-of-life announcement for [product or service] by [company], stopping on [date]. Active customers affected: [volume and profiles]. What we offer: [next steps: replacement product, assisted migration, prorated refund, nothing]. Reason: [real reason].

Structure: Clear announcement at the start (product stops on [date], no euphemisms like "range evolution"). Full timeline (how long it works, intermediate milestones: [milestones: sales end, support end, shutdown]). What the customer must do and by when, with the simplest path ([migration or alternative]: detail steps and what we handle). Financial handling (current subscriptions, prorata, commitments). Dedicated contact channel.

Rules: Generous notice period. No data loss without a proposed exit (export possible until [date]). Offer the replacement without forcing it. Provide: Announcement email, 2 timeline reminders, standard support response. Tone: Respectful of the customer who chose this product.

Building the Weekly Support Report

A one-page team report: volumes, timelines, key reasons, and requested decisions.

Build the weekly support report template for [company], intended for [recipients: management, product team]. Data available in [tool]: [available metrics: volumes by channel/reason, first-response/resolution times, satisfaction, backlog].

Structure the one-page report: 3-sentence summary (weekly trend, highlight, requested decision if any). Key figures in a table with week-over-week comparison (only using listed available metrics). Shifting reasons (what's up, what's down, and a hypothesis for the cause to verify). Product team feedback (top 3 customer friction points with verbatim). Backlog status with a plan if it's growing.

Rules: A number without comparison or threshold means nothing (every metric shows its reference). No self-congratulation or doom-mongering. Readable in 3 minutes. Provide the template and a filled example with dummy data marked as such.

Organizing the Monthly Support-Product Meeting

A ritual where customer friction points reported by support become tracked product decisions.

Organize the monthly meeting between support and the product team at [company]. Current problem: Support sees friction first but feedback gets lost; Product discovers issues later through other channels.

Design the ritual: Support-side prep (top 5 friction points of the month, each documented in 4 lines: symptom, ticket volume, customer verbatim, current agent workaround). 45-minute agenda (review new friction points, explicit decision on each: planned fix with date, officialized workaround, or reasoned rejection: a motivated 'no' is better than silence). Review of last month's decisions (what was done, what slipped). Feedback loop to agents: what was decided so they know what to tell customers.

Provide: Friction point template, sample agenda, decision tracking table, and the 3 pitfalls that kill this ritual (unprioritized laundry list, blame game, ownerless decisions) with their safeguards.

Preparing Support for a Peak Activity Period

A capacity plan for sales, holidays, or launches: priorities, extra help, macros, and trigger thresholds.

Prepare [company] support for the peak activity of [event: holidays, sales, product launch, TV campaign], expected from [period]. References: [history of last peak if known: volumes, motifs dominants, what broke]. Team: [normal headcount, possible reinforcements].

Build the plan: Load forecast by channel and reason (based only on provided history: if none, propose a method to estimate without inventing numbers). Announced "degraded mode" (temporarily longer response times: communicated BEFORE on [supports], rather than subis en silence). Processing priorities during the peak (what we handle first, what we explicitly defer). Macros and help articles to prepare for peak reasons ([expected reasons]: list to draft before the rush). Reinforcement prep (express training, scope limited to simple reasons, relecture). Numerical trigger thresholds: at what backlog level do we trigger which [available levers].

Format: Plan dated backwards from the start of the peak + threshold table + pre-drafted communication messages.

Test these Customer Support prompts on your data

Copy a prompt, open it in GPTPro, and compare responses from Claude, GPT, Gemini, and Mistral for your specific use case.