Tuesday, 10 am. A QBR is on Thursday for an account that renews in ten weeks. Usage dipped in the last two months, the champion changed teams, and there's an open escalation about an integration. You have a spreadsheet, forty support tickets and a call recording, and the deck is blank. AI prompts for customer success managers are most useful right here: turning raw material into an honest outline, a risk review with real questions, and a first-draft email. They're least useful when asked for a number, a prediction or a promise.
This pack follows one rule. The model organises your evidence. It does not invent benchmarks, success metrics or quotes. If a figure isn't in your data, the output should say MISSING.
These are untested templates; I haven't run them on a live account. The worked example is invented, and I checked its retention arithmetic with a short script. The same caution applies as in prompts for sales reps, which covers pre-sales; this post is for after the contract is signed.
How do I build a QBR with AI?
A good QBR answers three questions for the customer: what did we agree to achieve, what happened, and what are we doing next. Make the model follow that, and force every claim to point to a source.
You are helping a customer success manager prepare a quarterly business
review for [CUSTOMER CODE], renewal date [DATE], [PRODUCT].
INPUTS (the only facts you may use; each labelled):
- Goals agreed at last review: [PASTE, or MISSING]
- Usage data this quarter vs previous (as numbers I computed): [PASTE]
- Outcomes the customer stated (their words, with date): [PASTE]
- Support tickets summary (counts and themes I tallied): [PASTE]
- Open issues and their status: [LIST]
- Roadmap items relevant to them that are publicly committed: [LIST OR NONE]
- Stakeholders attending and their roles: [LIST]
OUTPUT:
1. A 7-slide outline: title, what we agreed, what happened (data), what
worked, what did not, risks I should raise openly, next-quarter plan.
2. For each slide: the key message in one sentence and the evidence line it
rests on (quote the input label).
3. A "hard questions" list: five questions the customer may ask, with
the honest answer based on the inputs, or "NO ANSWER IN INPUTS".
RULES:
- Do not state any metric, percentage or benchmark not in the inputs.
- Do not promise features, dates or discounts.
- Do not describe the customer's goals; quote them.
- Mark anything vague as [NEEDS DATA].
Slide 6 matters. A QBR that only shows wins gets ignored. If an integration issue is still open, say so and say what you are doing. Customers renew more comfortably with a vendor who names problems first, but check that with your own accounts; I'm stating a view, not a measured result.
How do I run a renewal risk review?
Collect the signals you have, then ask the model to turn gaps into questions. It shouldn't score or predict.
Renewal risk review for [CUSTOMER CODE], renewal in [N] weeks, contract
value [AMOUNT OR OMIT].
SIGNALS (mark each as FACT with source, or OPINION):
- Usage trend: [NUMBERS]
- Champion / sponsor status: [CHANGED / ACTIVE / UNKNOWN]
- Open escalations: [LIST]
- Support sentiment: [QUOTE 2-3 RECENT LINES]
- Commercial signals (budget talk, procurement, competitor mentioned):
[LIST]
- Contact frequency in last 60 days: [NUMBER OF MEETINGS/EMAILS]
Produce:
1. Signals grouped as: strong positive, neutral, concerning, unknown.
2. For each "unknown" or "concerning" signal, one question I should ask,
and who I should ask it of.
3. A 6-week action plan with owners, working back from the renewal date.
4. Where my FACT/OPINION split suggests I am guessing.
RULES:
- Do not give a churn probability, risk score or red/amber/green rating.
- Do not use industry churn benchmarks.
- Do not assume the customer is unhappy; list what I do not know.
You still make the call on risk. The review's value is the "unknown" column. A renewal can go wrong when nobody confirmed whether the person who controls the budget still wants the product.
Which numbers should I calculate myself, and how?
Compute retention figures in a spreadsheet and paste them. A model asked to compute them from a table of customers will sometimes get them wrong, and an NRR that's off by a point is a number that gets quoted for a year.
I checked this arithmetic with a script on invented data. One cohort started the period at 1,200,000 in annual recurring revenue. During the period it expanded by 210,000, contracted by 60,000 and lost 90,000 to churn.
NRR 105.0
GRR 87.5
Net revenue retention is (1,200,000 + 210,000 - 60,000 - 90,000) / 1,200,000, which is 105.0 percent. Gross revenue retention leaves out the expansion: (1,200,000 - 60,000 - 90,000) / 1,200,000 is 87.5 percent. Companies define these differently (time windows, treatment of price rises, which customers are in the cohort), so write your definition in the first slide and use it consistently. These figures are from invented data and are not a benchmark for anything.
Then the prompt can interpret what you computed:
Here are my computed retention figures and their definitions (do not
recalculate): [PASTE]. Write two sentences for a leadership update that
explain what they mean, name the largest driver of movement, and state
what we do not yet know. No comparison to industry benchmarks.
How do I write a health-check summary from messy notes?
Customer notes live in CRMs, call recordings and Slack. The model can compress them, if you force it to separate what the customer said from what you think.
Summarise the following notes for account [CUSTOMER CODE] from the last
[N] days.
NOTES: [PASTE, with dates and authors]
Output:
- What the customer asked for (quote, date).
- What we committed to (quote, date, owner), and whether it was done based
only on the notes.
- Concerns they expressed (quote).
- Changes in stakeholders.
- Contradictions between notes.
- Gaps: what we should know but the notes do not say.
Do not infer sentiment. Do not describe tone. If a commitment has no
evidence of completion, write NOT CONFIRMED.
"NOT CONFIRMED" is the most useful string in this pack. It surfaces the promise made in a call that nobody logged as done.
What about check-in emails and escalation updates?
Short messages, grounded in facts, and sent by you.
Draft an email to [NAME, ROLE] at [CUSTOMER] after [EVENT: a missed
commitment / an outage / a quiet period / a stakeholder change].
Facts: [WHAT HAPPENED, WHAT WE KNOW, WHAT WE DON'T]
What I can commit to: [ONLY ITEMS I HAVE APPROVAL FOR, WITH DATES]
What I need from them: [ONE ASK]
Under 140 words. Start with the substance. No "I hope this finds you well".
No apologies beyond one specific sentence. Do not promise anything not
listed in "what I can commit to".
If it's a significant escalation, have the commitments reviewed by whoever owns them internally before sending. Support and engineering own the dates.
A worked example (illustrative)
Invented scenario: renewal in ten weeks, usage down on a key module, champion changed teams, one open integration escalation. Your signals list: usage fell between the last two quarters (you computed the percentage; paste it), the new contact has not attended a call, and the customer said last quarter they wanted to "consolidate tools" (quoted, dated).
What good output looks like (shape):
Concerning: usage drop on the reporting module; champion moved; open
integration escalation; "consolidate tools" comment from last QBR.
Unknown: who now owns the budget; whether consolidation means replacing us.
Questions: (1) To the new contact: what is your goal for the product this
year? (2) To the old champion: who should I speak to about renewal? (3)
To the sponsor: is the tool-consolidation review active, and what criteria
does it use?
6-week plan: week 1 stakeholder intro; week 2 fix-or-date for the
integration issue; week 3 usage review with new contact; week 4 renewal
proposal draft; week 6 commercial conversation.
Not provided: any churn probability. I do not have data to support one.
The model has not decided the customer will leave. It has told you what you don't know, which is where the work is.
Failure modes to check for
| Failure | What it looks like | Fix |
|---|---|---|
| Invented metrics | "Customers like you see 23% improvement" | Inputs-only rule; no benchmarks |
| Promised features | A QBR slide committing a date | Forbid commitments; check with product |
| Fake sentiment | "The customer seems frustrated" | Quote-only rule; ban inferring tone |
| Churn scoring | A percentage with no basis | Don't ask; use signals and questions |
| Arithmetic slips | NRR computed wrongly | Compute in a sheet; paste results |
| Names and contracts pasted | Confidential data in a chat | Use customer codes; follow policy |
| Wins-only decks | No risks slide | Make "what did not work" a required slide |
What not to automate
- Commitments. Dates, discounts and roadmap promises come from people who own them.
- Risk judgement. You decide whether an account is at risk and what to tell leadership.
- Retention numbers. Compute and define them yourself, then explain them.
- Sensitive escalations. An outage apology or a contract dispute needs your voice and review.
- Customer data in unapproved tools. Use codes, minimise, or skip.
- The relationship. A model can draft the email. It cannot rebuild trust with a sponsor who stopped replying.
For why "only use these facts" works, see the lesson on avoiding hallucinations. For the support side of the same customer, prompts for customer support teams is adjacent, and the prompt library has a status report template that adapts well to account updates.
