The calendar invite said quarterly business review. What showed up was a 30-minute screen share of ticket counts and closed projects.
The provider confirmed everything was running well and asked if there were any questions. The GM of a mid-size cooperative in western Iowa closed his laptop with a vague sense that three hours of combined leadership time had just gone nowhere.
That is not a quarterly business review. That is a ticket summary dressed up as a strategy meeting. And there is a meaningful difference between the two.
A quarterly business review, or QBR, is a structured meeting between a managed IT provider and a client that covers the last 90 days of service, the current state of the technology environment, and the forward-looking strategy for the next quarter and beyond.
Done well, it is one of the most valuable conversations a business leader can have about their operation. It surfaces risks before they become incidents. It connects technology decisions to business goals. It creates accountability on both sides of the relationship.
Done poorly, it is a reporting exercise that produces no decisions, surfaces no risks, and leaves the client no better informed than they were before they walked in.
The difference between the two is not the slide deck. It is what the provider is willing to say.
A QBR that earns the time it takes should move through several distinct conversations, each one building toward a clearer picture of where the business stands and what comes next.
The executive summary and business goals. A good QBR does not start with ticket counts. It starts with the business. What happened in the last 90 days that affects your technology environment? Did you add a location, lose a key IT staff member, take on a new customer with compliance requirements, or make a leadership change that shifts your technology priorities? Your IT provider should be asking these questions because the answers change what your technology needs to do.
At Koltiv, the business goals conversation is on the agenda before anything else. Before ticket review, before asset overview, before any discussion of what the technology has been doing, we want to know what the business has been doing. That context shapes everything that follows.
The environmental and service review. This is where the last 90 days get examined honestly. Not just what tickets were closed, but what the pattern of those tickets tells you. Are the same issues recurring? Are there devices generating a disproportionate number of incidents? Is a system approaching the point where it is creating more support burden than it is worth maintaining?
A good environmental review also covers assets: what hardware is in service, what is approaching end of life, what is running software that is no longer receiving security updates. It covers Microsoft licensing, open projects, closed projects, and invoicing. The goal is a clear picture of the current state of the environment, not a summary of activity.
What your provider delivered. This section should be specific and evidence-based. Not "we kept your systems running." Something closer to: the number of issues identified and resolved before they reached your team, the projects completed and what they accomplished, the security incidents detected and mitigated, the hours your staff did not have to spend troubleshooting because something was handled proactively.
This is the accountability section of the QBR. A provider who cannot populate it with specifics is a provider who has not been paying close enough attention to your environment.
Potential risks. This is the section most IT providers skip or soften, and it is the one that matters most to a business leader. Your provider should be telling you, plainly, what in your current environment represents a risk to your operation. Hardware that is aging toward failure. Software running versions with known vulnerabilities. Devices that are not being monitored. Security controls that have gaps.
A QBR that does not surface risks is not protecting you. It is telling you what you want to hear.
Opportunities to explore. This is the forward-looking section, and it should cover more than product recommendations. What is changing in your industry that affects your technology decisions? What new tools or approaches are relevant to your operation? What is Microsoft, your primary software vendors, or the broader technology market doing that you should know about before it affects your budget or your workflow?
In a recent Koltiv QBR, this section covered Microsoft 365 pricing increases coming in July of 2026, the significant cost changes in VMware and Broadcom licensing affecting companies running those environments, expanded AI Copilot features that may affect how teams work, and emerging precision ag technology relevant to cooperative clients. None of that is a sales pitch. It is information a business leader needs to plan.
Budget and planning. The QBR should surface what is coming financially before it arrives as a surprise. Upcoming renewals. Hardware approaching replacement timelines. Projects that are likely to be needed in the next one to two years. This gives the business time to plan capital requests, budget conversations, and board approvals correctly, rather than reactively.
Satisfaction and feedback. A QBR should close with the client's voice. Not a survey link sent three days later, but a direct conversation about what has been working, what has not, and what the provider should do differently. The feedback is how the relationship improves. A provider who does not create space for it is not confident enough in what they are delivering to invite scrutiny.
If you want to evaluate whether your current IT provider is conducting real QBRs or going through the motions, there is one question that surfaces the answer quickly.
Ask them: based on what you know about our environment and our business right now, what are you most concerned about?
A provider who knows your environment will have a specific answer. They will name the aging server in your backup infrastructure that has been trending toward failure. They will mention the Windows XP workstation still running on your production floor that represents both a security vulnerability and a compliance risk. They will bring up the cybersecurity team departure that they know happened and ask how you are thinking about backfilling that expertise.
A provider who does not know your environment will say something general. Everything looks good. We are keeping an eye on a few things. No major concerns at this time.
General answers to specific questions are a signal. They mean the provider is managing your account at arm's length rather than with the depth of familiarity your operation deserves.
A QBR is not a one-way accountability exercise. It creates obligations on both sides of the relationship.
The provider is accountable for knowing your environment, surfacing risks proactively, delivering on what was committed in the previous quarter, and bringing a forward-looking perspective that helps the business make better decisions.
The client is accountable for sharing what is happening in the business, flagging concerns as they arise rather than accumulating them for the quarterly meeting, and engaging with the risks and opportunities the provider surfaces rather than deferring every decision.
The QBR is where that mutual accountability gets measured. When both sides take it seriously, the relationship compounds in value over time. When one side goes through the motions, the other eventually notices.
If the description of a real QBR in this post sounds different from what you have been experiencing, the first step is naming that gap directly with your provider. Share what you need from the conversation, ask for the sections that have been missing, and give the relationship a chance to adjust.
If the conversation does not shift, that is useful information too.
A managed IT relationship that is not creating accountability, surfacing risks, and contributing to your forward planning is a relationship that is costing you more than the monthly invoice. It is costing you the visibility and confidence you should have about one of the most critical functions in your operation.
That is a conversation worth having before something goes wrong rather than after.