How to Run an AI-Assisted QBR
Utilization charts answer a question your customer never asked. Here's how to build the review around what they've already committed money to instead.
Utilization charts answer a question your customer never asked. Here's how to build the review around what they've already committed money to instead.
Most quarterly business reviews open with a utilization chart. Seats provisioned, seats active, month-over-month adoption. Everyone nods, nothing changes, and six months later the renewal is contested and nobody on the customer side can say what the platform did for them.
I don't think the chart is wrong. I think it's answering a question the customer never asked. Utilization tells you whether people logged in. The executive in the room is trying to decide whether a line item survives the next budget cycle, and login counts don't help them with that.
So this is a method for building the other kind of review. It uses AI to do the correlation work that nobody has time to do by hand, but honestly, the AI isn't the interesting part. The interesting part is changing what goes in.
Start with three sources, and notice that only one of them belongs to you.
What the customer said they wanted. Whatever they told you during the sale, at kickoff, or in any executive conversation since. Their words, not your summary of them. If you can't find these written down anywhere, that's your first finding.
What they've said in public since. Every company publishes a running account of what it thinks it's missing. Open roles are the easiest version to read. A job posting is dated, specific, and costs real money to place, so nobody does it casually.1Job postings are public, dated, and specific, which makes them the rare customer signal you can act on without asking anyone's permission or waiting on a data request. It isn't the only signal, though. An earnings call, a risk factor in an annual filing, a new market, a reorg, a named executive hire, a published roadmap, an open RFP. Each one is a dated, public statement that some problem is worth money to them.
Pick the signal your platform actually bears on. If what you sell makes people better at something, open roles are usually the right read, because a requisition is a company saying in public that it can't do a thing with the people it has. If you sell infrastructure, the signal is more often a commitment they've announced and now have to deliver against.
Either way the test is the same: public, dated, and expensive enough that they meant it.
Your platform data. Last, and only as evidence for a claim you've already formed from the first two.
Two of the three belong to the customer. The one that belongs to you goes last, and that's most of the discipline.
The order matters. Start with your own data and you'll end up narrating it, and narrated data is a utilization chart with better adjectives.
Here's the question the whole method turns on:
Of the things this customer has already committed money to fixing, which ones are they paying for twice?
That question puts your platform inside a decision the customer is already making, with a budget already attached, at a price they've already accepted.
The overlap is the finding. It's a claim about money they've already committed, not a claim about adoption.
Here's one example, with a skills platform reading the hiring signal. Take the shape, not the signal.
Meridian Freight, a logistics company, 4,200 employees, three years into a platform agreement. Fictional, but the shape is borrowed from real accounts.
The recruiting and the capability are pointed at the same skill, in the same part of the business.
The finding writes itself. Meridian is paying to recruit a skill that 340 of their existing people have already demonstrated, and the recruiting is happening around a department with a retention problem. That isn't an adoption story. It's a claim about money they're already spending, and it lands with a VP of Operations in a way that "adoption is up twelve percent" never will.
Swap the signal and the shape holds. A security platform reads a compliance regime the customer has publicly committed to, and asks which of those controls they already own and haven't deployed. A data platform reads an announced expansion into a new market, and asks which of the pipelines that expansion needs already exist. The evidence changes. The question doesn't.
Notice what made it work. The finding is about their business. Your platform shows up in it, but it isn't the subject of the sentence.
Once you have the correlation, the economics follow a shape the customer already understands, because it's the same shape they use for every other spending decision.
Against whatever they're already funding, there are three quantities the customer can supply and check for themselves:
You don't need precision here. You need the order of magnitude to be obviously in one direction, and you need the customer to recognize their own numbers.
One hard rule, and I'd hold this one firmly: the person running the review doesn't produce pricing. Not a number, not a range, not a hint. What their current approach costs is the customer's number. Contract value is the renewal owner's number.
The single biggest improvement you can make is to stop trying to do this in one session.
The pre-call deck presents hypotheses. Here's what we think your objectives are. Here's what your public signals suggest you're short on. Here's where we think your existing capability sits. Every one of these is framed as a question, and the whole ask of the meeting is: which of these is right?
The post-call deck presents the plan. Now the objectives are confirmed in the customer's own words, the gaps are ones they agreed exist, and the ninety-day plan addresses gaps they named rather than gaps you inferred.
This costs you an extra meeting, and in my experience it's worth it every time. A plan built on confirmed premises survives a change in sponsor. A plan built on your inference doesn't.
Two practical notes. The decks need to land close together, within a week or two, or the customer loses the thread and you burn the goodwill the first meeting earned. And the pre-call deck should look visibly incomplete, on purpose.
Any AI-assisted version of this will happily produce a well-formatted answer built on nothing, because that's the failure mode of the technology. In customer-facing work that isn't a small error. It's the thing that gets someone embarrassed in front of an executive who knows their own business better than you do.
Three rules, and each of them makes the output more useful by making it narrower.
The confirmed objectives from the post-call deck are the most valuable thing this process produces, and they're almost always lost. They live in a deck in someone's drive and never reach the system of record, so the next person to touch the account starts from zero.
Whatever your process produces, make it map cleanly onto the fields your CRM or success platform actually has. Objective, outcome type, KPI target, current measure, evaluation period, due date. If a human has to reinterpret the output before it can be entered, it won't get entered.
This is the least glamorous step, and it's the one that decides whether the work compounds or evaporates.
The reframe isn't a presentation trick. Starting from what the customer has said in public, rather than from your own usage data, forces you to know something about their business they didn't tell you, and to be useful about it. That's the whole job. The AI just makes it fast enough to do for every account instead of the three you were already worried about.
If you try one thing from this, pick a single account and find one thing they've publicly committed money to this year. Put it next to what your platform says they already have, and see what the gap tells you. It usually takes about twenty minutes, and it usually changes what the meeting is about.
And if you try it and something surprising falls out, I'd love to hear about it.