The QBR Ritual That Nobody Believes In

There's a particular flavour of dread that CS Managers know well. It arrives about three weeks before quarter-end, in the form of a Slack message from the VP: "Can you make sure all QBR decks are submitted by Friday?"

The next four days are a small theatre of organised fiction. The CSM pulls last quarter's deck, updates the logo, swaps in new ARR numbers, and tries to retrofit a narrative around whatever the customer actually did, which often bears no resemblance to what the previous deck said they were going to do. They write a slide called "Your Success Milestones." They include a screenshot of a metric the customer hasn't asked about in six months. They write "Mutual Action Plan" at the top of the final slide, with three items that will never be tracked.

The meeting happens. The customer nods. The deck is filed somewhere in Salesforce. Nothing changes.

I've sat in hundreds of these. I've run dozens. And I can tell you: everyone in the room usually knows it's a ritual. The CSM knows it. The customer knows it. Often the CS leader knows it too. The question nobody asks out loud is why we keep doing it this way.

---

What the QBR was supposed to be

The idea behind a Quarterly Business Review is sound. Take a step back from the weekly noise of support tickets and feature requests. Look at the big picture. Align on whether the customer is getting value. Surface risks. Make a plan.

That's a genuinely useful conversation to have. The problem is that almost everything in the standard QBR format works against it.

The deck-first model puts the CSM in the position of narrator rather than partner. It creates a one-way information flow (here's what we've been doing) rather than a genuine examination of what the customer actually cares about. It optimises for coverage rather than insight. It fills an hour with information nobody has processed instead of half an hour on the two or three things that actually matter.

The quarterly cadence is often wrong too. Most CS teams run QBRs because "Q" is in the name, not because the customer's business naturally resets every 90 days. Some accounts need these conversations monthly. Others could have them twice a year. The cadence should come from what the customer's buying cycle looks like, not from the CS team's calendar.

---

The evolution most CS teams skip

There's a progression that high-performing CS organisations tend to go through, though they rarely describe it in these terms.

Stage one is the presentational QBR. This is the deck-heavy version. The CSM presents; the customer watches. Useful early in a relationship when the customer doesn't yet have a clear view of what good looks like. Terrible in year three.

Stage two is the collaborative review. The CSM sends materials in advance. The meeting is built around discussion rather than presentation. There are fewer slides and more questions. The agenda is built partly with the customer rather than entirely by the CSM. This is where most mature CS organisations should be.

Stage three (which most teams never reach) is what I'd call the business-led review. The CS team doesn't own the agenda. The customer brings their business problems and the CS team brings the data and context to help solve them. The product is a mechanism, not the subject of the meeting. Value is defined by the customer's outcomes, not by the vendor's feature list.

Getting from stage one to stage three requires the CS team to give up control of the narrative. That's uncomfortable. It's also where the real conversations happen.

---

The CS Ops angle

CS Operations teams can accelerate this evolution, or inadvertently slow it down, depending on what they build.

The temptation in CS Ops is to build a QBR deck template so good that the process becomes efficient. Automated data pulls, standardised sections, pre-built charts. The template becomes the process, and the process becomes the ceiling. Teams get very fast at producing stage-one QBRs.

The more useful investment is in the infrastructure that enables stage two and three. What does that look like in practice?

It means surfacing customer health data in a format that the customer can actually read, not just an internal health score, but a view of their usage, outcomes, and benchmark against similar accounts that you'd be comfortable sharing directly with the Economic Buyer.

It means building a shared success plan that lives somewhere both sides can see, not a slide that exists only in the CSM's Google Drive. A document that gets updated between QBRs because the mutual action items in it are real.

It means tracking what was committed in the last review and what actually happened. Not to score the CSM, but to create a feedback loop that makes the next review more honest than the last one.

And it means helping CSMs understand that the point of the QBR isn't to demonstrate that CS has been busy. It's to demonstrate that the customer is progressing toward something they care about. That distinction sounds obvious. In practice, most QBR decks get it backwards.

---

The question worth asking

Before the next round of QBR decks goes out, it's worth asking: if we stripped away the slides entirely and had a 30-minute conversation instead, what would we want to cover?

Usually the answer is two or three things. A risk that needs surfacing. An outcome the customer is chasing that the CS team can actually help with. A renewal conversation that needs to happen honestly rather than through the polite fiction of a metrics slide.

If those three things can fit in a deck, put them in. If they can't, the deck is the problem, not the conversation.

The QBR ritual persists because it feels like coverage. It feels like process. It looks, from the outside, like customer success work getting done. But the goal was never the deck. It was the relationship, the outcome, and the renewal. The sooner CS teams organise around that instead, the sooner the ritual becomes something worth believing in.