Every quarterly business review starts with four hours of copying numbers into a deck. Here is the model behind a tool that removes that, the prompts to build it, and what it takes to run it.
Your private status link is on its way to your inbox.
A QBR prep tool is four parts: a fixed template, automatic assembly of the data that fills it, a human editing layer for the narrative and the asks, and a record of what was committed. The mistake is trying to generate the whole review. What a tool can do is gather, compare against last quarter, and flag what changed. The judgement about what it means stays with the person in the room.
QBR prep
6
Reviews next month
4
Commitments overdue
18
Metrics assembled
3
Sections that moved
Northrise Group, Q3 review
Scheduled 24 September · owner T. Okafor · renewal in 41 days
What we agreed last quarter
You run customer success, or you sit in these reviews. You already know what a good QBR covers. What you want is to arrive with a draft that is already accurate, and to spend your preparation time on the story rather than the spreadsheet.
How preparation goes from four hours of copying to twenty minutes of editing.
Same sections every time, so reviews are comparable across accounts and across quarters.
Every figure next to last quarter and the same period last year, with the change and direction. A number alone gets no reaction.
Anything past a threshold you set is highlighted, so each section opens with what changed rather than a full table.
Marked as carried over, so the author edits rather than starting blank. Most sections change by a sentence.
Automatically, with their current status. Nothing else in the tool changes behaviour as much.
The exported version is kept alongside the record, because the underlying numbers will change and the question later is what you actually showed them.
A QBR prep tool is not a deck generator. It is four parts, and the fourth is the one that makes the second review better than the first.
The sections every review covers, in order, with the metrics each section needs. Fixed, so reviews are comparable across accounts and quarters, and editable in one place when the format changes.
Each metric pulled automatically, with the same period last quarter and the same period last year beside it, plus a flag on anything that moved beyond a threshold.
The narrative, the interpretation, the risks and the asks. Written by a person, saved against the review, and reusable as a starting point next quarter.
What each side agreed to, by when, and its status. Loaded automatically into the top of the next review, which is where accountability in these meetings actually comes from.
These prompts start from a Helix project, which is what handles sign-in, credentials and hosting. Start with Helix
Paste these into Claude Code, Codex or Cursor in order. Each one leaves you with something that runs, so you can stop after any step.
One shape, so reviews are comparable and the format changes in one place.
In this Helix project, build me a QBR prep tool.
Start with the template, and keep it in one config file. An ordered list of
sections, each with a title, a purpose line, and the metric keys it needs.
Seed it with: executive summary, adoption and usage, value delivered,
support experience, commercial position, risks, and next quarter's plan.
Creating a review instantiates that template for one account and one
period. Keeping it in config means changing the QBR format changes every
future review without anyone touching an account.
Then the account data it hangs off: name, segment, contract value,
contract dates, renewal date, the success owner, the account executive,
and the key contacts with their roles.
I sign in through Helix, so do not build a login page. Read the signed-in
user from the runtime. And do not put any key or connection string in the
code: if this needs to reach another system, tell me and I will create the
connection in my workspace.The four hours you are actually removing.
Now assemble the metrics.
For every metric in a review, show the current period, the previous
period, the same period last year, the absolute and percentage change, and
the direction. Never a bare number. A usage figure with nothing beside it
is a slide that gets nodded at.
Flag anything that moved more than a threshold I set per metric, and open
each section with what changed rather than with a full table. A review
that covers twenty metrics equally covers none of them.
Import from CSV per source to start, with the mapping in one editable
file, structured so I can swap in a live connection later.
One thing to get right: handle missing data honestly. A metric with no
value says so. Do not render it as zero. A zero on a customer-facing slide
starts an argument you cannot win.Worth knowing. Rendering missing data as zero is the most common and most damaging bug in this kind of tool. Make absent and zero visibly different.
Editing a draft instead of writing from nothing.
Each section gets the generated data plus a place to write the narrative.
Pre-fill each narrative with last quarter's text for that account, marked
clearly as carried over, so the author is editing rather than facing a
blank box. Most sections change by a sentence.
Add a risks section where each risk has an owner, a severity and a
mitigation, and carries forward until it is closed. And an asks section:
what we want from the customer this quarter, and what they have asked of
us.
Give the review a state: draft, internal review, ready, delivered. Let a
manager comment on a draft without editing it.
Export the finished review as a document, and keep that export next to the
record. The underlying numbers get corrected and backfilled, and six
months later the question is what we actually presented, which sometimes
has legal weight.Commitments, and the single feature that changes these reviews.
Last, and most important: track commitments.
Capture what each side agreed to, with a named owner on our side or
theirs, a due date, a status and an outcome. Capture them during or
straight after the review.
Then have the next review for that account open with an automatic section
listing every commitment from last time and where it stands. Nothing else
in this tool changes behaviour as much as that one screen.
Remind owners of overdue commitments before the next scheduled review, so
the status is real rather than updated in the meeting. And report
completion rate by owner across accounts, plus the accounts carrying the
most overdue items, which tends to correlate with the accounts in
trouble.The step that turns a working prototype into something with your data in it.
Now connect it to the systems we actually run, so it works on real data
rather than the rows you seeded.
Anything in angle brackets is a placeholder. Swap it for whatever we use
instead, and have the app name the connection it wants rather than assume
a vendor, so changing my mind later is a config change and not a rewrite.
<Amplitude>. Pull the adoption metrics the review covers, with the
previous period beside them.
<Salesforce>. Read contract value, renewal date, contacts and open
opportunities for the account.
<Zendesk>. Pull the ticket count and any escalation for the period, which
is the section customers always ask about.
<Google Drive>. Keep the exported review, so what you presented survives
the numbers being corrected later.
<Okta>. Confirm the reader is a member of staff, because the draft carries
risks and internal narrative that never go in front of the customer.
<Google Slides>. Push the assembled review into the deck template the team
already presents from.
<Snowflake>. Read the metric history so every figure has last quarter
beside it.
Only write where I have said to write. Everything else is read only.
Do not write a key, a token or a connection string anywhere in the code,
and do not ask me to paste one. Tell me which connections you need and I
will create each as an authentication in my Helix workspace. Reference
them by alias.Worth knowing. Every name in angle brackets is a placeholder for whatever you run. Helix holds the credential as a workspace authentication, so the app references an alias and never the secret itself.
The last step of every build: a URL, and the right people on it.
Deploy my app.Worth knowing. Your assistant runs helix deploy underneath and the app comes back as a URL. Internal narrative and risks sit in the same record as customer-facing content, so set Access Control before sharing to keep the internal half internal.
The four hours you are removing are four hours of copying numbers out of these systems.
Amplitude
Pull the adoption metrics the review covers, with the previous period beside them.
Salesforce
Read contract value, renewal date, contacts and open opportunities for the account.
Zendesk
Pull the ticket count and any escalation for the period, which is the section customers always ask about.
Google Drive
Keep the exported review, so what you presented survives the numbers being corrected later.
Okta
Confirm the reader is a member of staff, because the draft carries risks and internal narrative that never go in front of the customer.
Google Slides
Push the assembled review into the deck template the team already presents from.
Snowflake
Read the metric history so every figure has last quarter beside it.
Each line says whether the app reads, writes or both. Anything not described as writing should be read only.
Named systems are the ones most teams actually run, not a list of the only ones that work. Swap in whatever you use.
Each connection is an authentication in your Helix workspace, referenced by alias. The app names the connection it wants and never holds the credential, so nothing here ends up in your code and any of it can be rotated or revoked without a redeploy.
The build gets you a working prep tool. It reads usage, support and commercial data and produces documents shown to customers, so it needs to be run properly.
AI Deployment
One command takes the app from your assistant to a live address, so the people who need it get a link rather than instructions for running it locally.
App Security
Contract values, risks and internal narrative sit in the same record as customer-facing content. SSO plus scoped access is what keeps the internal half internal.
App Security
Pulling usage, support and billing metrics needs real access to those systems. Granting it to the app rather than pasting keys into it means credentials can be rotated or revoked without a redeploy.
App Registry
Every app carries a named owner and an entry IT can see, so the tool does not become nobody's problem when the person who built it changes role.
Cost Management
Per-app spend visibility, with budgets and caps, so an internal tool cannot quietly become a line item nobody can explain.
It assembles the usage, support, commercial and relationship data for an account into a fixed review template, so preparing a quarterly business review is editing a draft rather than gathering numbers.
No. It should gather the data, compare it against previous periods, and flag what moved. The interpretation, the risks and the asks are the part that makes a review worth holding, and they need a person who knows the account.
Carrying commitments forward. Opening each review with what both sides agreed last quarter and its current status is the single feature that turns a presentation into accountability.
Always with a comparison: the previous period and the same period last year, with the change and direction. A number on its own produces no reaction. And missing data must render as missing, never as zero.
Because the underlying numbers change as systems are corrected and backfilled, and six months later the question is what you actually presented, not what the data says now. That question sometimes has legal weight.
Yes. The prompts here are written for Claude Code, Codex or Cursor and stage the build from CSV imports. The judgement call is your template, and keeping it in a config file means you can change it later without redoing the app.
Customer Success
Build a health score from signals that actually predict renewal, show the trend rather than the number, and turn a red account into a named action. Prompts to build it, and what it takes to run it.
Customer Success
Work renewals from the notice date backwards, with a stage for each step, an owner, and a forecast leadership can trust. Prompts to build it, and what it takes to run it.
Customer Success
Give escalations a severity, an owner, a communication cadence and a closure record, so the customer hears from you on schedule rather than when someone remembers. Prompts to build it, and what it takes to run it.
Last reviewed September 2026.
Helix is the governed runtime for AI-built apps. Deploy what you build, put SSO in front of it, connect it to your systems with managed credentials, and give it a named owner.
Your private status link is on its way to your inbox.