AI prompts for customer success managers

10 free prompts · tested in ChatGPT, Claude & Gemini · browse the full library

Prepare a quarterly business review from raw account data

Turn usage data and account notes into a structured, confident QBR.

Build a quarterly business review (QBR) structure from the account information below.

Customer: customer name
Their stated goals at onboarding: onboarding goals
Usage and metrics this quarter: metrics
Recent interactions (support, calls, emails): recent interactions
Renewal date: renewal date

Produce:
1. **Account health summary** — one sentence, honest.
2. **Three proof points of value delivered this quarter** — specific outcomes the customer can verify. Feature usage stats do not count.
3. **Risks the customer hasn't raised** — signals in the data or interactions that suggest a problem they may not have named yet.
4. **One joint goal for next quarter** — tied to their onboarding goals. Our product roadmap is irrelevant here.
5. **The renewal conversation starter** — one sentence that opens the renewal conversation from a position of value. Do not use urgency.

If the data is too thin to support a specific proof point, say so.

Why it works: QBRs built from data dumps look like data dumps. The 'risks they haven't raised' section is what separates a consultative CSM from a reporter — it demonstrates you understand the account, not just the metrics.
What to swap: Anchor every proof point to the customer's own stated goals — a metric they didn't care about at onboarding is not a proof point.

Identify churn risk signals in recent customer communications

Find early warning signs buried in emails, tickets, and call notes before they become a cancellation.

Analyze the customer communications below for churn risk signals.

Customer: customer name
Account context: account context (e.g. "12-month contract, up for renewal in 90 days, 3-seat team")

Communications (paste emails, support tickets, call notes, Slack messages):
"""
communications
"""

Extract:
1. **Disengagement language** — verbs and phrases that suggest the customer is working around the product.
2. **Complaint type** — is this about product (fixable), process (manageable), or value (serious)?
3. **Decision-maker signals** — any new people CC'd, changes in who is responding, or drop in response frequency.
4. **Last positive signal** — the most recent communication where the customer expressed satisfaction or forward momentum.
5. **Overall risk rating**: Low / Medium / High — with one sentence of reasoning.
6. **Fastest intervention** — the one action most likely to change the trajectory this week.

Why it works: Churn rarely announces itself. The signal most CSMs miss in a long thread is a verb that describes a workaround: 'we've been exporting', 'we just do it manually', 'we stopped using'.
What to swap: Paste everything: support threads, call notes, Slack DMs, email chains. The model is pattern-matching across sources — thin input produces low-confidence output.

De-escalate an angry customer without making promises you can't keep

Draft a reply to a high-stakes complaint that calms without over-committing.

Write a de-escalation email to an angry customer.

What specifically went wrong: what went wrong
The impact on the customer (in their own terms): customer impact
What I can actually commit to doing next: committed next step
Timeframe I can realistically hit: realistic timeframe
What I cannot promise: cannot promise

Write a reply that:
1. Acknowledges what specifically went wrong. No generic "we're sorry for the inconvenience"
2. Names the impact in the customer's terms
3. States the committed next step with the realistic timeframe
4. Closes with one human question (not a ticket number or a satisfaction survey link)

Banned phrases: "we apologize for any inconvenience", "rest assured", "we value your business", "as per", "going forward".

Why it works: AI-generated apologies are the most recognizable corporate template in customer communications. The banned-phrase list and the specific-commitment constraint produce replies that sound like a person wrote them.
What to swap: Replace the cannot_promise field honestly — a commitment you can't keep turns a recoverable escalation into a lost account.

Build a 90-day success plan for a newly onboarded customer

Give a new customer a concrete picture of what success looks like — and what their role is in getting there.

Write a 90-day success plan for a newly onboarded customer.

Customer: customer name
Their stated business outcome (from the sales process): stated outcome
Their team size and technical level: team context
Key stakeholder who owns success on their side: champion

Structure the plan around what the customer achieves, never around product milestones:

**Day 1:** What the customer should be able to do or see. Be specific; "complete setup" is not an answer.
**Week 1:** The first signal that tells both sides this is working.
**Day 30:** The first win measurable by the customer in their own terms.
**Day 60:** Evidence that the whole team has adopted it, beyond the champion.
**Day 90:** The business outcome they agreed to in the sales process — stated in their language.

Also include:
- **The one thing that sinks this plan in week 1** if not addressed — and who owns addressing it.

Why it works: Onboarding plans built in vendor-language describe product completion when the customer only cares about their own outcomes. Framing each milestone from their perspective is what makes them feel like a partner.
What to swap: Anchor the Day 90 outcome to exactly what they said in the sales process — that is the number they will hold you to at renewal.

Brief the renewal conversation before it starts

Assemble what you know about an account into a plan for the renewal call.

Prepare me for this renewal conversation.

Account: account context
Contract value and renewal date: contract
Usage over the last two quarters: usage trend
Open issues and how long they have been open: open issues
Who champions us internally, and their standing: champion
What changed on their side this year: their changes

Produce:
1. Risk level, with the two or three specific signals that drive it. A general impression is not enough
2. The case they will make internally for renewing, in their words, using their metrics
3. The case someone on their side will make against renewing, argued properly
4. What I do not know that most affects the outcome, and how to find it out before the call
5. The three things to establish on the call, in order, and what to do if the first one goes badly
6. What I should not raise unless they do

Be specific about the champion risk: if renewal depends on one person, say so and say what happens if they leave.

Why it works: Writing the against-renewal case in the customer's own terms is what surfaces the objection you would otherwise meet cold on the call.
What to swap: `usage_trend` needs direction as well as level. Flat usage on a growing account is a worse signal than low usage on a stable one.

Make the case for expansion the customer would make

Build an upsell argument grounded in the outcomes the customer is already paying for.

Help me build an expansion case for this account.

What they use today, and how much: current usage
What they are trying to achieve this year: their goals
Where they are currently hitting limits: friction points
What I want to expand into: expansion target
Who would have to approve it: approver

Produce:
1. Whether this expansion actually serves their goals, honestly. If it does not, say so and stop.
2. The friction they are already feeling that this resolves, in specifics they would recognize
3. The value case in their metrics — the ones they already measure themselves
4. The internal objection the approver will raise, and the answer
5. The smallest version worth starting with, so the ask is easy to say yes to
6. The wrong time to raise this — what would have to be happening on their side for me to wait

Do not build a case around features they have not asked for and have shown no friction against.

Why it works: Making point 1 a genuine exit condition keeps the account relationship intact when the expansion is not right — which is most of the time.
What to swap: `friction_points` should come from what they have said or what usage shows. Starting from what your product solves gets you an argument they did not ask for.

Write customer comms during an incident

Communicate a live problem without over-promising or sounding like a legal notice.

Write customer communication for an incident in progress.

What is broken, in plain terms: whats broken
Who is affected and how: impact
What we know about the cause: known cause
What we do not yet know: unknowns
What we are doing: current actions
Realistic next update time: next update
Workaround, if any: workaround

Write three things:
1. The status-page entry — factual, no adjectives, states impact and next update time
2. The email to affected customers — leads with what they cannot do right now and the workaround, then what we are doing
3. The reply for customers who ask "is my data safe" or "will this happen again" while it is still ongoing

Rules:
- Never state a cause we have not confirmed. Say what we are investigating instead.
- Never give a resolution time we cannot commit to. Give the next update time instead.
- Do not apologize more than once per message, and do not use "inconvenience".
- Do not say "a small number of customers" unless you state the number.

Why it works: Committing to an update time you can actually hit is the one habit that keeps trust intact through a long incident. Fix times slip; update times do not have to.
What to swap: Fill `unknowns` honestly — it is what stops the first message contradicting the third.

Define a health score that predicts something

Build an account health score from signals that actually lead churn.

Help me define an account health score.

What our product does, and what success looks like for a customer: success definition
Signals available to me: available signals
Accounts that churned recently, and what preceded it: churn examples
Accounts that expanded, and what preceded it: expansion examples
How far ahead I need warning to act: lead time

Produce:
1. Which available signals actually lead churn by at least the required lead time, based on the examples — and which are lagging indicators that will only confirm what I already know
2. A weighting, with the reasoning for each weight
3. The threshold that should trigger action, and what action
4. What this score will systematically miss — the churn types it cannot see
5. How to check whether the score works: the specific back-test against past accounts
6. The signal I do not currently collect that would most improve this

Be skeptical of login frequency and support ticket volume unless the examples support them. Both are commonly used and commonly useless.

Why it works: Separating leading from lagging signals against real churn examples is what stops a health score becoming a dashboard that agrees with you after the fact.
What to swap: You need both `churn_examples` and `expansion_examples`. A score built only on churn will flag every quiet, healthy account.

Turn support tickets into product feedback that gets acted on

Convert a pile of tickets into a prioritized, evidenced case for product.

Turn these support tickets into feedback product will act on.

Tickets: paste tickets here
Period covered: period
Total tickets in period, for context: total volume
What product is currently working on: current roadmap

Produce:
1. Themes derived from the tickets, each with: ticket count, share of total volume, and the accounts affected with their contract value
2. For each theme, the underlying problem behind the requested feature. Customers ask for solutions, so the request is rarely the problem
3. Which themes are workflow problems and which are missing capability. These go to different places.
4. Two verbatim quotes per theme, unedited
5. Ranked by cost: support time plus revenue at risk. Ticket count is not the ranking
6. What is already on the roadmap and would resolve a theme, so I stop escalating it
7. The one theme worth raising this cycle, with the case in three sentences

Do not present ticket count alone as priority. Ten tickets from one frustrated account is not the same as ten accounts.

Why it works: Ranking by cost is what makes support feedback legible to product. Count alone reads as noise from a queue.
What to swap: Include `total_volume`. Twenty tickets is a crisis or a rounding error depending on the denominator.

Hand over an account without losing the relationship

Write a handover that transfers the context a new owner cannot get from the CRM.

Write a handover brief for this account.

Account and contract: account basics
Who is who on their side, and what each cares about: stakeholders
History that is not in the CRM: undocumented history
Current state: what is going well, what is not: current state
Commitments I have made, formal and informal: commitments
Renewal date and current risk: renewal

Produce:
1. The thirty-second version: what the new owner must know before their first call
2. Stakeholder map: who decides, who influences, who blocks, and the working relationship with each
3. The history that explains their current behavior — old incidents, previous promises, things they are sensitive about
4. Every commitment I have made, including the informal ones, with whether it has been delivered
5. The landmines: what an unbriefed person would say in week one that would set us back
6. What to do in the first thirty days, in order
7. What I would do differently if I were staying

Be specific about the informal commitments. Those are the ones that get broken, because they are the ones not written anywhere.

Why it works: The informal commitments and the landmines are the entire value of a handover — everything else is already in the CRM.
What to swap: Write `undocumented_history` before you look at the CRM, or you will only reproduce what is already there.

Frequently asked questions

QBRs that surface risks the customer hasn't raised. Churn signals found before the renewal conversation. De-escalation emails that don't sound like a template. Each prompt is built for the part of the job that doesn't have a playbook. This page collects 10 free, copy-pasteable customer success prompts, each tested in ChatGPT, Claude, and Gemini with a one-line rationale and the fields you need to swap in.