A QBR should leave the client with a decision

Bring a decision, not every data point

Start with what changed since the last review: open risks, recurring support pain, lifecycle pressure, licensing changes, commitments that slipped, and work that needs client approval. The meeting should make the tradeoffs visible enough for the client to choose a next step.

That does not mean hiding difficult context. It means separating evidence from interpretation. State what the team observed, why it matters, what it could cost or delay, and who can decide whether to fund, defer, or accept the risk.

Keep the roadmap alive between meetings

1. Prepare the baseline. Confirm the client facts, recent changes, open commitments, and decision owner before the meeting begins.
2. Rank the next decisions. Put budget, timing, risk, and operational impact beside each recommendation so the client can see the tradeoff.
3. Record the outcome. Capture the approval, deferral, accepted risk, or follow-up date with the person who owns it.
4. Hand off real work. A decision that becomes a project or remediation item needs scope and a delivery boundary, not a vague note in the next deck.

Choose the page that matches the work

This guide explains how an MSP can run the client-decision motion. The product page describes the current Scopable workflow. Setup documentation is for a released or explicitly available feature after the workflow decision is made. Keeping those jobs separate prevents a guide from becoming a thin archive or an unsupported product claim.