Quarterly Business Reviews with Your MSP

This article is educational content for understanding quarterly business reviews with MSPs. It is not guidance on metrics, not a QBR template, and not a substitute for clearly documented review procedures in your MSP contract.

You're in quarterly business review number 12 with your MSP. The account manager shows you a dashboard with charts and metrics. Uptime is 99.8 percent. Response time averages two hours. Patch deployment is 87 percent within service level agreement. The metrics look good, but you have a nagging feeling that something's not right. The MSP seems to be treating the review as a checkbox exercise—showing you numbers and moving on.

But you have questions: why haven't you made progress on the server modernization project? What happened to the cloud migration roadmap we discussed? Why are you paying for licenses you don't use? The dashboard is answering "are things working?" but not answering "is this partnership aligned with where we're trying to go?"

A quarterly business review should be more than a metrics presentation. It should be a structured conversation between you and your MSP about whether the partnership is delivering value, whether you're on track with your strategic goals, and whether anything needs to change. Done well, a QBR keeps the partnership aligned and identifies problems before they become relationship issues.

QBR Structure and Timing

A quarterly business review should happen roughly every three months—quarterly enough to track progress but not so frequently that nothing has changed to discuss. The timing should be consistent so both parties expect it and prepare. A typical QBR lasts 60 to 90 minutes and includes representatives from your organization (IT and business leadership) and the MSP (account manager and relevant technical leads).

The structure should have a clear agenda that flows logically. A typical agenda includes opening remarks to recap previous QBR findings and actions from last quarter, performance metrics (uptime, response time, SLA achievement), issues and problem resolution (what issues occurred and were they handled well?), completed work (what projects or improvements happened this quarter?), upcoming work (what's planned for next quarter?), strategic discussion (are we on track with long-term goals? What's working, what isn't?), and action items (what needs to happen before the next QBR?).

The QBR should be documented. Someone should take notes of what was discussed, what metrics were reviewed, what issues were identified, and what action items came out. These notes become the record of your partnership over time and help you track whether the MSP follows through on commitments.

Performance Metrics and SLA Achievement

Most MSPs will present performance metrics—uptime for critical systems, average response time to issues, percentage of changes deployed on time, patch deployment timeliness. These are useful data points, but they need context.

Uptime metrics should be broken down by system because uptime for your critical systems is more important than uptime for less critical systems. 99.8 percent average uptime might be acceptable if it's across all systems, but if your primary email server was down for six hours last month, that's a problem even if it brings the average up to 99.8 percent. Metrics should distinguish between critical systems and everything else.

Response time metrics should align with your SLA commitments. If your SLA says critical issues get 15-minute response, the QBR should show what your actual response times were. If you were consistently hitting 30 minutes on critical issues, that's a performance gap that needs to be addressed. SLA achievement is the percentage of issues resolved within the committed time frame. If the SLA says high-priority issues should be resolved within eight hours, and 87 percent of high-priority issues met that goal, what happened with the other 13 percent? Were they legitimate exceptions, or are there patterns of issues taking longer than committed?

The key insight is that metrics should prompt discussion, not just be presented. If uptime was 99.8 percent but there was a two-hour outage that significantly impacted business, that's worth discussing. If SLA achievement dropped from 95 percent to 87 percent, why? What changed? What will improve it? Metrics without discussion don't add value and often mask real issues behind impressive-looking numbers.

Issues and Problem Resolution Review

Beyond performance metrics, the QBR should review significant issues that occurred during the quarter. What problems affected your business? How quickly were they resolved? Could they have been handled better?

This isn't about blaming the MSP for problems—problems happen in every environment. It's about understanding patterns. If you had three network outages in the last quarter and two were from the same root cause, the MSP should have identified the pattern after the first two and fixed it before the third. If issues keep recurring, that's a pattern that needs to be addressed.

The MSP should present what was learned from issues. What changes will prevent similar issues in the future? Have they implemented those changes? Incident review that results in improvements is valuable. Incident review that results in no changes means you'll keep experiencing the same problems. This is also the time to discuss whether incident response met your expectations. Were you notified quickly when issues occurred? Did the response feel adequate? Did the communication during the incident keep you informed? Was the post-incident review thorough? These are relationship and process questions that are just as important as the technical response to the problem itself.

Completed Work and Project Status

The MSP should report on what work was completed in the past quarter. This includes maintenance work (patches applied, updates deployed, systems optimized), project work (migrations, system upgrades, infrastructure improvements), and improvements (security enhancements, performance optimizations). This demonstrates that the MSP is moving your infrastructure forward, not just keeping the lights on.

For project work, the report should include what was planned, whether it was completed on time and on budget, what the outcome was, and what's next. If a server modernization project was planned for Q2 but is still in progress in Q3, the QBR should discuss why—were there delays, scope changes, unexpected issues? Understanding the reason helps you plan better in the future.

The conversation should also address whether work is happening at the pace you expected. If the MSP said they'd handle three major projects per year and you're at the end of Q3 with only one completed, that's a pace issue worth discussing. Are they understaffed? Is your environment more complex than expected? Are there competing priorities that are slowing project work? These conversations help both parties understand whether the engagement is working at the expected velocity.

Upcoming Work and Roadmap Discussion

Looking forward, what's planned for the next quarter and beyond? The MSP should present their view of what work needs to happen. This might include maintenance work, planned projects, infrastructure updates, or compliance work. You should discuss whether that roadmap aligns with your business priorities.

This is also the time to discuss strategic initiatives. Do you have plans to migrate to cloud? Implement new systems? Consolidate data centers? Expand to new locations? Your MSP needs to understand your strategic direction and help you plan the IT investments necessary to support that direction. The MSP's roadmap should account for your strategic plans, not just operational necessities.

The roadmap discussion should also include rough estimates of cost and timeline. If you're planning a cloud migration, how long will it take and what will it cost? If you're adding locations, what IT investment is required? Rough estimates help you plan and budget appropriately.

Cost Review and Budget Alignment

Most organizations are concerned about IT costs. Are you spending what you budgeted? Are there unexpected costs? Are you paying for things you're not using? The QBR should include a cost review.

This includes review of managed services costs (are you paying what was contracted for?), project costs (if projects are being charged separately, are they on budget?), and licensing costs (are you licensed for what you're using?). It's not uncommon to find that organizations are paying for licenses they're not using or paying for services they don't need.

The cost review should also address cost drivers. What's consuming the most budget? Is that appropriate? If security tools are consuming a lot of cost, is that justified by the security value they're providing? If most of the budget goes to a legacy system that could be replaced with something modern, should you plan a replacement? This is the time to discuss opportunities to reduce costs or optimize spending. Maybe consolidation could reduce licensing costs. Maybe moving to cloud would reduce infrastructure costs. Maybe automating certain tasks would reduce labor costs. The MSP should be helping you spend IT money efficiently, not just maximizing their own revenue.

Staff and Relationship Assessment

The QBR should also address the people side of the relationship. Is the account manager you're working with effective? Are the technical staff you interact with knowledgeable and responsive? Is the MSP providing the people you need to support your infrastructure? These are relationship questions that affect whether the partnership works well.

If your account manager isn't responsive or doesn't seem to understand your business, that's a relationship problem worth addressing. If the technical staff have high turnover and you keep dealing with new people, that affects relationship continuity and your confidence in the MSP. If you requested a specific expertise to support a project and the MSP brought in someone who didn't have the necessary skills, that's a resource quality issue.

The conversation should also address whether MSP staff understand your business. Do they know what you do, who your customers are, what your peak times are, what your critical systems are? An MSP that treats you as "customer number 47" won't align their work with your business priorities as well as an MSP that genuinely understands your business. If there are staff changes, you should discuss them. If your primary contact is leaving the MSP, who will replace them? If the technical team is changing, how will that be managed? Continuity in people reduces risk that institutional knowledge is lost.

Strategy and Long-Term Planning

Beyond the current quarter, the QBR should address long-term strategy. Where is your organization heading in the next one to three years? What IT infrastructure will you need? What should the MSP be planning for?

This is the conversation about roadmap, not just the next quarter but the next one to three years. What systems should be modernized? What cloud migration should happen? What new capabilities do you need? When? The MSP should be helping you think ahead and plan investments that support your long-term direction.

This also includes discussing whether the current MSP relationship is sustainable long-term. As your organization grows or changes, will the MSP be able to support you? Do they have expertise in areas you'll need? Are they growing at the same pace as your organization? These are strategy questions that help you plan whether you'll stay with the current MSP or need to explore other options.

Action Items and Accountability

The QBR should produce action items—things that need to happen before the next QBR. These might be commitments from the MSP (complete a project, remediate an issue, provide documentation), commitments from you (provide information, make a decision, approve a change), or joint commitments.

Each action item should have a clear owner (who's responsible for doing it), due date (when should it be done), and success criteria (how will we know it's done?). Action items without these details are vague commitments that probably won't happen.

At the next QBR, you should review action items from the previous quarter. Were they completed? If not, why not? This creates accountability and helps you assess whether the MSP is following through on commitments. It also helps you follow through on your own commitments.

Preparing for QBRs

QBRs are only valuable if both parties prepare. You should go in with questions: Are we on track with your strategic plan? What issues would you like to discuss? What areas of IT are you concerned about? What would success look like for the next quarter? The MSP should prepare with data: performance metrics, completed work summary, roadmap for upcoming work, and their assessment of any relationship or capability gaps.

If you skip preparation and treat the QBR as just a check-the-box meeting, it becomes a waste of time. If you engage thoughtfully, it becomes a strategic conversation that improves the partnership and ensures both parties are aligned on what matters.

Closing Reflection

Quarterly business reviews done well keep your MSP partnership aligned with your business priorities and help you assess whether you're getting value from the engagement. Metrics are useful, but the conversation is more important. Are you making progress toward your goals? Is the MSP understanding your business? Are you satisfied with the service? Is anything changing that affects the partnership? These are the questions a good QBR answers. If your current QBRs feel like checkbox exercises, suggest making them more strategic. If your MSP isn't used to deep business discussions, that might be something to address when the contract comes up for renewal.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general guidance about MSP quarterly reviews. Individual MSP relationships vary—evaluate any review approach based on your organization's specific needs and goals.