There is a structural problem with quarterly business reviews that most CS teams sense but rarely name directly: the data in a QBR deck is organized around what has already happened, but the conversation that matters at a QBR is almost entirely about what is going to happen next. The retrospective frame of the data and the forward orientation of the discussion are not aligned, and that misalignment creates a specific and recurring failure mode.
This is not an argument against QBRs. The format has real value. It is an argument for understanding what QBR data can and cannot tell you, so that you supplement it correctly.
What QBR data is actually built from
A standard QBR deck draws from a recognizable set of sources: product usage metrics from the analytics layer (login counts, feature adoption rates, active user percentages), support ticket volume and resolution statistics from the ticketing system, NPS or CSAT scores from the most recent survey cycle, and notes from the CSM's CRM about the relationship history. These sources have one thing in common: they all describe what happened in the past 90 days.
This is not a flaw in the sources themselves. Usage data accurately reflects what customers did. Ticket volume accurately reflects what support interactions occurred. The problem is the interpretation layer. When a CSM walks into a QBR and presents these metrics as evidence of the account's health, they are implicitly projecting past patterns into the future. "Your usage has been strong" becomes "your usage will continue to be strong." "Support ticket volume has decreased" becomes "your team has gotten comfortable with the product." These projections feel reasonable. They are also unexamined assumptions.
Where the projection breaks
The past-to-future projection fails in cases where the customer's situation has changed in ways that the retrospective data does not capture. A few specific examples.
Organizational change inside the customer. If the champion who drove adoption of your product left the company in the last quarter and their replacement is newly onboarded, the usage data for the quarter may still look strong because the outgoing champion was using the product heavily until their last week. The incoming champion has not yet made a decision about the product's place in their workflows. The usage graph shows a healthy quarter. The renewal risk is significantly elevated. The QBR data provides no signal about this transition unless the CSM independently knows about it.
Support data as a lagging indicator. Ticket volume is typically framed as a health proxy: low volume means the customer is using the product successfully, high volume means there are issues. But ticket volume is a lagging indicator of customer satisfaction, not a leading one. By the time a frustrated customer reaches peak ticket volume, they have been frustrated for a while. And by the time they stop submitting tickets, the story is ambiguous: they may have resolved their issues, or they may have stopped investing in the relationship. The data alone cannot distinguish these outcomes.
NPS timing effects. If the NPS survey landed on the account in month one of the quarter and the relationship degraded in months two and three, the score in the QBR deck reflects a point in time that is now stale. This happens more often than CS teams tend to acknowledge, because survey timing is typically set by the tool, not by the account's sentiment trajectory.
The decisions that will define next quarter are already in motion
The core reason QBR data is structurally backward-looking is that the decisions customers make about renewals are not made at the renewal conversation. They are made incrementally, over weeks and months, as the customer's team accumulates experiences with the product, encounters friction, finds workarounds, and either deepens or contracts their commitment. By the time the renewal conversation happens, the customer often already has a direction in mind.
The evidence for this direction is already in your data. It is in the ticket topics from the last eight weeks, which may have migrated from operational questions to contractual ones. It is in the email thread from last month, where the champion who used to write with enthusiasm is now writing with professional distance. It is in the support escalation that was marked resolved but was followed by two weeks of silence rather than the normal resumption of operational questions.
None of this evidence shows up in a QBR deck because QBR decks are not built to represent it. The deck shows usage graphs and ticket counts and NPS scores. The signals that actually predict the direction of the renewal conversation are in the unstructured communication record, and they are only visible if someone goes back and reads it.
The QBR as a diagnostic moment, not a reporting one
One useful reframe is to think of the QBR not primarily as a reporting event where you present historical data to the customer, but as a diagnostic moment where you use the historical data to understand what questions to ask. The historical data is not the answer to "how healthy is this account." It is the starting point for "what is happening in this account right now that the historical data does not show."
This shift changes the preparation required for a QBR. In addition to pulling the standard metrics, the CSM needs to spend time in the communication record: What topics have been coming through support recently that are different from six months ago? Has the account's email communication with our team changed in tone or volume? Was there an escalation in the last quarter, and what happened in the communication channel after it was resolved?
These are not comfortable questions to go looking for before a QBR, because the answers might require you to bring concerns into the meeting that you had not planned to raise. But walking into a QBR without that review means you are presenting a historically clean picture to a customer who may be quietly decided.
Making the forward-looking part of the QBR actually forward-looking
The part of a QBR that is supposed to be forward-looking, the goals and plans for next quarter, also has a structural problem: it defaults to repetition of the previous quarter's goals unless the CSM has specific reasons to propose something different. If the product has been used primarily for workflow X, next quarter's plan tends to default to "more of workflow X" unless the CSM has identified a specific expansion opportunity or a new workflow to propose.
Current communication signals are useful here too. If ticket topics have shifted toward questions about a different set of features, that is an indication of where the customer's workflow curiosity is actually running. If the call notes from the last account review include a mention of a problem the customer is trying to solve, that is a potential hook for a forward-looking QBR discussion. The communication record contains the customer's actual interests and concerns in their own words, which is more reliable than the CSM's assumption about what they want to hear about next quarter.
The gap QBR data cannot fill
We want to be direct about something: no amount of improvement to QBR preparation fully closes the gap between retrospective data and current account health. The structure of the QBR format is quarterly, which means there will always be a 60 to 90 day window between the last QBR and the next one where things can change significantly without triggering a systematic review.
The alternative is not to run QBRs more frequently, which is operationally impractical and often unwanted by the customer. The alternative is to have a monitoring layer that is reading current communication signals continuously, surfacing drift and escalation patterns as they emerge rather than waiting for the quarterly checkpoint. That is a different kind of infrastructure than a QBR deck, and it operates at a different cadence.
QBR data is genuinely valuable for the conversation it is designed to support. It is a record of what happened and a structured format for discussing it with the customer. What it is not is a forward-looking health signal. Understanding that distinction is the starting point for building the kind of early warning capability that makes renewal conversations less surprising.
