How to Prepare Renewal Reviews With Customer Evidence

To prepare a renewal review with customer evidence, organize it into eight sections: renewal terms, goals stated at purchase, adoption against those goals, support history, promises made and kept, stakeholder changes, risks, and the ask. Attach a named source to every claim, such as a call recording, a ticket, an email, a usage report or the contract. Any statement that cannot point to a source goes on a separate "unverified" list, not into the review. BuildBetter Success can pull most of those sources into one place. The method below also works with the systems you already have, and it produces the same kind of document either way.

This guide covers what a renewal review is and how it differs from the renewal call. It then gives a section-by-section template with the source for each part, a prep timeline, rules for citing evidence, a hypothetical worked example, and the mistakes that most often make a review misleading.

What is a renewal review, and how is it different from the renewal call?

A renewal review is an internal meeting where your team decides what it believes about an account and what it will ask for, before anyone talks to the customer. The renewal call is the conversation with the customer that follows. The review comes first and produces the position you take into the call. If you are preparing the customer conversation itself, see our guide on how to prepare for a renewal call.

Keeping the two separate matters because they do different jobs:

• The review is for honesty. Internally you can say "we promised a feature and did not ship it" or "our champion has gone quiet" without negotiating.
• The call is for alignment. With the customer you present value, confirm goals for the next term and agree on terms.
• The review produces a decision. Typical decisions are: renew as is, renew with a remediation plan, pursue expansion, escalate to an executive, or prepare for a downgrade or churn.
• The review assigns owners. Every open risk and every unkept promise leaves the meeting with a name and a date attached.

Who attends depends on the size of the account. At minimum, include the account owner (CSM or account manager) and their manager. For larger accounts, add the AE or whoever owns commercial terms, someone from support who knows the ticket history, and someone from product if open feature requests are part of the story.

Why build the review from evidence instead of memory?

Memory gives too much weight to the most recent conversation and the friendliest contact, and usage dashboards cannot hear what customers say. A review built on recollection tends to repeat the account owner's current mood. That mood was shaped by the last call, which may have been with the one person at the customer who still likes you.

There are three failure patterns to watch for:

• Recency bias. One good call last week can outweigh three months of escalating support tickets the CSM never read.
• Champion bias. The person you talk to most is rarely the one who signs or blocks the renewal. Finance, procurement or a new executive may hold a view you have never heard.
• Usage-only health. Logins and seat counts measure activity, not satisfaction. A team can use a product every day while asking for an exit plan.

BuildBetter's Success page illustrates the third pattern. It shows an example account with 38 of 40 weekly active users and 95% of seats utilized, which a usage model scores "Healthy 92." The same account's support tickets and email contain lines like "We're evaluating alternatives" and "Can you send over what a wind-down would look like?" Once those conversations are included, the vendor's model scores the account "Critical 31." Whatever tools you use, the lesson is the same. A renewal review has to read what customers wrote and said, not only what they clicked.

The renewal review template: eight sections and the source for each

The template is eight sections in a fixed order. Each one names the system of record its evidence comes from. Keeping the order fixed makes reviews comparable across accounts and makes missing sections obvious. Each section below lists what goes in, where the evidence comes from, and the question it answers.

1. Account snapshot and renewal terms

What goes in: current contract value, renewal date, contractual notice period and deadline, whether the contract auto-renews, payment status, and plan or seat count.

Source: the signed contract or order form, your billing system, and the CRM record. Use billing as the source of truth for payment status. A CRM field someone last updated six months ago is not reliable for that.

Question it answers: How much time do we have, and what is commercially at stake?

The notice deadline is often earlier than the renewal date, and missing it changes your options. Our guide on how to track renewal notice periods covers how to keep those dates visible.

2. Goals stated at purchase

What goes in: the outcomes the customer said they were buying for, in their own words, with dates. Examples: "cut onboarding time for new support agents," "replace three spreadsheets with one system," "roll out to the second team by Q3."

Source: discovery and demo call recordings, the sales-to-CS handoff notes, the proposal or business case, and the kickoff call.

Question it answers: What did success look like to them when they signed?

This is the section most often written from memory and most often wrong. Quote the customer, not your own summary. If goals were restated later, for example at a mid-term business review, record both versions and their dates.

3. Adoption and usage against those goals

What goes in: usage metrics that map to the goals in section 2, shown as a trend over the contract term rather than a single snapshot. Include which teams or use cases adopted and which did not.

Source: product analytics, plus admin or seat data from billing.

Question it answers: Did the customer do the things that would produce the outcomes they bought for?

Do not paste a generic usage dashboard here. If the stated goal was rolling out to a second team, the relevant evidence is whether that team is active, not total logins.

4. Support history and open tickets

What goes in: open tickets and their age, recurring issues, escalations, and direct quotes that show sentiment.

Source: your support system, plus any shared Slack channels or email threads where problems were raised outside the ticket queue.

Question it answers: What has the customer's day-to-day experience been, and is anything unresolved going into renewal?

Pay attention to repeated issues. A customer who writes "this is the third time" is describing a pattern, and you should present it as one.

5. Promises made and kept, in both directions

What goes in: a commitment ledger with four columns: who promised, what, by when, and what actually happened. Include promises your team made, such as feature timelines, fixes, discounts or training sessions. Include promises the customer made too, such as rolling out to a team, publishing a campaign or connecting an integration.

Source: call recordings and transcripts, email, and Slack for what was said. Product analytics and your release history show whether it happened.

Question it answers: Where do we have credibility, and where have we lost it?

Customer commitments that quietly lapse are an early warning sign. When the customer said "we'll have the second team live by the end of the month" and usage shows nothing, the stall usually has a cause worth learning before renewal. Our guide on how to catch missed customer commitments before renewal covers this in detail.

6. Stakeholder changes

What goes in: who has joined, left or changed role on the customer side since purchase. Include the current economic buyer, the current champion, and anyone who has stopped replying.

Source: CRM contacts, email and calendar history (who attends calls now compared with who attended at kickoff), and call transcripts where people mention reorganizations or new leaders.

Question it answers: Does the person who will make the renewal decision know what we have delivered?

7. Risks, each with evidence

What goes in: a short list of specific risks. Each one includes the evidence behind it, its age, and a proposed mitigation with an owner. "Budget pressure" on its own is not a risk entry. A risk entry reads like this: "Finance asked for a usage breakdown by team on a call 18 days ago, which suggests seat reduction is being considered."

Source: everything above. The risks section should synthesize sections 1 through 6. It should not contain new, uncited claims.

Question it answers: What could stop this renewal, or shrink it?

8. The ask and next steps

What goes in: the recommended outcome and what you need internally to get there. Examples are an executive sponsor on the next call, a fix prioritized, approved pricing flexibility, or an expansion proposal. End with dated next steps, each with an owner.

Source: the decision the meeting reaches.

Question it answers: What are we going to do, and who is doing it?

How do you run the prep, step by step?

Work backward from the earlier of two dates: the contractual notice deadline or the internal review meeting. Gather evidence in the order of the template so each section can build on the one before it. The sequence below is a sensible default. Adjust the lead time to your account sizes and contract terms.

1. Confirm the dates. Pull the contract and billing record. Write down the renewal date, the notice deadline and the auto-renewal status. If the notice deadline falls before your planned review, move the review earlier.
2. Recover the purchase goals. Find the discovery, demo and kickoff recordings, or the handoff notes, and extract the customer's own statements of what they wanted. Copy quotes, not paraphrases.
3. Pull usage for the goals. For each goal, choose one or two metrics that would show progress and chart them across the contract term.
4. Export the support history. List open tickets with their age. Group closed tickets by theme. Pull representative quotes, including any from Slack or email.
5. Build the commitment ledger. Search transcripts and email for promises, both yours and theirs, and check each against product data and your release history.
6. Map the stakeholders. Compare who attended calls and replied to email at the start of the term with who does now.
7. Draft the risks. Write each risk with its citation. Then have someone other than the account owner read the underlying evidence and challenge the reading.
8. Write a draft ask and circulate the document as a pre-read. Send it far enough ahead that attendees arrive having read it, so the meeting is spent deciding rather than presenting.
9. Hold the review and record the decision. Assign owners and dates for every mitigation and open promise. Carry them into prep for the renewal call.

How should you cite evidence so the review holds up?

Cite every claim with its source, its date and who said it, and keep observed facts separate from your interpretation. A citation should let anyone in the meeting open the original and check it in under a minute. These rules keep the document honest:

• Quote, then interpret. Write the exact words first, for example "Honestly the team is losing patience with the export bugs" (call, 11 days ago, ops lead), and add your reading after it.
• Date everything. Something said nine months ago may no longer be true. Mark the age of any evidence that is old enough to matter.
• Name the speaker and their role. A complaint from the economic buyer carries different weight than one from an occasional user.
• Link to the original. Use the recording timestamp, ticket ID or email thread, not a summary of a summary.
• Include disconfirming evidence. If you believe the account is at risk, list the strongest signs that it is not, and the reverse. A review that only supports one conclusion is advocacy, not a review.
• Keep the unverified list. Things people "remember" but cannot source go on a separate list with an owner assigned to confirm or drop them.

What does a completed review look like? A hypothetical example

A completed review fits on a page or two, and every line traces back to a source. The following example is hypothetical. The company, people and numbers are invented for illustration.

Account: Fernway Logistics (hypothetical). Renewal terms: annual contract, non-auto-renewing, 60-day notice period. The notice deadline is five weeks out (source: order form; billing shows payments current).

Goals at purchase: On the discovery call, the VP of Operations said: "We want both dispatch teams on one system before peak season." The kickoff call repeated the goal and named the second team's lead as owner (source: discovery recording, kickoff recording).

Adoption: The first dispatch team is active and growing over the term. The second team has a handful of accounts created and almost no activity (source: product analytics). The goal is half met.

Support: Two open tickets about route import errors, both older than three weeks. One ticket includes: "We can't move the second team over until imports work" (source: support system, ticket thread).

Promises: Our side promised an import fix "next sprint" on a call two months ago. It has not shipped (source: call transcript; release notes). Their side committed to starting the second-team rollout by a date six weeks ago. There has been no activity since (source: call transcript; product analytics). The two are linked: their commitment stalled because ours did.

Stakeholders: The VP of Operations has not attended the last three calls. A new finance director joined the most recent one and asked about per-team costs (source: calendar history, call transcript).

Risks: (1) The renewal decision may be made by finance, without the VP's original goal in view. (2) The unshipped import fix is blocking the outcome the customer bought for. (3) The question about per-team costs may signal a plan to cut seats down to the first team only.

Ask: Prioritize the import fix with a committed date before the notice deadline. Have our VP reach out to their VP of Operations. Prepare a value summary for the finance director based on the first team's results. Owners and dates are assigned in the meeting.

A memory-based review of this account would probably have said "good relationship, first team loves it, should renew." That statement is true and also incomplete in the ways that matter most.

What are the ways to assemble the evidence?

You can assemble renewal evidence with a platform that captures conversations and product data together, by hand from your existing systems, or from CRM notes and memory. The approaches differ mainly in whether conversation evidence makes it into the review and how long gathering it takes.

BuildBetter Success records calls, Gmail and Outlook email, Slack threads and DMs, and support tickets first-hand. It connects those to CRM records, billing and contracts, product analytics and documentation. According to its Health page, every 0–100 score breaks down into the specific risk factors behind it, each with its source, and every risk flag cites the calls, tickets and messages it came from. Its commitment tracking compares what a customer committed to on a call against product usage. If nothing happened, it raises an alert such as "Commitment missed, 21 days since the stated date," with a drafted check-in. The Lifecycle page describes renewals surfacing on a schedule with the notice period attached (90, 60, 30 and 15 days), auto-renewals tracked separately, and Contracts as one view of subscriptions across Salesbricks and Stripe. The site marks parts of the renewal scheduling and retention reporting as partially shipped. Its Intelligent Reports, currently in beta, include a Churn Risk Signals report with specific quotes and recommended actions.

Whichever approach you use, the template does not change. Tooling only changes how long it takes to fill in each section and how much evidence you miss along the way.

What mistakes make renewal reviews misleading?

The most common mistake is treating usage health as account health. Close behind are reviews that skip the purchase goals or leave out promises your own team failed to keep. Other mistakes to watch for:

• Starting too late. If the review happens after the notice deadline, it can only document a decision the customer has already made.
• Reviewing only covered accounts. Accounts with no assigned CSM still renew or churn. They need at least a lightweight version of this review, even if it is assembled by ops.
• Letting the account owner be the only reader of the evidence. A second reader catches the convenient interpretation.
• Ending without owners. A risk with no owner and no date is just an observation.
• Merging the review with the call prep. The internal document will include things you would never say to the customer. Keep it internal, and write the call plan separately.

Frequently asked questions

How far before renewal should the review happen?

Hold it before the contractual notice deadline, not the renewal date. Leave enough time to act on what you find, such as shipping a fix or bringing in an executive. For contracts with long notice periods, that can mean reviewing well over a quarter before the renewal date.

What if we never recorded the original sales calls?

Use the next best written source: the proposal, business case, order form, handoff notes or kickoff email. If none of these states the goals, write "goals not documented" in section 2. That is itself a finding. Then plan to confirm goals with the customer on the renewal call.

How long should the review document be?

For most accounts, keep it short enough to read in a few minutes before the meeting, roughly one to two pages with links to the underlying evidence. Larger accounts may need more detail in the commitments and stakeholder sections. Keep the eight-section structure either way.

Should the customer ever see the renewal review?

No, not the internal version. It contains candid risk assessments and internal asks. Parts of it, such as goals, adoption progress and delivered commitments, can become a customer-facing value summary for the renewal call. Rewrite those parts for that audience instead of sharing the internal document.

What counts as a stakeholder change worth flagging?

Flag any change to the economic buyer, the champion or the main day-to-day users. Also flag a key contact who has stopped replying, and new attendees from finance or procurement. Any of these can mean the person deciding the renewal has a different picture of your value than the person who bought.

Build your next renewal review from evidence

Pick one account renewing in the next quarter. Fill in the eight sections with a source for every claim and hold the review before the notice deadline. The gaps you find are usually the most useful output. If you want the evidence for each section gathered from calls, email, Slack, tickets, billing and product analytics, with risk flags that cite where they came from, see how BuildBetter Success works against your own book.