Most vCIO meetings start with a review of what technology did over the last 90 days, then work toward what the business needs. The order is backwards, and it matters more than most people realize.
When the meeting starts with technology, the client is being asked to react to the MSP's world. Here are your tickets, here's your uptime, here's what we patched. The client's job becomes nodding along and occasionally asking a question. When the meeting starts with the business: what changed for you this quarter, where are you trying to go, what's getting in the way. The client is being invited into a real conversation.
The difference in client engagement between those two approaches is significant. Not because one agenda looks better on paper, but because the client can feel whether the vCIO showed up to report on their technology or to think about their business with them.
The technology still needs to get covered. It just lands differently when the client already knows the vCIO understands why it matters to them.
Why vCIOs Default to Technology First
Part of what makes this hard is that vCIOs tend to assume they already know what clients want. Lower costs, less downtime, fewer security headaches. Those things are real and they come up in almost every conversation. But they're not the whole picture, and sometimes they're not even the most important part.
Most clients have been sitting through technology reviews for years, listening to reports they don't fully understand about systems they don't think about much, and gradually deciding that IT is something to delegate rather than something to be involved in. They don't tune out because they aren't interested in their technology. They tune out because nobody is connecting it to the things they actually care about.
When a vCIO walks in and asks a business leader about where their company is headed, what they're trying to build for their people, or what's been getting in the way of things that matter, that's a conversation they don't often get to have with their technology partner. And people love to talk about their businesses.
What Changes When This Works
When this shift happens, it's noticeable. The executive who used to send someone else to the technology strategy meeting starts showing up themselves. The questions change from "do we need to worry about this?" to "how does this connect to what we're trying to do?" The vCIO starts getting calls that aren't about a problem, just someone thinking through a decision and wanting their perspective.
That's the real measure of whether the vCIO relationship is working. Not the technology outcomes, though those matter too, but whether the client sees the vCIO as someone worth talking to when something important is on their mind.
It's also worth remembering that vCIOs don't always know what's actually on someone's mind when they walk into that meeting. The client might be thinking about any of these:
Watching everyone around them seemingly embrace AI while they haven't got a clue where to start
Losing sleep over a security incident that hasn't happened yet but feels inevitable
Tight cash and a payroll concern that's real right now
A major client who just told them SOC 2 is now a requirement to keep the contract
All of those things would shape the roadmap significantly if the MSP only knew about them.
A Real Example
Consider a client still running on-premises infrastructure a couple of years after the pandemic reshuffled how their team worked. The client wasn't frustrated about IT tickets or server performance. What they wanted was a great work experience for their people: nobody tethered to a particular desk or location, employees able to move around the office, work from home, or travel, and have everything just work the same way regardless.
"Seamless" was the word they kept using, and the reason behind it was as much about culture and flexibility as it was about convenience.
That conversation changed the shape of the technology plan entirely. The result:
Enrolling computers in Entra
Standardizing on laptops
Moving fully into Teams
Putting a legacy application into Azure Virtual Desktop rather than leaving it on a local server
The plan wasn't optimizing for the lowest price or the most technically elegant solution. It was optimizing for the experience the client had described. Once the vCIO understood that, the decisions became easier to explain and easier for the client to approve.
The Skill That's Hardest to Teach
It's not the technology knowledge. Most people who end up in the vCIO role have plenty of that. It's the habit of starting with the client's world before moving to the technology, and staying curious about that world even when it would be faster to just go straight to the solution.
Business goals aren't always financial or operational. Sometimes they're about how a client wants their employees to feel about coming to work. Sometimes they're about what the owner is trying to build over the next five years and whether the technology they have today can support it. Sometimes the client doesn't fully know themselves until someone sits with them and asks the right questions.
That's the conversation worth having before building the plan.
Questions to ask when you start the vCIO process, and revisit regularly:
What does success look like for your business, not just your IT?
What would change if technology stopped being something your people had to think about?
What are you trying to accomplish this year that we should be supporting?
The answers to those questions are what the roadmap should be built around. The technology is almost never the hard part. Understanding what the client is actually trying to do with it usually is.
How to Build This Into Strategy Overview
There are two ways to make goal-focused conversations a consistent part of your workflow.
Option 1: Use the Goals Plan from the Marketplace (Recommended)
The most structured approach is to download the Goals Plan from the Strategy Overview Marketplace and add it to each client's default Report. This gives a dedicated place to capture and track business goals over time, separate from technology initiatives.
How to set it up:
Go to the Strategy Overview Marketplace
Download the Goals Plan template
Add the Plan to each client account and their default Report
During discovery or TSM conversations, capture the client's business goals in this Plan
Reference these goals when building technology recommendations and reviewing progress
The advantage here is that goals become a first-class object in the client's record. They can be tracked, updated, and tied directly to technology initiatives. When preparing for a TSM, you're not starting from scratch. You're reviewing what the client said mattered and checking whether the technology work is supporting it.
Option 2: Add a Goals Section to the Executive Summary
For a quicker start without adding a separate Plan, add a goals section near the top of the executive summary template (before the technology review) that captures:
The client's primary business objectives for the year
Any recent changes to their priorities or situation
How current technology initiatives connect to those objectives
This works well when you're just starting to shift your meeting structure toward goals-first conversations. The tradeoff is that goals captured in executive summaries are harder to reference over time than goals in a dedicated Plan. But it's a reasonable starting point, and you can add the full Goals Plan once the habit is built.
Where to Start
Pick one client and try leading with business goals in the next meeting. Don't present technology first. Ask what's changed for them, what they're working toward, what's getting in their way. See how the conversation shifts.
Then capture what comes up in Strategy Overview, either in a Goals Plan or in the executive summary. The goal is to make that information easy to reference next time, so each conversation builds on what was learned rather than starting over.
The technology still gets covered. It just lands differently.
