First Pass: A Collection of Insights on the world of AI and MSPs

AI for MSP QBR Preparation: Stop the Pre-Call Scramble

Fri, 07 Aug 2026 04:00:04 GMT

Quarterly business reviews should be a strategic conversation. In practice, they often become a frantic data-gathering exercise the day before the meeting. Someone pulls SLA reports, someone else checks open tickets, a vCIO digs through proposals, and the account manager tries to remember what was promised six months ago. By the time you sit down with the client, you have a stack of numbers but no coherent story.

The same problem appears in a more compressed and painful form during unexpected escalation calls. A client calls upset, your team scrambles to reconstruct context, and you end up reactive instead of composed. Neither situation reflects the trusted advisor relationship MSPs are trying to build.

AI for MSP QBR preparation changes this by treating client intelligence as something that should already exist, not something you assemble under pressure. When your data is unified and your AI workflows are repeatable, you can generate a complete client summary in minutes, whether the meeting is scheduled three weeks out or happening in three hours.

Why QBR Preparation Breaks Down Without AI

The core problem is not that MSPs lack data. Most have an abundance of it scattered across their PSA, RMM, CRM, project management tools, and proposal software. The problem is that pulling it together requires manual effort, and manual effort takes time that account managers and vCIOs rarely have in surplus.

When preparation is manual, a few predictable things happen. Teams default to the metrics that are easiest to pull rather than the ones most meaningful to the client. Historical context gets lost because no one has time to read through six months of ticket notes. Relationship risk signals, like a client who has submitted more escalations recently or has an open proposal sitting untouched for 60 days, go unnoticed until they become problems.

There is also an inconsistency issue. When every QBR depends on who prepared it, quality varies. A detail-oriented vCIO builds a thorough deck. A stretched account manager puts together something serviceable but thin. AI for MSP QBR preparation gives you a repeatable floor that every client conversation starts from, regardless of who is running it.

What Unified Data Makes Possible

The foundation for AI-assisted QBR preparation is unified client data. This means your PSA, RMM, CRM, and project tools are either integrated into a central platform or connected in a way that lets AI query across all of them simultaneously.

When that foundation exists, a well-prompted AI model can generate a structured client brief that includes:

SLA performance trends over the review period, flagged against contracted thresholds
Open and aging tickets , categorized by type and priority, with notes on any recurring patterns
Project status summaries , including milestones hit, current blockers, and upcoming deliverables
Open proposals , with time-in-stage and any engagement signals from the client
Relationship risk indicators , such as recent escalations, changes in response patterns, or contract renewal timelines

This is not a report you build manually. It is a summary generated in response to a prompt like: "Prepare a QBR brief for Acme Corp covering the last 90 days." The output gives you a starting point that would have taken an hour to assemble on your own, produced in minutes.

From there, the human work is interpretation and strategy, which is where account managers and vCIOs should be spending their time anyway.

Handling Escalation Calls with the Same Approach

Scheduled QBRs give you runway. Escalation calls do not. When a client calls frustrated at 2pm on a Tuesday, the ability to pull a coherent account summary instantly is not a convenience, it is a competitive differentiator.

The same AI workflow that supports QBR preparation works for escalation response. Before you pick up the phone or join a bridge call, you prompt your system: "Summarize recent activity for Acme Corp, including open tickets, any SLA misses in the last 30 days, and notes from the last three client interactions."

What you get back is the context you need to walk into that conversation without fumbling. You know what happened, when it happened, and what was already said. You can acknowledge the situation accurately and focus the call on resolution rather than reconstruction.

Clients read the fumble. When you ask basic questions about your own service history, it signals that you are not on top of the account. When you arrive with context, even in an unscheduled call, it signals the opposite. AI for MSP QBR preparation and escalation response is ultimately about showing up prepared every time, not just when you had time to get ready.

Building a Repeatable AI Workflow for Client Conversations

The goal is not to use AI for one good QBR and then revert to manual prep next quarter. The goal is a repeatable practice where AI-assisted preparation is the standard operating procedure for every significant client conversation.

This requires three things working together.

First, prompt standardization. Your team should not be inventing new prompts every time. Develop a library of tested prompts for different scenarios: standard QBR preparation, escalation response, renewal planning, executive briefing. These become part of your playbook, not individual improvisation.

Second, data hygiene. AI surfaces what exists in your systems. If ticket notes are sparse, project updates are missing, or proposal stages are not updated consistently, the summaries will reflect that. QBR preparation is a strong forcing function for better data discipline across the team.

Third, a human review step. AI-generated summaries are a starting point, not a finished product. The account manager or vCIO should review the output, add strategic context that does not live in any system, and shape the narrative before the meeting. The AI handles the data gathering; you handle the judgment.

When these three elements are in place, the process scales. More clients, more accounts, more vCIOs, without a proportional increase in preparation time.

From Ad Hoc to Operational: The MAGIC Principle

Using AI for a single QBR is a tactic. Building a practice where AI-assisted client preparation is embedded in your service delivery workflow is an operational capability. There is a meaningful difference.

The MAGIC Framework , Lemhi's approach to AI Transformation for MSPs, is built around this distinction. MAGIC stands for Multi-step, Adaptive, Grounded, Integrated, and Consistent. Applied to QBR preparation, it means your AI workflow does not just generate a summary. It generates the right summary, grounded in your actual client data, integrated with the tools your team already uses, and consistent enough that anyone on the team can run it reliably.

MSPs that treat AI as a one-off productivity trick will see isolated improvements. MSPs that build repeatable AI practices across service delivery, client success, and operations will see compounding returns. QBR preparation is one of the clearest places to start because the value is immediate and measurable: less prep time, better conversations, stronger client relationships.

Conclusion

QBR preparation has been a time tax on MSP account teams for as long as the QBR format has existed. The data required for a good client conversation has always been there. The problem has been the effort required to assemble it. AI changes that equation directly.

When you combine unified client data with standardized AI prompts and a consistent review process, you stop scrambling before every client conversation. You show up prepared whether the meeting was on the calendar for a month or scheduled an hour ago. That consistency is what builds the trusted advisor reputation MSPs are working toward.

Data Quality Is Your Competitive Edge. Use It Before Every MSP Catches On

Wed, 05 Aug 2026 04:00:00 GMT

Most MSPs are sitting on years of operational data and doing very little with it. Ticketing histories, time entries, asset records, client configurations, contract data, all of it lives somewhere, usually scattered across a PSA, an RMM, a spreadsheet or two, and someone's memory. That scattered state is not just an operational inconvenience. It is quietly becoming a liability as AI adoption accelerates across the industry.

Here is what makes this moment unusual: data quality is still a differentiator. Most MSPs have not yet done the work to clean, centralize, and govern their data. The MSPs that do it now will build a structural advantage that compounds over time. The ones that wait will find themselves trying to catch up once the window has closed and clean data is simply what clients and tools expect.

This is not a distant concern. The gap between MSPs with governed data and those without is already visible in how effectively they can deploy AI tools, automate workflows, and make decisions with confidence. The question is not whether to act. It is how to act before the market catches up.

Why Data Quality Matters More Than the AI Tool You Choose

There is a tendency in the MSP space to focus on which AI tool to buy rather than whether your business is ready to use it effectively. That framing gets things backwards. AI tools amplify what is already in your data. If your data is messy, duplicated, or siloed, the outputs will be unreliable at best and actively misleading at worst.

Consider a specific scenario. You want to use AI to predict which clients are at risk of churn based on ticket volume, sentiment patterns, and contract utilization. That sounds straightforward until you realize your ticket categories have been applied inconsistently for three years, your contract data does not match what the billing team actually charges, and nobody has audited client records since the PSA migration. The AI cannot fix any of that. It will surface noise with a confidence score attached.

The MSPs pulling ahead are not necessarily using more sophisticated AI. They are using the same tools more effectively because their underlying data is clean enough to trust. That is the competitive advantage available right now, and it is rooted in discipline rather than technology spend.

The Compounding Effect of Centralized, Well-Governed Data

One of the reasons data quality creates a durable competitive moat is that it compounds. Every month you operate with governed data, you accumulate better signal. Your AI models get more accurate. Your automation catches more edge cases. Your reporting becomes more reliable. The longer you maintain that discipline, the wider the gap grows between you and MSPs starting from scratch.

Centralized data is the foundation of this compounding effect. When your PSA, RMM, documentation platform, and financial systems are connected and normalized, you stop losing context every time information crosses a boundary. A client issue that starts as a ticket can be traced to an asset, linked to a contract, and correlated with billing, all without a manual lookup. That kind of connected visibility is not magic. It is the result of deliberate data architecture decisions made months or years earlier.

Governance is what sustains it. Without clear ownership, naming conventions, and data entry standards, even a well-integrated stack will drift back toward chaos. Governance means someone is accountable for data quality, there are defined standards for how records are created and maintained, and there is a regular audit process to catch drift before it becomes debt.

MSPs that build this infrastructure now will have two or three years of clean operational history by the time the rest of the market catches up. That history is not something you can buy or shortcut. It has to be earned through consistent practice.

Where to Start: A Practical Sequence for MSPs

The gap between knowing data quality matters and actually doing something about it is where most MSPs get stuck. The work feels overwhelming, especially when you are trying to run service delivery at the same time. The key is to resist the urge to fix everything at once and instead move through a deliberate sequence.

Start with your PSA. Your PSA is the operational center of gravity for most MSPs, which makes it both the biggest data problem and the highest-leverage place to start. Audit your ticket categories, client records, and time entry practices. Establish standards for how data gets entered and who is responsible for maintaining it. Even a modest cleanup effort here will have immediate downstream effects on reporting accuracy.

Connect before you expand. Before adding more tools, focus on improving the connections between the tools you already have. A PSA and RMM that share clean, normalized client records are more valuable than a disconnected stack of specialized platforms. Integrations only create value when the data flowing through them is trustworthy.

Assign ownership explicitly. Data quality problems persist when nobody owns them. Designate someone, whether that is an operations manager, a technical lead, or a vCIO, who is accountable for data standards. This does not require a dedicated data team. It requires clear accountability and regular review.

Build incrementally. The goal is not to achieve perfect data quality before you start using AI. The goal is to improve data quality continuously while beginning to apply AI in areas where your data is already reliable enough. This crawl-walk-run approach lets you generate early wins while building the foundation for more sophisticated applications over time.

What Clients Will Start Expecting, and Soon

The client-facing implications of data quality are under-appreciated. Right now, most clients do not explicitly ask about your data practices. They evaluate MSPs on responsiveness, technical competence, and price. That is changing.

As AI-driven reporting, predictive recommendations, and automated insights become standard offerings, clients will start distinguishing between MSPs that produce reliable intelligence and those that produce dashboards that look impressive but cannot be trusted. A vCIO conversation backed by clean data and AI-driven analysis is categorically different from one built on gut feel and manually compiled spreadsheets.

MSPs that invest in data quality now will be positioned to deliver that kind of insight as a differentiator. The ones that wait will find themselves in a race to catch up at exactly the moment when clients are paying close attention to the difference. Being six months ahead of client expectations is far more valuable than being six months behind them.

The Narrowing Window for First-Mover Advantage

The competitive window for data quality as a differentiator is real, but it is not permanent. AI adoption among MSPs is accelerating, and with it comes growing awareness that data infrastructure matters. Tool vendors are building better guidance into their platforms. Industry conversations are shifting from "should we use AI" to "how do we operationalize it." That shift will eventually surface data quality as a prerequisite rather than an advantage.

The MSPs that will benefit most from the current moment are the ones that treat data quality as a strategic investment rather than a technical cleanup project. That means allocating time and attention, setting measurable standards, and building data governance into how the business operates, not as a one-time sprint but as an ongoing discipline.

The window is still open. But the MSPs moving fastest right now are not waiting for the market to tell them this is important.

Conclusion

Data quality is not a glamorous priority, but it is one of the most consequential ones available to MSPs right now. The competitive advantage is real, the compounding effects are significant, and the window to act ahead of the market is narrowing as AI adoption accelerates across the industry.

The path forward does not require a massive transformation project. It requires a clear methodology, explicit ownership, and the discipline to improve incrementally rather than waiting for perfect conditions. Cybersecurity has CIS Controls. AI has mostly had vibes. The MAGIC Framework is the controls-first alternative: five Implementation Guards from Baseline to Frontier, each level earning the right to the next, built as a shared and auditable playbook that MSPs can adopt and improve over time. If the sequence described in this post is the right direction, MAGIC is the map. It is free and browsable.

The Importance of a Copilot Prompt Library for MSP Teams: How Drive Adoption Fast

Mon, 03 Aug 2026 04:00:03 GMT

Most MSPs that have deployed Microsoft 365 Copilot to clients face the same quiet problem: the seats are live, the licenses are paid, and almost nobody is using the tool consistently. Individual staff members might experiment on their own, but there is no shared understanding of what good AI usage looks like. The result is uneven adoption, hard-to-measure ROI, and a growing sense that Copilot is not delivering what was promised.

A prompt library changes that dynamic. Microsoft recently surfaced an admin-managed prompt library feature inside Microsoft 365 Copilot that lets administrators curate and distribute approved prompts directly to end users. For MSP owners and operations leaders, this is not just a product update to pass along to clients. It is a structural tool you can use inside your own business to make AI usage consistent, repeatable, and measurable across every team.

What the Copilot Admin Prompt Library Actually Does

The feature allows Microsoft 365 administrators to build a curated collection of prompts and surface them to users directly within the Copilot interface. Instead of leaving every employee to figure out prompting on their own, you define what good looks like and push it to the people who need it.

For an MSP, this matters at two levels. First, it gives you something concrete to implement for clients as part of an AI adoption engagement. Second, it gives you a governance mechanism for your own internal Copilot rollout. You can define prompts by department, by role, or by workflow, and you can update them centrally as your understanding of what works improves.

The library is not just a reference document stored somewhere on SharePoint. It is integrated into the Copilot experience, which means prompts are visible at the moment of use rather than buried in a tab no one remembers to open. That distinction matters for adoption. Friction at the point of use is where most AI rollouts quietly die.

Why Standardization Is the Missing Step in Most MSP AI Rollouts

When MSPs think about AI adoption, they tend to focus on deployment and training. Get the licenses. Run a lunch-and-learn. Send some how-to guides. These steps are necessary but not sufficient. What they miss is standardization, specifically the process of agreeing on how AI should be used for specific tasks and encoding that agreement in a format teams can actually follow.

Prompt standardization does for AI what runbooks do for IT operations. It takes tribal knowledge about what works and turns it into a repeatable process anyone on the team can execute. A new service desk technician does not need to figure out from scratch how to write an effective Copilot prompt for drafting a client escalation email. That prompt already exists in the library. They use it, they get a good output, and they build confidence in the tool.

Without standardization, you get inconsistency. One team member gets excellent results from Copilot because they have spent time learning to prompt well. Another gets mediocre output and quietly stops using the tool. You have no visibility into either outcome. A prompt library makes the difference between these two employees a solvable operational problem rather than a permanent gap in capability.

How Internal Hackathons Accelerate Prompt Library Development

You do not have to build a prompt library from scratch on your own. One of the most effective approaches is running a structured internal hackathon focused specifically on prompt development. The format is straightforward: bring teams together for a defined period, assign real workflows to each group, and challenge them to develop and test prompts that produce reliable, high-quality outputs for those workflows.

Hackathons work for this purpose because they surface knowledge that would otherwise remain invisible. Your senior account manager may have developed a prompting approach for quarterly business review preparation that cuts their prep time significantly. Your NOC lead may have found a reliable way to use Copilot for drafting incident summaries. A hackathon creates the conditions for that knowledge to become organizational property rather than individual habit.

The outputs from these sessions feed directly into your admin-managed prompt library. You end this process with a curated, tested, department-specific collection of prompts that your team developed and validated themselves. That ownership matters. Prompts your team built are prompts your team will actually use.

The hackathon model also generates a secondary benefit. It gives you a structured activity to offer clients as part of an AI adoption engagement, not as a theoretical recommendation but as something you have run and refined internally.

Making AI Usage Measurable Across the Business

One of the persistent frustrations with AI adoption is that the benefits are real but difficult to quantify in a way that satisfies leadership or justifies continued investment. A prompt library helps solve this problem by creating structure around AI usage that makes measurement possible.

When prompts are standardized and centrally managed, you can start to ask specific questions. Which prompts are being used most frequently? Which workflows have the highest Copilot engagement? Where are teams still defaulting to manual processes when an AI-assisted workflow exists? Microsoft 365 Copilot provides usage analytics, and a prompt library gives that data a framework for interpretation.

Beyond analytics, standardized prompts make it easier to conduct before-and-after comparisons for specific tasks. If you have defined a prompt for drafting client-facing proposals, you can measure the time required for that task before and after the prompt was introduced. That kind of task-level measurement is far more persuasive to leadership than aggregate usage statistics.

For MSPs specifically, this measurement capability is also a client deliverable. When you can show a client that Copilot usage increased 40% in the month following prompt library deployment, with corresponding reductions in time spent on specific administrative tasks, you have a concrete argument for the value of your AI adoption services.

Building a Prompt Library That Scales With Your MSP

A prompt library is only useful if it stays current. The workflows your team uses today will evolve, Copilot's capabilities will expand, and you will learn from actual usage which prompts perform well and which need refinement. The library needs an owner and a maintenance cadence, not a one-time setup.

Start with a small number of high-value workflows rather than trying to cover everything immediately. Identify the three to five tasks in your business where AI assistance would have the highest impact, whether that is client communication, documentation, internal reporting, or technical escalation drafting. Build and test prompts for those workflows first, get them into the admin library, and measure what happens.

From there, expand by department. Ask each team lead to identify their highest-volume repetitive tasks and run a structured session to develop prompts for them. This approach distributes the development work while keeping the governance centralized. You maintain quality control through the admin library without creating a bottleneck where everything has to flow through one person.

Treat the prompt library as a living product. Schedule quarterly reviews to assess which prompts are being used, which have been superseded by new Copilot capabilities, and which workflows have emerged as new candidates for AI assistance. This cadence keeps the library relevant and keeps AI adoption moving forward rather than stalling after the initial rollout.

Conclusion

The Copilot admin prompt library feature is one of those platform updates that looks incremental on the surface but has significant operational implications if you act on it deliberately. For MSPs, it is both an internal adoption tool and a client-facing capability, a way to make AI usage consistent and measurable in your own business while also building a repeatable service offering around AI operationalization.

The MSPs that will see the most return from Microsoft 365 Copilot are not the ones who deployed the most seats. They are the ones who invested in the structure around usage: the prompt standards, the governance, the measurement, and the culture of continuous improvement that keeps adoption moving. A well-maintained prompt library is one of the most practical ways to build that structure without requiring specialized AI expertise your team does not yet have.

One last thing worth noting. The admin-managed prompt library is not a widely publicized feature. Your client should not know about it before you do, and with Microsoft shipping at the pace they ship, that gap closes faster than it should. The AI Digest tracks Copilot platform releases and feature rollouts, over 700 updates tracked, so you can stay current without monitoring Microsoft's release notes yourself. Subscribe to the topics that matter to your practice, or browse the full feed free.

AI Use Cases for MSPs With Connected Data

Fri, 31 Jul 2026 04:00:05 GMT

Most MSPs have the data. The problem is that it lives in six different places. Your PSA holds ticket history. Your RMM holds device telemetry. Your finance tool holds project actuals. Your spreadsheets hold the rest. When those systems do not talk to each other, AI has nothing useful to work with, and the "AI-powered insights" vendors keep promising stay firmly in the category of theoretical.

The shift happens when you centralize that data into a unified structure, often called a data lakehouse, where your PSA, RMM, billing, documentation, and project management data all land in one queryable environment. At that point, AI stops being a feature you demo and starts being an operational capability you run. The use cases below are not speculative. They are queries and workflows MSPs are running right now against connected data, and they are delivering real business value.

If you have been waiting to understand what AI would actually do for your MSP once your data infrastructure is in place, this is that answer.

QBR Preparation in Minutes, Not Hours

Quarterly business reviews are one of the highest-value client touchpoints an MSP has, and they are also one of the most labor-intensive to prepare. Pulling together ticket volume trends, resolution times, open risks, project statuses, and budget summaries across a single client account can take a technician or account manager two to four hours per client. For a 50-client book of business, that math gets painful fast.

With centralized data, a well-constructed AI query can pull every relevant data point for a given client and generate a structured QBR summary in seconds. You specify the client, set the date range, and define the output format. The AI cross-references ticket data, device health trends, project progress, contract utilization, and any flagged escalations to produce a first draft that a human reviews and refines, rather than builds from scratch.

The output is not just faster. It is more consistent. Every client gets the same analytical depth regardless of which account manager owns them. That consistency matters when you are trying to scale a high-quality client experience without adding headcount proportionally.

Churn Risk Scoring Across Your Client Base

Client churn is expensive, and the warning signs are almost always visible in retrospect. The client who left six months ago probably showed elevated ticket escalation rates, reduced engagement scores, and a stalled project in the three months before they canceled. Without a unified view of those signals, no one saw the pattern until it was too late.

Connected data makes proactive churn risk scoring possible. You can build a scoring model that weights factors like ticket sentiment trends, response time complaints, missed SLA instances, contract renewal proximity, and executive engagement cadence. Run that model across your entire client base and you get a ranked list of accounts by churn risk, updated on whatever frequency makes sense for your business.

This is not just about retention. It is about resource allocation. When you know which clients are at risk, you can direct account management attention where it will have the most impact. You can also trigger automated check-ins or escalation reviews for clients crossing a risk threshold, rather than waiting for the call that tells you they are leaving.

Technician Performance Anomaly Detection

Managing technician performance at scale is difficult without good data. Most MSPs track basic metrics like ticket volume and average resolution time, but those surface-level numbers miss the patterns that actually matter. A technician who closes tickets quickly but generates high rates of repeat issues is creating hidden costs. A technician whose resolution times have increased significantly over the past 30 days may be dealing with a skill gap, a tooling problem, or something worth a quiet conversation.

With centralized data, you can run anomaly detection queries that surface these patterns automatically. Rather than reviewing every technician's metrics manually each week, you set a baseline, define acceptable variance, and let the AI flag deviations. A technician whose ticket reopen rate has jumped 40 percent in the last two weeks gets flagged for review. A technician who is consistently resolving a specific category of issue faster than their peers gets identified as a potential trainer or documentation contributor.

The goal here is not surveillance. It is informed management. Your operations lead cannot monitor every ticket. Anomaly detection gives them a prioritized list of what actually warrants attention, which makes coaching conversations more targeted and performance management more fair.

Real-Time Project Budget and Scope Visibility

Project overruns are one of the most consistent margin killers in MSP businesses. They often do not surface as overruns until the project is already over, because no one had a live view of hours consumed versus hours budgeted at the task level. By the time the project manager notices the burn rate problem, there are two weeks left and nothing left in the budget.

Centralizing your project management, time tracking, and billing data creates the foundation for real-time budget status queries. You can ask a question like "which projects are currently tracking to exceed their budgeted hours by more than 15 percent" and get an answer that reflects the current state, not last week's export. You can set up automated alerts when a project crosses a budget threshold, giving project managers a window to intervene before the overrun is locked in.

This same data connection also supports better estimating over time. When historical project actuals sit alongside original estimates, you can analyze where specific project types consistently run over, which engineers tend to estimate accurately, and which clients tend to generate scope creep. That institutional knowledge stops living in someone's head and starts informing your next proposal.

Client Escalation Readiness Scoring

When a client situation escalates to the executive level, your team needs to walk into that conversation fully prepared. They need to know the history of open issues, what was promised and when, which tickets are aging, and whether any contractual commitments are at risk. Without centralized data, assembling that picture means pulling from multiple systems under pressure, often right before the call.

Escalation readiness scoring solves this by maintaining a continuously updated view of each client's escalation posture. You define the signals that indicate a client is moving toward an executive escalation, things like a cluster of high-severity tickets, a pattern of after-hours contacts, or a spike in direct emails to your leadership team. The AI monitors those signals and generates a readiness brief automatically when a client crosses a threshold.

Preventing an escalation is always better than managing one. That brief gives whoever takes the call the context they need without the scramble, and it gives your team the opportunity to reach out proactively before the client feels the need to escalate at all.

The Infrastructure Is the Prerequisite

Every use case described above requires the same foundation: your data has to be connected, structured, and queryable. None of this works with siloed systems and manual exports. The AI does not create the insight. It surfaces insight from data that is already there. Your job is to make sure that data is in a place where AI can reach it consistently.

Once that infrastructure is in place, these use cases are not one-time projects. They are repeatable, scalable operational capabilities that compound over time as your data history grows. QBR prep gets faster. Churn risk models get more accurate. Technician performance baselines get more precise. The MSPs who build this foundation now are the ones who will be operating at a fundamentally different level two years from now.

Should MSPs Build or Buy AI Tools? Three Costs Decide

Wed, 29 Jul 2026 04:00:01 GMT

The build-vs-buy debate is as old as enterprise software itself. But when MSPs apply that familiar framework to AI, they often walk into the analysis with faulty assumptions. The logic sounds reasonable on the surface: you have engineers on staff, you understand your clients' data, and you want control. Why pay a vendor when you could build something custom?

The answer comes down to three specific costs that internal advocates for building almost always underestimate. Not because they are careless, but because these costs are genuinely non-obvious until you are deep inside an AI infrastructure project and the invoices start arriving. John and Evan have watched this pattern repeat across the MSP space, and the numbers tell a consistent story.

This post breaks down each of those three costs so you can run the analysis honestly before you commit budget, engineering time, or leadership attention to a direction that may not serve you.

The First Cost: Token Economics Are Not What You Expect

If you have experimented with OpenAI, Anthropic, or any of the major model providers, you have probably looked at the per-token pricing and thought it seemed manageable. It is manageable at low volume, during testing, or when a single engineer is querying the API manually. The math changes significantly when you are running production workloads at MSP scale.

Consider what "at scale" actually means for an MSP. You are not running one query at a time. You are potentially processing tickets, summarizing documentation, generating client-facing reports, running anomaly detection across endpoints, and handling natural language interfaces for internal tools, all simultaneously, across dozens or hundreds of client environments. Token consumption compounds quickly.

Context windows are a major driver that teams consistently overlook. Many AI use cases require you to inject substantial context into each prompt: system instructions, relevant history, retrieved documentation, client-specific parameters. A single "simple" query with full context can consume ten to twenty times more tokens than a naive estimate would suggest. When you multiply that by request volume across a full production deployment, the monthly API bill can land two to four times higher than your initial projection.

Building your own AI infrastructure means you own that cost structure with no abstraction layer and no negotiating position. You are a small customer to the model provider, paying retail rates, with no built-in cost optimization logic unless you build that yourself too.

The Second Cost: Maintenance Is a Product, Not a Task

There is a mental model that treats infrastructure as something you build once and then maintain occasionally. That model does not apply to AI infrastructure, and applying it will create serious problems for your team.

AI models are not static. The underlying models you build on top of get updated, deprecated, and replaced. Prompt patterns that work reliably today may perform poorly after a model update. Retrieval-augmented generation systems require continuous attention to embedding quality, chunking strategy, and index freshness. Fine-tuned models need retraining as your data distribution shifts. Security and compliance requirements around data handling evolve constantly, and AI systems handling client data face particular scrutiny.

What this means in practice is that maintaining an AI system you built internally is not a support burden, it is a product ownership burden. You need someone accountable for the system's performance, someone watching for degradation, someone evaluating whether the architecture choices you made six months ago still make sense given what the ecosystem has done since then.

That person exists in a buy relationship too, but they work for the vendor. In a build relationship, that person is one of your engineers, and their time spent on AI infrastructure maintenance is time not spent on billable work, on client relationships, or on the operational improvements your business actually needs.

The Third Cost: Engineering Hours Have a Real Opportunity Cost

This is the cost that gets the least honest treatment in internal build-vs-buy analyses, because it requires you to quantify something most organizations prefer to keep abstract.

Your engineering hours are not free. Even when you are paying salaries rather than billing clients directly for that time, every hour an engineer spends building and maintaining internal AI infrastructure is an hour not spent somewhere else. The question is whether that somewhere else is more valuable.

For most MSPs, the answer is yes, clearly and significantly. Think about the opportunity cost in concrete terms. A senior engineer spending 30 percent of their time on an internal AI infrastructure project is likely foregoing some combination of the following: billable client work at your standard rate, improvements to your service delivery operations that would reduce cost or improve margin, work on internal tooling that would make your team more efficient, or technical leadership on client-facing initiatives that could expand your accounts.

If that engineer bills at $150 per hour and works approximately 2,000 hours annually, 30 percent of their time represents $90,000 in potential billable revenue per year , before you account for overhead, before you account for the compounding value of client relationship development, and before you account for the fact that you will likely need more than one person to build and maintain a serious AI infrastructure. Multiply that across a small team over an 18-month build timeline and you are looking at a real number that should appear prominently in your analysis.

The build path is not just expensive in the ways that show up on infrastructure invoices. It is expensive in the ways that show up on your revenue line.

What "Build" Actually Requires at MSP Scale

It helps to be specific about what you are actually committing to when you choose to build. This is not a criticism of the build path in principle. Some organizations have the scale, the resources, and the specific requirements that make building the right choice. But MSPs evaluating this decision should go in with a clear picture.

A functional internal AI data infrastructure for an MSP typically requires:

A data ingestion and normalization layer that can handle heterogeneous client data sources
A vector database and retrieval system for knowledge management
An orchestration layer to coordinate model calls, context injection, and output handling
Security and access control logic to maintain client data isolation
Monitoring and observability tooling to detect performance degradation
An evaluation framework to measure output quality over time

Each of those components requires initial build time and ongoing maintenance, and each interacts with the others in ways that create compounding complexity. The ecosystem each component sits in is moving fast enough that your architectural choices have a shelf life measured in months, not years.

When the Buy Decision Is Clearly Right

Given those three cost categories, the buy path makes sense for most MSPs in most situations. Not because building is inherently wrong, but because the cost-benefit calculation is genuinely unfavorable for organizations operating at typical MSP scale.

The buy decision is strongest when:

Your engineering team is small or primarily focused on client delivery
You need AI capabilities operational within months rather than years
Your clients operate in regulated industries where data handling compliance is non-negotiable
Your competitive advantage comes from service quality and client relationships rather than from proprietary AI infrastructure

Buying also does not mean surrendering control or differentiation. The right AI partner gives you configurable systems you can adapt to your workflows, transparent cost structures you can plan around, and a maintenance burden that stays on their side of the relationship. You get to focus your internal resources on what actually differentiates your business.

The Argument Is Simpler Than It Looks

Three costs, honestly accounted for, usually resolve the build-vs-buy question for MSPs. Token economics at production scale come in higher than initial estimates. Ongoing maintenance is a product ownership commitment, not an occasional task. And internal engineering hours carry an opportunity cost that deserves to appear in the analysis the same way vendor fees do.

The MSPs that are moving fastest with AI right now are not the ones that built the most infrastructure. They are the ones that made a clear-eyed decision about where to focus their resources, and then moved.

How to Prepare MSP Data for AI Before You Deploy

Mon, 27 Jul 2026 04:00:19 GMT

The AI tools promising to transform your MSP operations are only as good as the data you feed them. That sounds obvious, but most MSPs skip the foundational work and jump straight to deployment. They connect a new AI layer to their PSA or RMM, run a few queries, and get back results that feel off. Tickets miscategorized. Summaries that miss context. Recommendations that contradict what your team knows to be true. The tool gets blamed, but the real problem started long before the tool was installed.

Getting your data ready for AI is not a technology problem. It is a discipline problem. It requires decisions about how information enters your systems, what stays and what gets archived, and who owns the standards that keep everything consistent over time. MSPs that do this work first get AI deployments that compound in value. MSPs that skip it spend months troubleshooting outputs that never quite work.

This post walks through the structural data work your MSP needs to complete before any AI layer can return results you can trust and act on.

Why Does Dirty Data Break AI Specifically?

AI models do not experience your data the way a human analyst does. A seasoned technician can look at a ticket that says "client called, something is wrong with the internet" and mentally fill in the gaps from memory, context, and client history. An AI model cannot do that reliably. It reads what is there and draws inferences based on patterns. If your patterns are inconsistent, the inferences will be wrong.

The categories of data problems that hurt AI performance are different from the ones that simply slow down human workflows. Duplicate records confuse entity resolution. Inconsistent field naming creates false categorizations. Free-text fields with no structure carry signal the model cannot parse. Stale records from clients you no longer support pull historical averages in directions that have nothing to do with your current business.

Before you evaluate any AI tool, you need an honest audit of what is actually in your PSA, your documentation platform, and your ticketing system. Not a surface-level check. A real assessment of completeness, consistency, and relevance. This audit becomes the baseline for every decision that follows.

How Do You Standardize How Data Enters Your Systems?

The most common data problem in MSPs is not bad data that already exists. It is new bad data created every day because there are no enforced standards for how information is entered.

Technicians use different words for the same issue type. Account managers log notes in inconsistent formats. Ticket closures happen without resolution codes. Client records get updated in one system but not another. Each small inconsistency is manageable when a human reads individual records. At scale, across the volume of data an AI model ingests, they become noise that degrades every output.

Standardizing data entry means building mandatory fields, controlled vocabularies, and structured templates that make inconsistency harder than consistency. In your PSA, that might mean required resolution categories, standardized client naming conventions, and dropdown fields rather than open text wherever possible. In your documentation platform, it means templates with defined sections that every technician fills out the same way.

This is not about restricting how your team works. It is about making sure the information they generate is machine-readable in a way that produces reliable AI outputs. The constraint on the front end pays off every time the AI returns an accurate result on the back end.

What Should You Archive Before You Deploy?

AI models trained or fine-tuned on your historical data will reflect the patterns in that data. If your data includes three years of support records from a client segment you no longer serve, a vertical you exited, or a technology stack you replaced, those patterns will show up in your outputs.

Archiving is not the same as deleting. You are not losing history. You are making a deliberate decision about what context is relevant to the AI layer you are building and what will create noise or skew results in directions that no longer serve your business.

A practical approach is to define a relevance window based on your current service catalog and client mix. Records from active clients and current services stay in the primary dataset. Records outside that scope move to a separate location the AI tool does not ingest by default. You can always query the archive directly when historical research requires it.

This step also forces a useful business conversation. When you decide what data is relevant, you surface assumptions about what your MSP actually is right now versus what it was two or three years ago. That clarity benefits operations well beyond any AI deployment.

How Do You Build a Methodology for What Gets Ingested?

Cleaning existing data and standardizing new data entry solves the quality problem. But you also need a deliberate methodology for which data sources feed your AI tools and in what form.

Not everything in your environment should be ingested. Some data is sensitive in ways that create compliance risk if it flows through a third-party AI platform. Some data is technically accessible but low signal, meaning it will not meaningfully improve AI outputs and will increase processing overhead. Some data exists in formats that require transformation before it is useful.

Your ingestion methodology should define:

Source systems and their priority order
Data transformation rules that normalize records before ingestion
Refresh cadence so the AI is working from current information
Access controls that determine who can query what

The MSPs that treat data governance as infrastructure, rather than a setup task, are the ones whose AI capabilities improve over time instead of degrading. This is not a one-time decision. Your ingestion methodology needs to be a living document your team revisits as you add new tools, onboard new clients, or change your service catalog.

Who Should Own Data Quality Before You Deploy Anything?

Every data quality initiative fails for the same reason: no one owns it. A project lead pushes for standardization, the team complies for a few weeks, and then old habits return because there is no ongoing accountability.

Before you connect any AI tool to your environment, assign a named data owner. This does not have to be a full-time role. In most MSPs, it sits alongside another function, operations manager, service delivery lead, or a senior technician with process authority. What matters is that someone has explicit responsibility for maintaining the standards you set, reviewing data quality on a defined schedule, and making calls about ingestion decisions as the environment evolves.

Pair the ownership assignment with a lightweight governance process: a monthly data review cadence, a place to flag quality issues, and a clear path to updating standards when the business changes.

The goal is to make data quality self-sustaining rather than dependent on a periodic cleanup sprint.

How to Keep Up With Microsoft Copilot Updates as an MSP

Wed, 22 Jul 2026 04:00:03 GMT

Keeping up with Microsoft Copilot feels like trying to read a book while someone keeps adding pages. Microsoft has committed to a continuous release cadence for Copilot features across Teams, Outlook, Word, Excel, and the broader 365 ecosystem. By the time your team finishes evaluating one update, three more have shipped.

For MSPs, this creates a specific and painful problem. Your clients expect you to be the expert. When a CFO asks whether Copilot's new meeting recap feature is worth enabling, or a client's IT manager wants to know if the latest Copilot agent capabilities change their security posture, you need an answer. Being caught flat-footed erodes the trust that your entire service relationship depends on.

The challenge is not a lack of information. It is an excess of it, scattered across Microsoft's release notes, tech blogs, partner portals, and community forums. This post lays out a practical approach to staying current without burning out your team.

Why the Copilot Update Pace Is Different From Normal Software Releases

Traditional software release cycles gave IT teams breathing room. A major update every quarter, a feature preview period, time to test. Microsoft's AI-integrated products do not follow that pattern.

Copilot features are rolling out through multiple channels simultaneously: Microsoft 365 Admin Center message center posts, the Microsoft 365 roadmap, Copilot Studio announcements, Azure OpenAI model updates, and periodic "Copilot Wave" announcements that bundle dozens of changes at once. Add to that the fact that foundational model updates from OpenAI can change Copilot's behavior without any visible version bump, and you have a situation where the product your client used last Tuesday may behave meaningfully differently by next Monday.

For MSPs managing dozens or hundreds of clients across different licensing tiers, this complexity multiplies. A change that matters for a client on Microsoft 365 Business Premium may be irrelevant to one on E3, or may land months later. Tracking feature availability by SKU, tenant configuration, and rollout ring is a real operational burden.

The MSPs who handle this well are not the ones with the largest teams or the biggest research budgets. They are the ones with a structured process for triage: knowing which updates require immediate action, which require client communication, and which can be monitored over time.

The Personal Trial Approach: Why It Works and Where It Breaks Down

One of the most effective ways to actually understand a new Copilot feature is to use it yourself before recommending it to clients. When you personally generate a Copilot summary in an Outlook thread, run a Copilot prompt in Excel on real data, or configure a Copilot agent in Teams, you develop an intuition for what works and what is still rough.

This hands-on approach surfaces things release notes miss. You will notice the prompt wording that gets useful results versus vague ones. You will catch limitations in how Copilot handles certain file types or data structures. You will understand the user experience well enough to set realistic client expectations.

The problem is scalability. If your lead engineer or practice manager is personally trialing every new AI release, they are spending significant time on research that does not directly generate revenue. That time cost compounds as the number of tools grows beyond Copilot alone, into Claude, Gemini, Copilot Studio agents, and the AI features being embedded into your PSA, documentation, and RMM platforms.

The answer is not to stop personal trialing. It is to be selective about which tools warrant deep hands-on evaluation and to build a system that handles the monitoring layer so your team is only trialing things that have already cleared a relevance threshold.

Building a Monitoring System Your Team Will Actually Use

The goal of a monitoring system is not to read everything. It is to reduce the signal-to-noise ratio so your team spends time on information that matters.

Tier your sources. Not all sources carry equal weight. Microsoft's official message center posts and roadmap are authoritative for timing and SKU availability. Community sources like the MSP subreddit, partner communities, and podcasts are better for real-world implementation experience. Separate these mentally and in your workflow.

Assign ownership. Without a named owner, AI update monitoring becomes everyone's responsibility and therefore no one's. Designate one person to own the weekly scan of Copilot release notes and roadmap updates. That person does not need to evaluate every change in depth. Their job is triage: flag what matters, archive what does not, and escalate what requires team discussion.

Create a standing agenda item. A 15-minute weekly or biweekly team slot dedicated to AI updates builds the habit and creates a forcing function. Your designated monitor brings the flagged items. The team decides what requires action, client communication, or further testing. This keeps the whole team calibrated without requiring everyone to do their own research.

Use curated intelligence tools. You do not need to build this monitoring infrastructure entirely from scratch. Services that track AI releases across Microsoft, Anthropic, and other major vendors and surface relevant changes in a structured format can significantly reduce the burden on your designated monitor and ensure you are not missing releases that fall outside your usual reading sources.

Turning Copilot Knowledge Into a Client-Facing Advantage

Staying current on Copilot updates is not just an internal operational concern. It is a commercial opportunity.

Clients are being bombarded with marketing about AI. They hear about Copilot from Microsoft directly, from LinkedIn, from their peers. What they are not getting from most of their vendors is a clear, honest answer to the question: "What does this actually mean for my business, and what should I do about it?"

MSPs who can answer that question confidently and regularly become indispensable advisors rather than commodity service providers. This means having a process to translate update monitoring into client-facing communication.

When a significant Copilot update lands, consider what your clients need to know. Does this change how they need to configure their tenant? Does it introduce new capabilities they should pilot? Does it create a security or compliance consideration? A short, plain-language update to relevant clients, delivered proactively, signals that you are watching out for their interests.

Over time, this positions your MSP as the trusted interpreter of AI change rather than a reactive support desk. That is a differentiated value proposition that compounds with every wave of updates Microsoft ships.

The pace of Microsoft Copilot updates is not going to slow down. If anything, as Microsoft continues integrating AI more deeply across the 365 suite, Copilot Studio, and its security and compliance products, the rate of meaningful change will increase. The MSPs who thrive in that environment will not be the ones who read the most. They will be the ones with a system that filters signal from noise, assigns clear ownership, and translates change into client value.

You do not need to hire a dedicated AI researcher or spend hours each week in release notes to stay current. You need a repeatable process and the right tools to support it.

Internal AI Hackathon: Drive Real MSP Employee Adoption

Mon, 20 Jul 2026 04:00:03 GMT

Most MSPs have purchased at least one AI tool in the past year. Fewer have figured out how to make their technicians actually use it. The gap between "we have AI access" and "our team thinks in AI-first terms" is not a technology problem. It is a culture and change management problem, and it will not close on its own.

You do not need a formal training program, an outside consultant, or months of runway to close that gap. What you need is a structured, time-boxed challenge that gives your team permission to experiment, a clear goal to aim at, and a reason to care about winning. An internal AI hackathon does exactly that. Artie, one of the MSP operators we work with closely, ran a four-week employee challenge built around a deceptively simple constraint: build an AI agent that reclaims at least one hour per week. The results were worth examining closely, and the model is repeatable.

Why "One Reclaimed Hour" Is the Right Constraint

Hackathons fail when the goal is too abstract. "Explore AI capabilities" or "get comfortable with the tools" sounds reasonable, but it gives participants no way to know whether they are succeeding. Artie's team solved this by anchoring the challenge to something every technician already cares about: time.

One reclaimed hour per week is specific enough to be measurable, ambitious enough to feel meaningful, and humble enough that a mid-level tech can actually reach it. It also shifts the framing away from "learn a new tool" and toward "solve a real problem." That distinction matters. When your team is building toward a tangible outcome, they engage differently than when they are completing training modules.

The constraint also naturally filters toward high-value use cases. To reclaim an hour, participants have to identify where time is actually being lost in their workflows. That discovery process is itself valuable, often producing insights about inefficiencies that have nothing to do with AI. The hackathon becomes a structured audit of how work actually gets done, which is something most MSPs have never formally attempted.

How to Structure Four Weeks Without Losing Momentum

A four-week timeline is long enough to produce real results and short enough to maintain urgency. Here is how Artie structured each phase:

Week one: Problem identification. Each participant documented two or three recurring tasks that consume time without requiring deep judgment. Ticket triage, routine client status updates, documentation drafts, alert categorization. The goal was not to find the perfect use case but to identify any use case worth testing.

Week two: Build the first version. Participants started building or configuring AI agents targeting their identified problem. Artie's team used a mix of tools depending on the tech's comfort level, and no one was required to use the same platform. This reduced the anxiety of "learning the tool" and kept focus on the outcome.

Week three: Test and refine. This is where most hackathons stall, because the first version almost never works the way you expect. Build explicit iteration time into the schedule. Artie held a mid-challenge check-in where techs shared what was working and what was not, which created organic peer learning without formal instruction.

Week four: Demo day and vote. Each participant presented their agent to the full team, walked through the problem it solved, and quantified the time reclaimed. The team voted on the best submission. Artie awarded a monetary prize to the winner.

That final vote is not just a nice ending. It creates a social incentive that persists through the harder middle weeks when enthusiasm naturally dips.

The Monetary Prize: Smaller Than You Think, More Effective Than You Expect

You do not need a large prize to make this work. Artie's prize was meaningful but not extravagant. The psychological effect of a monetary reward is less about the amount and more about what it signals: that leadership takes this seriously enough to put something real on the line.

A gift card or bonus that feels like an afterthought will produce afterthought-level engagement. A prize that requires a team vote to award produces something different. It creates accountability between peers, not just between employees and management. When your techs know their colleagues will evaluate their work, the quality of that work tends to rise.

If budget is genuinely constrained, there are alternatives that carry similar weight: extra PTO, a team outing, public recognition in a company all-hands. The mechanism matters less than the signal. Make it clear that this challenge is a real priority, not an HR initiative to check off.

What You Actually Get at the End of Four Weeks

The obvious output is a set of working AI agents built by your own team. Some will be rough. Some will be genuinely impressive. All of them will reflect real operational knowledge about your specific environment, client base, and workflows, which is something no off-the-shelf tool can replicate.

But the less obvious output is more valuable. By the end of four weeks, you will have identified which technicians have high AI aptitude and want to go deeper. You will have surfaced use cases you had not thought to look for. You will have created a shared vocabulary around AI that did not exist before. And you will have demonstrated to your team that AI fluency is something you build by doing, not by watching videos.

Artie's team came out of the challenge with three agents that went into regular production use. More importantly, they came out with a different attitude toward the tools. The question shifted from "should I try this?" to "what should I build next?" That shift is the actual goal, and a four-week hackathon is one of the most reliable ways to produce it.

Making It Repeatable: Turning One Hackathon Into a Culture

A single hackathon is a good start. A quarterly cadence is a culture shift. If the first challenge goes reasonably well, resist the temptation to declare victory and move on. Schedule the next one before the momentum from the first one fades.

Each subsequent challenge can raise the bar slightly. The second challenge might target two reclaimed hours instead of one, or require integration across multiple tools, or focus on a specific service line like security operations or project management. You are building a curriculum, even if it does not look like one.

The agents your team builds also become shared assets. Document them. Build a simple internal library where techs can find and adapt each other's work. Over time, that library becomes one of your most durable operational advantages, a body of IP that reflects your team's expertise and your clients' actual needs.

Moving your MSP team from having AI tools to genuinely using them is not a technical challenge. It is a human one. A structured four-week hackathon with a clear constraint, a competitive incentive, and a team vote gives you a repeatable mechanism to drive real adoption without mandating it.

Artie's model works because it respects how people actually change behavior: through doing, through peer accountability, and through visible recognition that the work matters. You can run this quarter. The version you run six months from now will be better, because your team will be better.

AI Acceptable Use Policy for SMB Clients: The MSP Playbook

Fri, 17 Jul 2026 04:00:03 GMT

Most SMB clients are already using AI. They just have not told you about it yet. Employees are pasting customer data into ChatGPT, using AI writing tools on company devices, and experimenting with browser-based assistants that have no connection to your security stack. By the time a client mentions AI in a QBR, the exposure is already there.

That is exactly why the AI acceptable use policy deserves to be the first thing you raise in every AI conversation, not the last. It is not a formality or a legal checkbox. It is a diagnostic tool. The way a client responds to the question "do you have an acceptable use policy for AI?" tells you almost everything you need to know about their current risk posture, their readiness for AI adoption, and how much governance work lies ahead.

This post walks through how to use that single question as a structured entry point into the broader security and data governance conversation, and how to turn it into a repeatable process across your client base.

Why the Acceptable Use Policy Question Works as an Opener

Ask a client whether they have an AI acceptable use policy and you will get one of three responses. They say yes and can show you the document. They say yes but cannot produce it, which usually means it was copied from a template and never operationalized. Or they say no, which is the most common answer, and the most honest.

Each response is useful. The client who has a documented, enforced policy is ahead of the curve and ready for a more sophisticated conversation about AI integration. The client who thinks they have a policy but cannot locate it has a governance gap that is easy to articulate and straightforward to fix. The client who has nothing is starting from zero, and that is actually the cleanest starting point because there are no assumptions to undo.

The question also sidesteps the hype problem. Many SMB owners feel pressure to adopt AI but are not sure where to start. Asking about governance reframes the conversation from "what AI tools should we use" to "what guardrails do we need first." That shift puts you in the role of a trusted advisor rather than a vendor pushing products.

What Does an AI Acceptable Use Policy Actually Cover?

An acceptable use policy for AI is not a general IT acceptable use policy with a paragraph added at the bottom. It needs to address a distinct set of risks specific to how AI tools process, store, and transmit information.

At minimum, a solid policy covers four areas:

Approved and prohibited tools. Define which AI tools employees may use and which are explicitly off limits.
Data input boundaries. Specify what categories of data are permitted inside AI systems and what is not, including customer PII, financial records, and proprietary business information.
Output handling. Establish how employees should treat AI-generated content before acting on it or sharing it externally.
Accountability. Identify who owns AI governance and what the reporting process looks like when someone encounters a problem or makes a mistake.

For SMB clients, you do not need a 30-page document. A one-to-two page policy that employees can actually read and remember is more effective than a comprehensive framework sitting in a shared drive untouched. The goal is behavioral change, not documentation for its own sake.

How Does the Policy Surface Shadow AI Risk?

Shadow AI is the MSP equivalent of shadow IT, and it is growing faster. Employees are adopting AI tools at a rate that outpaces any formal procurement or security review process. The risk is not hypothetical. Customer data entered into a public AI tool may be used for model training, stored on servers outside your client's jurisdiction, or exposed if that vendor has a breach.

When you ask about an acceptable use policy and find that one does not exist, your next move is a short discovery conversation about what tools employees are currently using. Frame it as inventory, not interrogation. You are trying to understand the current state so you can build appropriate guardrails.

What you are looking for is any tool that processes business data outside the approved technology stack. That includes AI features embedded in consumer applications, browser extensions with AI functionality, and standalone tools employees signed up for with personal email addresses. Each of these represents an unmanaged data pathway, and the acceptable use policy gives you the authority to address it.

Connecting the Policy to a Broader Governance Conversation

The acceptable use policy is not the destination. It is the door. Once you have established that a client needs governance around AI, you have a natural opening to discuss the full picture of what responsible AI adoption looks like at the organizational level.

That conversation typically moves in three directions:

Data classification. Most SMBs have never done this formally, but it becomes essential once AI tools are in play. You cannot define what data is safe to use in AI without first knowing what data you have and how sensitive it is.
Vendor assessment. This is the process for evaluating AI tools before they are adopted rather than after.
Incident response. This addresses what happens when an employee uses an AI tool inappropriately or when a vendor has a security event.

None of this requires your client to have a dedicated IT security team. It requires clear ownership, written guidance, and a relationship with an MSP who knows how to implement controls that fit an SMB environment. That is the value you are offering.

Making This a Repeatable Process Across Your Client Base

The clients who ask you for help with AI governance this year will be ahead of the ones who do not. But to make that work at scale, you need a process that does not depend on one person remembering to ask the right questions.

Start by adding the acceptable use policy question to your standard client assessment or QBR template. Make it a required field, not an optional discussion item. This creates a consistent baseline across your entire book of business and surfaces gaps you might otherwise miss with clients who are not actively raising AI concerns.

From there, build a tiered response:

Clients with no policy get a policy development engagement.
Clients with a policy but no enforcement mechanism get a governance audit.
Clients with documented, enforced governance get an AI readiness assessment for deeper integration work.

This gives your team a clear path forward for every client type without starting from scratch each time.

Document your findings in your PSA or wherever you track client risk profiles. AI governance is not a one-time project. It evolves as tools change and as clients grow, and you need a record of where each client stands so you can have an informed conversation six months from now.

The AI acceptable use policy is one of the most efficient tools an MSP has for starting a productive client conversation about AI. It is specific enough to be actionable, broad enough to open the full governance dialogue, and grounded in a real risk that clients can understand without needing a technical background. Every client conversation about AI should start here.

If you want a structured methodology for building these governance conversations into a repeatable client engagement model, the MAGIC Framework gives you the controls-first approach that makes that possible at scale.

Shadow AI in SaaS Apps: MSP Client Governance Guide

Wed, 15 Jul 2026 04:00:10 GMT

Your client has a policy: no AI. No ChatGPT, no Copilot, no generative tools of any kind. You documented it, they signed off on it, and everyone moved on. The problem is that policy was out of date the moment the ink dried.

AI did not wait for an invitation. It arrived through the SaaS tools your clients already pay for, embedded in the productivity suites they use every day, tucked inside browser assistants and CRM update prompts and customer support widgets. Notion is summarizing notes. Salesforce is drafting emails. Zoom is transcribing and analyzing calls. None of this required a purchase order or an IT ticket. It just showed up.

This is the shadow AI problem, and it puts MSPs in a genuinely difficult position. You cannot enforce a policy against something your clients cannot see. And if you are not actively tracking which SaaS tools have AI features enabled by default, what data those features train on, and whether admins can actually turn them off, you are governing a gap you have not yet mapped.

Why a "No AI" Policy Is No Longer Enforceable

There was a time when blocking AI meant blocking a handful of consumer tools. You could put ChatGPT on a deny list, restrict certain browser extensions, and call it a governance posture. That approach is functionally broken now.

Major SaaS vendors have spent the last two years embedding AI capabilities directly into their core products. Microsoft 365 Copilot, Google Workspace's Duet AI, HubSpot's AI content tools, Zendesk's intelligent triage, Intercom's AI agent features. These are not add-ons your clients opted into consciously. Many are enabled by default with existing licensing tiers, or rolled out through product updates that do not require administrator approval.

When AI is a feature of a tool your client already uses and trusts, the psychology shifts. Employees do not think of themselves as violating policy when they click a button that was already there. They think they are just using the software. A blanket prohibition does not account for this reality, and it does not give your clients any guidance about which risks are actually worth worrying about.

The practical result is that a "no AI" policy creates a false sense of security. Clients believe they are protected. You believe the policy is being followed. Meanwhile, AI is operating across their stack, possibly training on client data, customer communications, or regulated information, and no one is watching.

What Shadow AI in SaaS Actually Looks Like

Shadow AI is not always someone sneaking ChatGPT past the firewall. In most MSP client environments right now, shadow AI looks like this:

A project management tool auto-generating task summaries using content from project files
A customer success platform using conversation data to train its own AI models, with that behavior enabled by default
A browser with a built-in AI assistant that can read and summarize the contents of any page the user visits, including internal tools
A recruiting platform using AI to score candidates based on historical hiring data that may contain protected class information
A video conferencing tool storing AI-generated transcripts and meeting intelligence in a vendor-managed environment

None of these require a separate AI purchase. All of them involve data leaving the client's direct control in some form. Some of them have administrator controls that can limit or disable the behavior. Many do not.

The challenge is that this picture looks different for every SaaS application in your clients' stacks. There is no universal AI governance setting. Every vendor makes different choices about defaults, data usage, training consent, and administrative control.

The Governance Gap MSPs Need to Close

If you accept that shadow AI is already present in your clients' environments, the question shifts from "how do we prevent AI" to "how do we govern AI that is already here.

That governance work has four components:

Visibility. You need to know which SaaS tools in your clients' stacks have AI features, which are enabled by default, and which involve data processing that may affect compliance posture. You cannot make good decisions without this inventory.
Data behavior mapping. For each AI-enabled feature, you need to understand what data it processes, where that data goes, whether the vendor trains on it, and what the data retention posture looks like. This is especially critical for clients in regulated industries like healthcare, finance, or legal services.
Administrative control assessment. Many SaaS vendors offer administrator controls that let you disable AI features, opt out of data training, or restrict feature access to specific user groups. You need to know which tools offer these controls and whether they are currently configured correctly.
Policy alignment. Once you have visibility into what AI is actually doing, you can help clients build policies that reflect reality: which AI uses are acceptable, which require review, and which are genuinely off-limits given their regulatory environment.

This is not a one-time audit. SaaS vendors are shipping AI features continuously. The governance posture you establish today needs a mechanism to stay current as the landscape changes.

How MSPs Can Build a Scalable AI Governance Practice

The opportunity here is real. Most of your clients do not have the internal expertise to evaluate AI risk across their SaaS stacks on their own. They are not reading vendor documentation about model training terms or checking release notes for AI feature rollouts. That is work they need help with, and it is work MSPs are positioned to do.

Building a scalable AI governance practice starts with standardizing your own methodology. That means having a consistent framework for evaluating AI features in SaaS applications, a reference source for vendor AI behavior, and a way to communicate findings to clients in terms they can act on.

The MSPs who will do this well are the ones who treat AI governance as a service offering rather than a one-off conversation. That means incorporating AI feature review into onboarding assessments, adding it to your regular security and compliance touchpoints, and creating the documentation that lets clients see their actual exposure.

It also means being honest with clients about what is controllable and what is not. Some AI features cannot be disabled. Some vendor data practices are non-negotiable. Part of your value is helping clients understand where the real risk sits and make informed decisions about which tools they continue to use.

Conclusion

The clients who asked you to keep AI out of their environments were not wrong to have concerns. Those concerns are legitimate, and they deserve a real response. The response that actually protects them is not a blanket prohibition that gets bypassed by every SaaS product update. It is a governance posture that accounts for the AI that is already there.

Your role as their MSP is to give them an accurate picture of their current exposure and a practical path to managing it. That work starts with knowing what AI is doing inside the tools they already use, and that requires a systematic way to track vendor AI behavior across a client's full SaaS stack.

Atlas is Lemhi's reference database for exactly that work. It documents the AI posture of 176-plus SaaS applications in plain English: whether the tool trains on your data by default, whether admins can disable it, whether an opt-out exists. Before a client asks what their software has been doing with their data, you should already know the answer. Atlas is free and open.

How to Position Your MSP as a Trusted AI Advisor to Clients

Fri, 10 Jul 2026 13:36:25 GMT

Most MSPs have spent years proving their value through uptime, response times, and ticket resolution. That track record matters, but it also has a ceiling. When a client's CFO starts asking about AI strategy, the break-fix reputation does not follow you into that conversation.

The good news is that you do not need to become a healthcare AI specialist or a logistics automation expert to lead meaningful AI conversations with your clients. There is a category of AI applications that cuts across every industry, every department, and every organization size. These horizontal use cases are your entry point, and they are more powerful than most MSPs realize.

This post walks through how to use those universal applications to shift your positioning from infrastructure vendor to transformation advisor, and what that shift actually looks like in practice.

The "I Don't Know Their Industry" Barrier Is a Mirage

The most common reason MSPs hold back from AI conversations is a fear of overstepping. You manage their endpoints and their backups. Who are you to tell a law firm or a dental group how to transform their business with AI?

That hesitation is understandable, but it is based on a false premise. AI transformation is not primarily a vertical problem. The same fundamental challenges appear in every organization: employees spend too much time finding information, finance teams manually reconcile data, HR departments answer the same policy questions hundreds of times a year, and legal or compliance reviews create bottlenecks that slow everything down.

These are not healthcare problems or manufacturing problems. They are organizational problems. And because you work with dozens of organizations across multiple industries, you have actually seen these patterns more consistently than any single-industry consultant ever could. That cross-client visibility is an asset you are likely undervaluing.

Three Horizontal Use Cases That Open Boardroom Doors

You do not need a catalog of fifty AI applications. You need two or three that are immediately recognizable to a non-technical executive, that produce measurable results quickly, and that naturally lead to bigger strategic conversations. These three fit that criteria.

HR Policy Bots

Every organization with more than twenty employees has the same problem: HR staff spend a significant portion of their week answering questions that are already documented somewhere. PTO policies, benefits eligibility, onboarding requirements, expense reimbursement rules. These questions are repetitive, low-complexity, and interruptive.

An HR policy bot, trained on the company's existing documentation, can handle the majority of these queries without human involvement. Employees get faster answers. HR staff reclaim hours. And the organization has a concrete, visible example of AI delivering operational value.

This is a low-risk first deployment. The data is not sensitive in the same way as financial records. The workflow is contained. And the ROI is simple to calculate and easy for any executive to understand.

Finance Automation

Accounts payable processing, invoice matching, expense report review, and month-end reconciliation are all candidates for AI-assisted automation. These processes are rule-based enough for AI to handle reliably, but they currently consume significant human time in almost every organization.

When you bring this use case to a CFO, you are speaking their language immediately. You are not talking about technology for technology's sake. You are talking about reducing error rates, accelerating close cycles, and redeploying finance staff toward higher-value analysis work. That is a conversation that earns attention.

Legal and Compliance Summarization

Contract review, regulatory update monitoring, and policy compliance checking are time-consuming tasks that often bottleneck entire business functions. AI can summarize lengthy documents, flag clauses that deviate from standard terms, and monitor for changes in relevant regulations.

For clients in regulated industries, this use case has particular resonance. But it is equally relevant to any organization that deals with vendor contracts, customer agreements, or internal policy governance. You do not need to be a legal expert to identify that this problem exists and to introduce tools that address it.

How to Structure the Consultative Conversation

Bringing these use cases to a client is not about pitching software. It is about opening a diagnostic conversation. The framing matters as much as the content.

Start with a question, not a presentation. "Where does your team spend time on work that feels repetitive or manual?" is a better opening than "We have an AI solution for HR." The first invites your client to surface their own pain. The second positions you as a vendor with something to sell.

Once you have identified two or three areas of friction, you can map specific use cases to those pain points. At this stage, you are functioning as a consultant, not a salesperson. You are helping them see a problem they already have through a new lens.

The goal of this first conversation is not to close a deal. It is to establish that you are capable of having this kind of strategic discussion at all. That alone changes how you are perceived. When the next AI-related decision comes up, you want to be the first call they make, not a vendor they remember after they have already committed to a direction.

Building Repeatable Packages Around Horizontal Use Cases

Once you have delivered one or two of these use cases successfully, the next step is systematizing them. That means building documented delivery processes, defined scope boundaries, pricing structures, and outcome metrics that you can replicate across your client base.

This is where MSPs have a structural advantage over one-off consultants. You can invest in building a solid HR bot deployment framework once, then deliver it to ten clients with incremental effort. The economics improve with each engagement, and your team gets faster and more confident with every iteration.

Packaging also changes the sales conversation. Instead of custom-scoping every engagement from scratch, you can present a defined service with a clear outcome. That reduces buying friction, makes pricing more predictable for clients, and positions your offering as something proven rather than experimental.

As you accumulate delivery experience across multiple client environments, you also accumulate insight. You start to see what works in different organizational contexts, what objections come up, and what success looks like at different stages. That institutional knowledge becomes a competitive moat that no competitor can easily replicate.

From Project Vendor to Strategic Partner

The shift from break-fix vendor to trusted advisor does not happen through a single conversation or a single project. It happens through a pattern of engagements that consistently demonstrate strategic value, not just technical execution.

Horizontal AI use cases are the mechanism for starting that pattern. They give you a credible reason to be in rooms you would not otherwise enter. They produce visible results that create internal advocates for your work. And they open the door to deeper conversations about where AI fits into the client's broader business strategy.

Over time, clients who started with an HR bot or a finance automation project will start looping you into technology decisions earlier. They will ask for your perspective on AI vendor claims they encounter. They will want you in the room when they are planning for the next year. That is what trusted advisor status actually looks like, and horizontal use cases are one of the most reliable paths to getting there.

Conclusion

The path to the client boardroom does not require you to become an industry specialist overnight. It requires you to show up with a point of view that connects technology to business outcomes, and horizontal AI use cases give you exactly that. HR bots, finance automation, and legal summarization are not niche applications. They are universal problems with proven solutions, and you are well-positioned to deliver them.

The MSPs who will earn trusted advisor status are the ones who start these conversations now, build repeatable delivery around them, and compound that experience into genuine strategic credibility over time.

MIP Isn't a Transformation. It's a Line of Business. Here's Why That Matters.

Fri, 10 Jul 2026 04:00:04 GMT

The MIP Debate Is Creating the Wrong Kind of Anxiety

A new acronym is moving through the MSP channel: MIP. Managed Intelligence Provider. Pax8 formalized the concept in 2025 with a report titled "The Agentic Inflection Point: And the Rise of the Managed Intelligence Provider," framing MIP as the third tier in the MSP evolution arc. MSP for uptime. MSSP for risk. MIP for outcomes and AI-driven automation.

The framing is useful. The reaction it's generating in some corners of the channel is not.

"From MSP to MIP" is showing up as a headline construct across dozens of MSP blogs, and the implication is clear: this is an identity shift. A transformation. Something you have to become, not just something you have to do. That framing is generating the same anxiety that preceded every prior technology wave: the feeling that the existing business is being left behind, that a new identity is required to participate.

It isn't. MIP is a service category, not a company type.

The way Alex frames this with MSP owners is direct: MIP is not a transformation you go through, it's a capability you add. Lemhi doesn't treat MIP as a brand state. It treats it as a service surface. If you have a repeatable motion for helping clients adopt, govern, and operate AI, you are functionally delivering what Pax8 calls MIP. Whether you use the acronym or not is irrelevant.

The anxiety Alex hears consistently from MSP owners runs something like this: "Are we behind? Do we need to reposition the company? Are we going to look outdated if we're not calling ourselves an AI partner?" That's the wrong frame. The correction lands fast: "Your clients aren't asking if you're a MIP. They're asking if you can help them not screw this up."

Lemhi's working definition is clean: MIP is the delivery of AI as a managed service, using the same operating model MSPs already run. Standardized inputs. Defined outputs. Recurring oversight. The mistake is thinking it's a category you have to become instead of a lane you have to build.

What MSPs Actually Did With Cloud and Cyber

The MSP channel has been through this exact movie before. When cybersecurity became a distinct discipline, the conversation was about whether MSPs needed to become MSSPs. Some did. Most didn't. Most extended their service catalogs with security capabilities: EDR, email security, SOC monitoring through white-label partners, security assessments. The line between MSP and MSSP blurred because clients preferred a single partner who handled both. The MSPs who thrived built the capability without necessarily rebuilding the brand.

Same pattern in cloud. When Microsoft pushed Office 365 and Azure, the conversation wasn't "do we become a Managed Cloud Provider?" It was "how do we make cloud services part of what we already deliver?" The practices that emerged from that shift: M365 migration, cloud management, Azure governance. All became lines of business within existing MSP firms, not new companies.

The operational logic in both cases was identical: identify a technology category clients need help with, build a repeatable service around it, package it, price it, and deliver it consistently. The company didn't transform. The service catalog expanded.

What Alex observed during those transitions was a clear split. The MSPs that came out ahead didn't lead with "we're now a cloud company" or "we're now a security company." They built the work first. Migrations, governance, monitoring. The brand followed the delivery, not the other way around.

The ones that struggled got ahead of themselves on positioning. They updated the website, changed the pitch, talked about new capabilities, but were still figuring out the delivery engagement by engagement. That inconsistency surfaces in client conversations immediately.

The mapping to the current MIP debate is direct: MSPs who extend their service catalog with AI and build a clean, repeatable motion will look like MIPs in the market whether they say it or not. The ones who try to rebrand first are recreating the mistake from the security wave: signaling capability before they actually have it.

What MIP Actually Means at the Operational Level

Strip away the branding and the Pax8 report and here's what a Managed Intelligence Provider actually is, operationally: an MSP that delivers AI services through the managed services model. Packaged. Recurring. Standardized. Outcome-focused.

That's it. The "intelligence" part refers to the technology category: AI governance, Copilot deployment, policy management, usage monitoring, readiness assessments. The "managed provider" part is identical to what MSPs already do. Same delivery model. New technology category.

One channel definition puts it clearly: "A managed intelligence provider helps businesses integrate AI tools and provides ongoing support, to ensure safe and optimized deployment and maximum return on investment." That's an M365 migration practice description with "AI tools" swapped in for "email platform." The operational structure is indistinguishable.

If you already deliver managed services with standardized processes, consistent delivery, recurring client relationships, and a proactive rather than reactive posture, you already have the operational model for MIP. You don't need to acquire a new one. You need to point the existing one at a new technology category.

Inside Lemhi, this isn't called MIP. It's an AI line-of-business build. That's intentional. Partners don't need a new category definition. They need a service they can sell, deliver, and scale.

The service stack looks like this:

AI usage assessment: what's happening today, where the risk is sitting
Acceptable Use Policy mapped to actual workflows
Approved tool stack, almost always anchored in Copilot
Technical controls: Purview, SharePoint permissions, access boundaries
Ongoing governance: usage review, policy updates, client enablement

That is the operational definition. An MSP that can deliver those five things in a repeatable way is delivering what the MIP concept describes.

The difference from Pax8's framing is tone and application. Pax8 defines the category. Lemhi operationalizes it. Less "become a managed intelligence provider," more "here's the exact service you can run starting next quarter."

The Difference Between AI Projects and AI Lines of Business

Most MSPs who are "doing AI" right now are doing AI projects. Implementing Copilot for a specific client. Helping a business automate a specific workflow. Running a one-time AI readiness assessment. These are real engagements, and they generate real revenue, but they generate it once. The engagement ends when the project ends. That's consulting, not a service line.

A line of business looks different. It has a standardized set of deliverables, a recurring delivery cadence, a consistent price point, and staff who can execute it the same way for every client. In the AI context: a packaged AI assessment with a defined scope and output, followed by an AUP and tool stack implementation, followed by a recurring governance retainer that includes monthly usage monitoring, quarterly policy reviews, and policy updates as new tools emerge. The client relationship doesn't end. It converts to a managed service.

The distinction maps directly to what channel observers are already noting: "MSPs are failing at monetization standardization rather than AI capability." Most MSPs who want to deliver AI services already have the technical knowledge. What they haven't done is package that knowledge into a repeatable, scalable offering with defined pricing and a consistent delivery process. That's the gap between a practice and a line of business.

The recurring model isn't just better for revenue. It's better for the client. AI governance isn't a one-time event. Tools change, policies need updating, usage evolves. A client who gets an AI assessment and nothing afterward has governance that's out of date in six months. A client on a recurring AI governance retainer has a practice that stays current. The service model matches the nature of the problem.

A productized AI line of business in Lemhi's framework starts with a fixed-scope assessment, typically priced and sold as a standalone entry point, where the MSP surfaces AI usage, risks, and gaps. That rolls immediately into a defined implementation package: AUP, tool standardization, and governance setup.

The shift happens after that. Instead of stopping, the MSP converts the client into a governance retainer. Monthly or quarterly cadence. Review usage. Update policy. Adjust tool access. Enable new use cases. That is the line of business: the ongoing system, not the initial project.

The difference between consulting and a line of business shows up clearly in sales. In consulting, every deal is scoped from scratch. In a line of business, the MSP can answer before the conversation starts: "Here's our AI package. Here's what's included. Here's what it costs." No reinvention per client. That's what makes margin hold.

Lemhi is already seeing partners make this shift. The pattern is consistent: they start with two or three project-based engagements, realize they're re-solving the same problem every time, then standardize into a single offer with a follow-on retainer. That's the transition point where AI stops being interesting and starts being revenue.

Why the Rebrand Temptation Is a Trap

There's a version of the MIP conversation that goes: announce the pivot, update the website, tell clients you're now an AI company, then figure out the service delivery. That's the trap.

The managed services history is full of cautionary examples. MSPs who rebranded as security companies before they had a real security practice created client expectations they couldn't meet. When a breach happened and the MSP couldn't respond at the level a "security company" should, the trust damage was worse than if they'd never claimed the identity in the first place. Clients expected more, not less, from a company that had made security its brand.

The same risk exists in AI. An MSP that announces it's a Managed Intelligence Provider before it has a packaged, repeatable AI service offering is setting a bar it will struggle to clear. The client who hears "we are the AI partner for your business" expects AI expertise at every touchpoint. When the delivery is still being figured out, the gap between positioning and reality erodes exactly the trust the rebrand was trying to build.

Alex has seen this play out, not in a dramatic overnight way, but in a slow erosion of credibility. An MSP positions themselves as "leading AI transformation," gets pulled into a client conversation, and is still working through basics like policy, tool choice, or governance boundaries in real time. The gap between what was claimed and what can be delivered surfaces immediately.

Lemhi's guidance to partners is direct: do not lead with positioning you can't consistently deliver against. Build the first three engagements. Document what worked. Turn that into a repeatable process. Then talk about it. That sequencing protects both the client and the MSP.

The internal principle: capability before claim. If you can't run the same process three times in a row, you don't have a service yet. And if you don't have a service yet, you don't have anything to brand.

What "build before you brand" looks like in practice is deliberately unglamorous: define the assessment, build the AUP template, document the control setup, run a few clients through it, tighten it, then package it. No announcement required. Better delivery is the announcement.

What the Line-of-Business Motion Actually Looks Like

Building an AI line of business is not starting from scratch. The frameworks are already defined. The Pax8 MIP playbook exists. The Microsoft Copilot deployment guidance is documented. The AI governance framework is fully mappable from day one: assessment, AUP, tool stack, technical controls, ongoing review.

The actual work of standing up an AI line of business for an MSP looks like this: define the assessment deliverable (what does the client get, what does it include, what does it cost), build the AUP template (not custom per client, but a documented baseline that gets tuned per engagement), configure the technical controls package (Purview labels, DLP policies, SharePoint governance), define the recurring governance retainer (monthly or quarterly, what's included, what's the cadence), and train the delivery staff (consistent execution, not ad-hoc per engagement).

The operational disciplines are identical to what made managed services work in the first place: scope it clearly, price it simply, deliver it the same way every time. MIP is not a new operational model. It's the existing one applied to a new category.

For an MSP starting from scratch, Lemhi's guidance is specific. Three steps:

Define and sell a single AI assessment offering. Scope, output, price. This is the entry point. Don't skip to governance retainers until clients have gone through it.
Build a baseline AUP and governance recommendation you can apply across clients, not a custom document for each engagement.
Package the follow-on governance retainer before you need it. Have the pricing, scope, and delivery cadence defined before the first assessment converts.

That's enough to start. No full AI practice required on day one. Just a repeatable entry point and a clear next step.

The timeline is shorter than most MSPs expect. Lemhi has seen partners go from "we should probably figure this out" to a defined, priced offering in a matter of weeks once they stop overengineering it. The bottleneck is almost never technical. It's packaging and confidence.

What Lemhi provides in that process is structure: the assessment framework, AUP templates, governance model, and positioning guidance. The goal is to get MSP partners to "we can deliver this consistently" as quickly as possible. Because that's the real milestone: not understanding AI, but being able to run it as a business.

You Don't Need a New Name

The MSPs that built the strongest managed services practices didn't lead with "we're now a managed services provider." They led with what they were doing differently for clients. The same MSPs that added cloud practices didn't become cloud companies. The ones that built security practices didn't all become MSSPs.

MIP is a useful concept. It captures something real about what the AI service category requires: proactive management, AI-driven automation, ongoing governance, client outcomes over ticket counts. That's what the market is moving toward. But it describes what you deliver, not what you are.

Build the service. Price the service. Deliver the service. You don't need a new name to do any of it. You need the same thing that built every prior practice: operational discipline, a repeatable model, and the willingness to start before it's comfortable.

Should Tier-One Technicians Fear AI? Honest Take From MSP Veterans

Wed, 08 Jul 2026 04:00:12 GMT

The Honest Answer

The question comes up in every room right now. Tier-one technicians, help desk staff, early-career MSP folks — they're watching the AI conversation and wondering where they fit in it. The anxiety is understandable. And anyone who tells you it's not a real question isn't being straight with you.

Here's the honest answer from someone who has watched this pattern play out three times in 30 years of MSP work: the technology isn't the threat. The refusal to adapt to it is.

No, AI is not coming for every tier-one job. It is coming for the part of the job that never grows. The technicians who treat AI like the next layer of the stack — something to learn, govern, and configure — are going to do well. The ones who stay parked in repetitive work and call that job security are the ones who should be nervous.

Andy Banning has said it the same way in conversations with MSP partners: keep learning, lean into governance and policy, and remember that cloud made things more complex, not less. The tone is pragmatic, not soft. He is not pretending the repetitive part of tier-one work is safe forever. The instinct is blunt: governance is step 1. If you can help your MSP understand permissions, readiness, policy, and rollout risk before everyone gets turned loose on AI, you are already moving out of the replaceable zone.

They Said the Same Thing About Exchange Admins

In June 2011, Microsoft launched Office 365 and bundled Exchange Online with it. If you were an Exchange administrator at the time, you heard a version of the same fear technicians are expressing today: "Microsoft is going to host their own email. Why would anyone pay us to manage it?"

The fear made sense in the moment. Exchange admins had spent years building expertise in on-premises mail infrastructure. Now Microsoft was offering to run it in the cloud, directly. On the surface, the skill set looked obsolete.

What actually happened: the admins who learned cloud migration, hybrid Exchange configurations, and eventually M365 governance became more valuable than they had been in the on-prem era. The hiring demand for cloud skills grew at six times the rate of IT skills overall through the transition period. The ones who didn't adapt didn't get replaced by Microsoft. They got replaced by other technicians who moved faster.

What separated the Exchange admins who stayed valuable from the ones who got squeezed was not deeper attachment to Exchange. It was willingness to move one layer up. Cloud shifted the work from keeping one server healthy to handling migration, enablement, permissions, governance, and the user change management around it. During the server-to-cloud transition, MSPs started adding professional-services capability around the technical core instead of treating the old infrastructure lane as the whole job.

That is the map for AI. The question MSPs ask most often right now is about Copilot enablement and Microsoft consumption. The technician who learns the new admin surface becomes more useful. The one who waits for the old surface to matter again gets boxed in.

And Before That, Break-Fix Technicians

Before the Exchange admin anxiety, there was the break-fix transition. When managed services emerged in the mid-2000s, break-fix technicians had a version of the same concern. If the job is to fix things when they break, what happens to that job when things stop breaking as often because the MSP is preventing problems proactively?

The answer, again, was that the technology created more complexity, not less. The break-fix technicians who moved into managed services learned to think preventively: monitoring, patch management, standardized configurations, documentation. That required more skill and more judgment than reactive hourly work, not less. The ones who made the shift became the backbone of the early MSP model. The ones who didn't found themselves on the wrong side of a market that had moved on.

The break-fix technicians who made the jump were the ones who stopped seeing value as "I can fix it fast" and started seeing value as "I can stop it from breaking in the first place." That is a mindset shift before it is a tooling shift. The old model was infrastructure custodian work. The next model required becoming a business enabler rather than the person who just said no. That posture change is exactly what tier-one techs need to make right now.

The people who struggled in that era had the same issue techs face today with AI: they were excellent inside the current queue, but they didn't want to learn the adjacent discipline. Managed services rewarded documentation, standardization, monitoring, and change control. AI is going to reward readiness assessment, policy, permissions, rollout discipline, and practical enablement. Different tools, same career pattern.

The Pattern Is Always the Same

Two transitions, same arc. A technology shift creates a fear response. The fear is that the new technology will eliminate the need for the technician. What actually happens: the technology creates new complexity, new service categories, and new demand for people who understand it, while reducing demand for people who only know how to do the thing the technology has taken over.

The data from the current AI transition confirms the same arc is running again. Help desk job postings have declined 36% since 2020 as AI-driven tools automate routine tasks. Simultaneously, CompTIA reports that AI skill requirements in job postings nearly doubled in a single year: from just over 5% of postings in 2024 to over 9% in 2025. More than 275,000 active U.S. job postings in January 2026 specifically referenced AI skills.

The overall tech workforce is projected to grow by 1.9% in 2026, adding nearly 185,500 new jobs. The net employment picture in tech has always gone up through these transitions. What shifts is which skills are doing the growing.

The cloud transition created the cloud architect, the cloud engineer, the cloud security specialist: roles that didn't exist in the on-prem era. The cyber transition expanded security operations roles by an order of magnitude. AI is creating demand for AI governance administrators, Copilot deployment specialists, and policy configuration technicians. These roles didn't exist three years ago. They're in job postings now.

What Actually Gets Replaced (And What Doesn't)

The 70% figure is worth looking at directly. Gartner estimates that roughly 70% of tier-one IT tickets are theoretically automatable by AI. If you're a tier-one technician, that number deserves a straight read: a meaningful share of what you do today can be handled by an AI ticketing tool.

Password resets. Basic connectivity troubleshooting. Standard ticket routing. Status updates. Software access requests. These are the tasks at the bottom of most tier-one queues, and AI tools are already handling them in environments that have deployed them.

The honest framing isn't "AI can't do your job." It's "AI is doing the lowest-context part of your job. What are you doing with the time that frees up?"

The technicians who are in trouble are the ones whose entire job is in that automatable zone and who aren't actively building skills above it. The technicians who are well-positioned are the ones using the automation to move up the stack: to the configuration, governance, troubleshooting, and client advisory work that requires judgment and context.

And there's a new category of work that didn't exist before AI that a tier-one technician can own right now: managing the AI tools themselves. Configuring Copilot for an SMB client. Running a readiness assessment in SharePoint before a Copilot deployment. Governing which scenarios are enabled and which data sources are accessible. Reviewing Purview AI Observability reports and flagging policy drift. Microsoft has released a dedicated certification for this work: the Microsoft 365 Copilot and Agent Administration Fundamentals exam (AB-900). This is a tier-one growth path. It's accessible, it's in-demand, and every MSP deploying Copilot needs someone who can do it.

The first category of tier-one work that AI will touch is the repetitive assistance layer: common IT questions, routine fixes, first-pass documentation, and alert summarization. Lemhi's own AI use-case library calls out an AI help desk assistant for common questions and routine fixes, AI-generated technical documentation, and AI summaries for alert and log review. That is the work you should expect to shrink first.

The growth path above it is concrete. Start by learning the control plane for M365 Copilot: Exchange Online, SharePoint, Teams, Entra, Purview, and Copilot governance. Lemhi has already started pushing for a lightweight Microsoft Copilot certification track to help technicians get there. That lines up with how Andy Banning is already working in the field: readiness checklists, governance-first reviews, and structured interviews to make sure clients don't run into snags before AI enablement begins.

The Technicians Who Should Be Paying Attention

Not every tier-one technician's situation is identical. The ones with the most exposure are those whose work is almost entirely in the repetitive-task tier and who haven't started building new skills. If every day looks like password resets and basic connectivity calls, and there's been no movement toward learning how the tools actually work under the hood, the pressure is real.

The ones in the best position are the curious ones. The technicians who want to know how AI ticketing works, why Copilot needs a SharePoint oversharing assessment before deployment, what the Copilot Control System actually does. Curiosity is the skill that survives every transition. It's what turns the Exchange admin who was afraid of Office 365 into the M365 architect who manages it for a hundred clients.

The specific ask for any tier-one technician reading this: get hands-on with the tools. Understand what Copilot can and can't do. Take the AB-900 exam. Position yourself as the person in the MSP who manages AI for clients, not the one whose tasks AI manages. The MSPs building Copilot deployment practices right now are creating demand for exactly that technician.

If you're anxious, don't start by arguing with the future. Start by volunteering for the messy work everyone else avoids. Learn how to spot overshared SharePoint data. Learn how an AI use policy actually gets rolled out. Learn how to run a basic readiness checklist and explain why data sitting on a local NTFS share is a blocker if the client wants AI search over company knowledge.

The first concrete step: get hands-on with Copilot in a governed Microsoft environment, then study the admin side until you can explain what the user sees, what the admin controls, and where the risks come from. After that, take the AB-900 path and become the person in your shop who can help with readiness checks, policy rollout, and basic Copilot governance. That is a much better bet than trying to protect a queue full of password resets.

The Shift Is Already Happening

The Exchange admins who thrived weren't the ones who waited to see how Office 365 played out. The break-fix techs who built careers through managed services weren't the ones who held on to reactive hourly work until clients stopped calling.

Every transition in this industry has rewarded the same thing: the willingness to get curious before you're forced to, and to build the next skill set while the window is still open.

That window is open right now for AI. The technician who understands governance configuration, policy management, and Copilot administration is the one MSPs are hiring for. The demand is already there. The certification path exists. The clients are asking for the service.

The only thing left is deciding to be the technician who manages AI, not the one who waits to find out if AI manages them.

The Safest AI Bet for MSP Clients Isn't the Flashiest One. It's Copilot.

Mon, 06 Jul 2026 04:00:07 GMT

The Wrong Question MSPs Are Asking

There's a version of the MSP AI conversation that goes sideways fast: which model scores best on benchmarks, which tool has the most impressive demo, which startup just raised the biggest round. Those are real questions. They're just not the right ones for a client-facing MSP advising an SMB on where to put their AI eggs.

The right questions are different. Which AI recommendation creates the least long-term risk for the client? Which one can the MSP actually govern? Which one doesn't require a new vendor relationship, new compliance documentation, or a new explanation when the terms change in six months?

On those questions, Microsoft Copilot wins. Not because it has the most impressive model, but because it's the most defensible recommendation an MSP can make. Here's why.

The Data Is Already There

The most underrated argument for Copilot is also the most obvious once you say it out loud.

An SMB's business data already lives in Microsoft 365. Email. Calendar. Teams conversations and meeting recordings. SharePoint documents. OneDrive files. That's not a peripheral slice of the business. That's the operating record of the company. When an employee asks a generic LLM "what did we agree to in the contract with Acme?" the LLM doesn't know. It starts cold, with no context, and the user has to paste in documents, summarize threads, and reconstruct context manually.

Copilot starts with all of it. It uses Microsoft Graph to surface content the signed-in user already has permission to access. It can pull the email thread, find the contract in SharePoint, cross-reference the Teams meeting where the decision was made, and synthesize across all three. This isn't a feature difference from a generic LLM. It's a structural difference. The SMB doesn't need to feed the AI their business context, because Copilot already operates inside it.

The governance piece reinforces the data argument. Copilot respects every existing SharePoint permission and role-based control. If a user can't access a document normally, Copilot can't surface it. The permission architecture the MSP already manages is the same architecture that governs what Copilot can and can't touch.

When a client says "why not just use ChatGPT?" the answer that lands isn't technical. It's operational. What we train MSPs to say is: "You can use ChatGPT. But every time your team wants it to be useful, they have to paste your business into it." That reframes the conversation immediately. You're not comparing models. You're comparing where your company's data lives and how it moves.

The analogy that consistently works: ChatGPT is a blank whiteboard. Copilot is your company's filing cabinet, already organized by permissions. If an employee wants ChatGPT to answer a question about a client, they have to copy the file, paste it in, and hope they didn't include something sensitive. Copilot starts with the file already in place, showing only what that employee is already allowed to see.

In practice, this is how MSPs position it: "If your team is going to use AI anyway, do you want them constantly moving data into tools you don't control, or do you want the tool to sit where your data already is, under the controls we already manage?" That's usually where the conversation ends.

The Governance Surface Is Already Familiar

MSPs who manage M365 tenants already live in the Microsoft admin center. They provision users, manage licenses, set conditional access policies, configure DLP rules, and run compliance reports. That administrative surface is already their day job.

When an MSP adds Copilot governance to the stack, they're extending existing work, not building something new from scratch. The controls they need are already there. Microsoft Purview, integrated directly into the M365 admin center, is where sensitivity labels get applied, where DLP policies get configured, and where audit logs get reviewed. The Copilot Control System, announced at Microsoft Ignite 2025, gives MSPs a centralized control plane to manage which Copilot scenarios are enabled, which data sources Copilot can access, and how agents are deployed across the tenant. All of it lives in the same admin environment the MSP already operates.

The contrast with governing an outside AI tool makes the argument concrete. If a client wants to use a non-Microsoft LLM at scale, the MSP now has to build governance from scratch: new vendor assessment, new DPA review, new compliance documentation, new audit infrastructure to track usage, new policies to enforce, with no existing admin surface to work from. Every governance decision requires a new process. With Copilot, the process already exists. The MSP is applying existing skills to a new surface, not starting from zero.

Foundational Copilot governance controls are available with the same M365 Business Basic, Standard, or Premium licenses most SMB clients already carry. No new infrastructure purchase required to begin.

The difference in workload is not subtle. When an MSP adds Copilot governance to an environment they already manage, it looks like an extension of existing work: tightening SharePoint permissions, reviewing DLP coverage, applying sensitivity labels, and turning on audit visibility. Same tools, same admin surface, same muscle memory.

When they try to govern an external AI tool, it's a completely different motion. New vendor risk review. New DPA conversation with the client. New policy language. No centralized audit trail unless you build or buy one. And no way to enforce usage consistently across devices. Partners spend more time trying to document governance for a third-party tool than actually helping the client use AI effectively.

The pre-deployment work with Copilot is also very consistent across clients. Lemhi's recommendation runs in a tight sequence: oversharing check in SharePoint, identify broadly permissioned folders, validate sensitivity label coverage on anything client- or employee-facing, review existing DLP rules, then enable Copilot for a limited user group first. Purview does most of the heavy lifting here, especially around labeling and audit visibility, and the Copilot Control System gives MSPs a single place to manage what's actually turned on. It's not "new AI infrastructure." It's finishing the governance work most tenants never fully completed.

The Startup AI Risk MSPs Aren't Talking About

Every AI tool recommendation an MSP makes is a bet on vendor continuity.

In March 2024, Inflection AI (the company behind Pi, an AI assistant with roughly 6 million monthly active users) was effectively dissolved. Microsoft hired the entire founding team and licensed the technology for $650 million. Users who had built workflows around Pi went overnight from a venture-backed company with a clear product roadmap to an organization whose leadership had departed. The service didn't shut down immediately, but the organizational continuity was gone.

Inflection isn't a cautionary tale about a failing startup. It was a well-funded company with serious AI talent. The disruption didn't come from failure. It came from success: the team was valuable enough to get acqui-hired. That's the nature of the AI startup market right now. The most promising companies are also the most likely acquisition targets. And acquisitions at startup speed don't come with 12-month client transition periods.

When an MSP recommends a startup LLM to an SMB client and that tool changes its pricing, pivots to enterprise-only, gets acquired, changes its data handling terms, or disappears, the MSP owns that recommendation. There's no documented governance trail to point to. There's no contractual data residency commitment to cite. There's just a conversation with a client asking why their AI tool doesn't work anymore.

Microsoft's enterprise data commitments for M365 Copilot are contractual and documented. As of March 2024, M365 Copilot was added as a covered workload in Microsoft Product Terms data residency commitments. For EU clients, Copilot is an EU Data Boundary service with specific regional data handling guarantees. These are the kinds of commitments Microsoft has been making to enterprise and SMB customers for two decades. They exist in writing. They can be cited in a compliance conversation.

No VC-backed AI startup has a 20-year track record of making and keeping those commitments at scale.

This is a conversation happening quietly in the channel, but it's real. MSPs are starting to recognize that an AI recommendation isn't just a tool suggestion. It's something their client will build workflow around. And when that tool shifts, the MSP is the one who has to unwind it.

Partners have described situations where a client built lightweight processes around a free or low-cost AI tool, only for the pricing model or access terms to change within months. Nothing catastrophic, but enough friction that the client comes back asking, "Why are we switching again?" That erodes trust quickly, even if the original recommendation was reasonable at the time.

The framing that tends to land with MSPs is simple: "Would you recommend a core line-of-business system from a vendor you're not confident will look the same in 12 months?" AI is moving fast, but client expectations around stability haven't changed. The more embedded the tool becomes in daily work, the more that stability matters, and the more liability sits with whoever recommended it.

What "Copilot as the Anchor" Actually Looks Like in Practice

Recommending Copilot isn't a one-time conversation. It's the foundation of a repeatable service motion.

MSPs access Copilot licensing through the CSP program, the same channel they already use for all M365 licensing, with no new vendor relationship required. The SMB-specific SKU, Microsoft 365 Copilot Business (available December 2025), is priced at $21 per user per month and requires only an existing M365 Business Basic, Standard, or Premium license. The commercial story is straightforward.

The service motion around the license is where the recurring value sits. Before rolling out Copilot, the MSP runs a readiness assessment: identifying overshared files and folders in SharePoint, reviewing existing DLP policies and sensitivity label coverage, and making sure the data governance foundation is solid before Copilot starts surfacing information at scale. Microsoft's Oversharing Blueprint, built on Purview and SharePoint Advanced Management, provides the framework. The pre-deployment readiness work is a billable engagement in its own right.

After deployment, there's ongoing management: monthly usage reviews via Purview AI Observability, policy updates as new Copilot scenarios get enabled, and user training to close the gap between license and adoption. The client who deploys Copilot without the governance layer, and without training, is the client who calls the MSP six months later confused about why it's not delivering value. The MSP who bundles governance and adoption support from day one is the one building a durable service relationship.

This is the monetization model that's working: implementation fee, license margin through CSP, and a recurring managed Copilot governance retainer. Not a one-time product sale. A service.

In practice, the Copilot deployment service that works is tightly structured. It starts with a paid readiness assessment, not optional. That includes SharePoint oversharing review, sensitivity label coverage, DLP baseline, and a quick pass on how teams are actually using data today. The output isn't a report. It's a readiness score and a clear remediation plan.

From there, deployment is phased. Small user group first, governance controls already in place, then expand once usage patterns are understood. The MSP isn't just turning licenses on. They're controlling how Copilot enters the business. That's what separates a deployment from a service.

The failure modes are consistent when MSPs skip this. Copilot surfaces content users technically have access to but shouldn't be using broadly, which triggers internal concern. Or adoption stalls because users don't know how to apply it to their workflows. In both cases, the client comes back questioning the value of the license. Lemhi's framing to partners is direct: "Copilot without governance exposes problems. Copilot with governance becomes a system." The service is making sure it's the second one, and then owning it ongoing through usage reviews, policy refinement, and continuous enablement.

Stability Is a Feature

New AI tools launch every week. The benchmark comparisons are relentless. The demos are always impressive. And every few months there's a new model that's definitively "the best."

SMB owners aren't AI researchers. They're not following the leaderboards. They're trying to run a business, and they're asking their MSP to tell them what to do with AI in a way that won't create new problems faster than it solves old ones. The answer that serves that client is not "whatever is highest on the benchmark this month." It's the answer that's integrated with what they already use, that can be governed with what's already in place, and that will still be there, with the same vendor commitments and the same contractual protections, in two years.

Copilot is that answer. Not because Microsoft is always right, and not because no other AI tool is worth using. But because for the MSP advising an SMB client on where to anchor their AI program, "defensible, governable, and built on what you already have" is a better standard than "most impressive demo." And it's a standard Copilot meets.

AI Absorption vs. AI Adoption: Why Turning Copilot On Isn't the Same as Using It

Fri, 03 Jul 2026 04:00:07 GMT

AI Adoption is the act of turning AI tools on — provisioning licenses, deploying agents, giving employees access. AI Absorption is what Microsoft's 2026 Work Trend Index named the outcome that actually creates value: AI changing how work gets done, not just whether AI tools are present. Adoption is measurable in days. Absorption is measurable in quarters. The distinction is the difference between Copilot license cost and Copilot ROI — and it is the single most important framing shift in SMB AI work today.

How MSPs Drive AI Absorption Instead of Just AI Adoption

For MSPs, the Adoption/Absorption distinction is the language that explains why a Copilot rollout that "succeeded" on the technical side can still produce zero ROI. Adoption is the kickoff. Absorption is the managed service.

Microsoft's 2026 Work Trend Index data:

67% of AI's real impact comes from organizational factors — culture, manager modeling, talent practices — not from the tool.
80% of "Frontier Professionals" report more time on high-value work , vs. 58% of typical AI users. Frontier Professionals are the population whose teams have absorbed AI into how work gets done.
3.7x–10.3x ROI per dollar invested for top Copilot adopters — and the top adopters are the absorbers, not just the deployers.

The MSP playbook for driving absorption rather than just adoption:

Train deliberately. Adoption assumes employees figure it out. Absorption requires Copilot 101/102/201/202 (or equivalent) on a fixed cadence. The UK Government's 20,000-user trial measured the 26 min/day savings only for trained users.
Model from the top. Microsoft's WTI: when managers actively model AI use, employees report +17 points in AI value, +22 in critical thinking, +30 in trust in agentic AI. The VCAIO is the manager-modeling effect for SMBs without internal AI leadership.
Measure all three layers. Training (what employees were taught), Observability (what they actually do), Surveys (what they think). Absorption shows up in the gap between observability and surveys.
Sequence use cases. Quick Wins ship in Phase 3. Strategic bets follow. The roadmap shape matters because absorption compounds — early wins build the muscle for later bets.
Run the Council. Decisions made monthly, owners assigned, observability reviewed. BCG's 15%→55% employee positivity lift comes from active leadership engagement.

The MSP that frames the engagement around absorption — and prices the retainer to support the work — captures the long tail. The MSP that ships only adoption hands the long tail to whoever comes next.

Why SMBs Need AI Absorption to Capture Real Copilot ROI

For SMB executives, the Adoption/Absorption distinction is the answer to a question many CFOs are asking quietly: *we bought the licenses, why don't we see the ROI?* The answer is almost never about the tool. It is about the absorption gap.

What absorption looks like inside an SMB:

Employees use AI without thinking about it. It is in the workflow, not on the side.
Managers model the behavior. The team copies what leadership does, not what HR says.
The AUP, training, and Council are recurring — so the practice keeps shaping behavior even as new tools emerge.
ROI is visible in the QBR. Hours saved by use case, dollars returned, AI Maturity Score movement.

What adoption-only looks like:

Licenses provisioned, sparingly used. Copilot is open in tabs but rarely the default.
Champions enthusiastic, broader team detached. Adoption stalls at the early-adopter 15–20%.
Roadmap document filed. Strategy exists on paper; behavior unchanged.
No visible ROI. CFO restless.

The Lemhi line — *adoption is the kickoff, absorption is the managed service* — names the gap and points at the fix.

How Lemhi Engineers AI Absorption Into Every TaaS Engagement

Lemhi's entire platform is built around driving absorption rather than just provisioning adoption.

TaaS frames the engagement around absorption. The retainer continues past Phase 3 specifically because absorption requires ongoing work.
VCAIO drives manager modeling. For SMBs without internal AI leadership, the VCAIO is the structural substitute for the manager-modeling effect.
Council and QBR keep leadership engaged. Active executive sponsorship is the strongest predictor of absorption success. The Council is how that sponsorship becomes a recurring calendar event.
Three-layer measurement. Training reports, observability, surveys — all three reviewed monthly. Absorption shows up in the alignment of the three.
AI Maturity Score tracks absorption movement over time across 8 pillars. The score is the artifact; the absorption is the outcome.

Provisioning licenses is a 30-minute task. Driving absorption is a 24-month practice. Lemhi sells the practice.

Copilot ROI for SMBs: How to Calculate Hours Saved, Dollars Returned, and Payback Period

Wed, 01 Jul 2026 04:00:05 GMT

Copilot ROI for an SMB is the dollar value of time employees recover when they use Microsoft Copilot effectively, minus the cost of the licenses and the supporting practice. The simple formula is: (hours saved per user per month × blended hourly rate × number of users) − (license cost × number of users). The most credible external benchmark — the UK Government's 20,000-user Copilot trial — measured 26 minutes per day per trained user. Lemhi's published modeling produces conservative (50% of measured time × rate) and aggressive (1.5× measured time × rate) projections to bound the estimate honestly.

How MSPs Build a Credible Copilot ROI Story for SMB Buyers

For MSPs, Copilot ROI is the conversation that converts curious SMB executives into TaaS retainer signers. It is also the conversation where MSPs most often overpromise — which produces buyer's remorse six months in.

The credible MSP ROI methodology has three layers.

Inputs. Number of desk workers, blended hourly rate (typically $35–$75 for SMB knowledge workers), Copilot license cost ($30/seat/month for Microsoft 365 Copilot at current pricing).
Benchmark. UK Government's 20,000-user trial: 26 minutes/day per trained user. Microsoft's 2026 Work Trend Index: top Copilot adopters achieve 3.7x–10.3x ROI per dollar invested. Lemhi sample modeling: 8.8 hours/month per trained user as the median.
Output. Conservative annual savings, aggressive annual savings, payback period in months.

A worked example using Lemhi's published Boreal Bison Inc. sample: 60 desk workers, $35 blended rate, $30/seat license cost. At 8.8 hours saved per user per month — the sample's measured median — the team recovers 88 hours/month of capacity for the surveyed portion (or 528 hours/month if scaled across all 60). The conservative annual savings calculation (50% of recovered time × rate) is $18,480; the aggressive calculation (1.5× recovered time × rate) is $55,440. Against $30 × 60 × 12 = $21,600 in annual license cost, payback lands in the 60–90 day range under most scenarios.

What MSPs should avoid:

Single-point estimates. Always present conservative and aggressive scenarios. ROI is bounded, not deterministic.
Ignoring untrained users. 26 minutes/day is for trained users. Untrained users save much less; the ROI math depends on the training program.
Skipping the supporting cost. TaaS retainer cost is part of the ROI calculation. The retainer is what makes the savings real.
Promising ROI without governance. Shadow AI exposure can wipe out the ROI in a single incident. Governance is part of the value calculation, not a separate concern.

What SMB Executives Should Expect from Copilot ROI in 60–90 Days

For SMB executives, the Copilot ROI question is one your CFO is already asking. The honest answer has three parts.

Time savings are real, but they require training. Employees who are not trained on Copilot do not save 26 minutes a day. The 10-20-70 rule (BCG: 10% technology, 20% process, 70% people) holds — the technology alone is not the value driver.
The payback window is short. For most SMBs, Copilot pays back in 60–90 days once Phase 3 Quick Wins ship. That is shorter than most enterprise software ROI.
The ROI is sensitive to absorption, not adoption. Microsoft's 2026 WTI named the population that gets the biggest gains "Frontier Professionals" — 80% report more time on high-value work, vs. 58% for typical AI users. The difference is structural support inside the organization, not individual skill.

The most useful test of whether your Copilot investment is going to pay back: ask whether you have a VCAIO, a Council, and a training plan. If yes, the ROI math holds. If no, you are buying licenses without the practice that makes them productive.

How Lemhi Engage Packages Copilot ROI as a Phase 0 Deliverable

Lemhi Engage produces the Copilot ROI calculation as a packaged Phase 0 deliverable.

ROI Calculator. Inputs are team size, blended rate, license cost, and target adoption percentage. Outputs are conservative and aggressive annual savings, payback period, and a sensitivity analysis.
Benchmark library. The calculator references UK Government, Microsoft, BCG, and Gartner benchmarks transparently — so the MSP can defend the numbers in the client meeting.
Plan integration. ROI projections roll into the recommended package (Starter, Standard, Advanced) and the proposed go-live timeline.
QBR AI Segment. Actual ROI is reported quarterly inside the existing client QBR — measured against the Phase 0 projection. Movement on the AI Maturity Score is the leading indicator; hours saved by use case is the lagging indicator.
Continuous observability. The platform tracks active users, sessions, and agent invocations every month. The Council reviews whether the ROI projection is on track.

The combination of a defensible upfront projection and continuous in-flight measurement is what separates an MSP's ROI story from a vendor's. The MSP can show the number — and prove it.

Shadow AI in Microsoft 365: How MSPs Detect, Govern, and Reduce Risk

Mon, 29 Jun 2026 04:00:02 GMT

Shadow AI is any AI tool that employees use for work purposes without the organization's approval, monitoring, or governance. In Microsoft 365 environments, shadow AI typically shows up as personal ChatGPT or Claude accounts pasted with company data, browser-based AI extensions, ungoverned Copilot agents, and consumer-grade summarizers running over confidential email. Shadow AI is the single largest source of unmanaged AI risk inside SMBs in 2026 — and it is the failure mode that AI Acceptable Use Policies, Continuous Scanners, and the VCAIO role exist to address.

How MSPs Detect and Govern Shadow AI in Microsoft 365

Shadow AI is the conversation your SMB clients are about to ask you about, whether or not they know the term yet. CoreView's 2026 State of AI in Microsoft 365 report found that 70% of C-suites encourage AI use, but 53% of admin teams say AI is deploying faster than the safeguards. That gap is shadow AI in plain language. Microsoft now publishes shadow AI guidance on Microsoft Learn. New entrants like OpenClaw and Agent 365 are tooling against it specifically. The category is heating up.

For MSPs, shadow AI is both a risk surface and a revenue surface. It is a risk surface because the data exposure is real: confidential client information, financial detail, customer PII, and IP routinely end up pasted into consumer-grade chat windows. It is a revenue surface because shadow AI is the most concrete, most leadership-visible reason an SMB needs a TaaS practice. Nobody on the executive team has to be convinced shadow AI matters.

The MSP playbook is four steps.

Inventory. Use observability (egress monitoring, SaaS sprawl detection, browser-extension audits, the Continuous Scanner against M365) to build a real picture of which AI tools are in use, by whom, and against which data sources. Self-report surveys are not enough — employees underreport.
Categorize. Each tool falls into approved, conditional, or blocked. The categories are decided in the AI Council by the executive sponsor on the VCAIO's recommendation. Document the rationale.
Govern. Write the AUP to match the inventory. Update sensitivity labels and conditional access policies so that high-classification data cannot reach blocked tools. Train employees on the categories with concrete examples.
Enforce continuously. Re-scan the environment every month. Surface AUP violations to the VCAIO. Bring high-volume violations to the Council. Refresh training when a new tool category emerges.

The mistake most MSPs make is treating shadow AI as a one-time discovery exercise. By the time the inventory report ships, a new wave of consumer AI features has already entered the environment. The Continuous Scanner exists because the inventory has to be a running process.

Why Shadow AI Is the SMB Risk Surface That Cannot Wait

For SMB leadership, shadow AI is the version of AI risk that does not require a technical briefing to understand. Your employees are using AI to do their jobs. Most of them are doing it through personal accounts. None of those accounts are governed by your IT team. Whatever your AI policy says, the actual behavior in your environment is happening one browser tab away from your data.

The exposures are concrete:

Confidential client data pasted into consumer chat windows. Once in, gone — depending on the vendor's training and retention policy.
Regulated data (HIPAA, financial records, PII) processed by tools that have no compliance footprint.
IP and product plans summarized by an AI tool the company has no contract with.
Customer correspondence routed through summarization extensions that have access to entire inboxes.

The fix is not banning AI. Banning AI inside an SMB in 2026 is the same as banning email in 2002 — it doesn't work, and it makes you uncompetitive. The fix is governing AI: an approved list, a real AUP, employee training, continuous monitoring, and a Council that revisits all four when the landscape shifts. IBM's 2025 Cost of a Data Breach report found breaches involving shadow AI cost more on average than fully governed environments — the math favors the practice.

How Lemhi Powers Continuous Shadow AI Discovery for MSPs

Lemhi treats shadow AI as a continuous discipline, not a project deliverable.

The Continuous Scanner runs against client M365 environments throughout the engagement. Permissions, sensitivity labels, sharing risk, agent inventory, and shadow AI signals surface to the PSA ticket queue as findings, not as a one-time report.
Standardized AUP templates. First draft in Phase 1, revised in Phase 3 based on observed real-world usage. Reviewed in every Monthly AI Council. The AUP evolves with the environment.
AI Council shadow AI segment. The Council's Measurement Review block surfaces shadow AI signals each month — what tools showed up, what data they touched, what owners need to act.
Coordination with the VCISO. Where shadow AI overlaps with security posture or data classification, the VCAIO and VCISO coordinate. The MSP delivers both motions without duplicating the work.
Engage-led discovery. Lemhi Engage's Tenant Readiness check surfaces shadow AI signals during Phase 0, so the proposal the MSP brings to the SMB already names the problem in dollar terms.

Shadow AI is not solvable by tooling alone. It is solvable by the practice — a VCAIO who owns the AUP, a Council that makes the decisions, and a Continuous Scanner that keeps the inventory current. Lemhi is how MSPs deliver that practice at portfolio scale.

MSPs Have Seen This Movie Before. The AI Era Is the Same Script With One New Twist.

Fri, 26 Jun 2026 04:00:01 GMT

MSPs Have Seen This Movie Before.

Every major shift in the MSP industry has followed the same arc. Resistance. Client confusion. A wave that made adaptation non-optional. And a clear divide between the MSPs who prepared early and the ones who scrambled to catch up.

It happened with Break Fix to Managed Services. It happened with on-prem to Cloud. It happened with antivirus to Cyber. And it's happening right now with AI, with one meaningful difference from every era that came before.

The Arc, Every Time

Break Fix to Managed Services. The pitch seemed backwards: pay us monthly even when nothing breaks. MSPs resisted because the model was unfamiliar. Clients resisted because they didn't see the value until they saw the alternative — unpredictable bills and reactive chaos. The MSPs who moved early built recurring revenue and deep client relationships. The ones who held on to break-fix got margin-squeezed out.

On-Prem to Cloud. When Microsoft pushed Office 365, MSPs initially saw a threat to hardware revenue. Cloud meant no servers to sell, no on-prem maintenance, compressed margins on software licensing. The forcing function was the market itself: clients wanted to stop managing hardware, and hyperscalers were ready to serve them directly. MSPs who built cloud practices around migration, governance, and security kept the relationship. Those who resisted watched clients drift toward whoever would help them move.

AV to Cyber. Antivirus was standard practice until ransomware made it obviously insufficient. The MSPs offering only AV-and-patch got blamed when clients got hit, and they had no answer because they'd never built the next layer. The ones who'd invested in EDR, email security, and managed security stacks were positioned as trusted advisors before the breach, not scrambling to explain themselves after.

The pattern: resist, confusion, wave, divide. Four eras, same script.

The AI Era Is the Same Movie — With One Critical Difference

The AI arc follows the same script. MSPs uncertain about their role. Clients confused about what they need. A wave of adoption building pressure across the industry. And a clear divide forming between MSPs building AI service practices now and the ones who'll be caught explaining why they haven't.

Here's the difference: in every prior era, MSPs had to push clients toward the new model. Clients needed to be convinced that managed services was worth the monthly fee, that cloud was safer than the server in the back room, that real security cost more than a $5/month AV subscription.

In the AI era, the push is coming from the other direction. Clients went to annual planning and put "do AI" on the agenda themselves. They're coming to their MSPs with a question, not the other way around.

95% of MSPs report their clients are already exploring or actively adopting AI tools. 82% of small business employers have invested in some form of AI. 62% increased their AI spending in their 2025 budgets. The demand is not hypothetical. It's already in your client conversations, whether you're leading those conversations or not.

What this actually sounds like in the room is different from prior waves. MSPs aren't opening with "you should be thinking about AI." Clients are opening with "we need to do AI," usually without a clear definition of what that means. It shows up after a peer mention, a conference, or an internal champion experimenting with ChatGPT. The tone isn't curiosity. It's urgency without structure.

What makes this tricky is the expectation gap. The client thinks they're asking for "AI," but what they're actually asking for is guidance across multiple layers: tools, data handling, workflows, and risk. MSPs who respond with a tool recommendation miss the moment. The ones who slow it down and say "let's start with how your team is already using AI" are the ones who convert this into a real engagement.

This is also where the AI transformation vs. AI project distinction matters immediately. Clients will default to "can you implement X tool for us?" That's a project mindset. The right move is to reframe: "We'll help you implement this, but more importantly, we'll help you put a structure around how your business uses AI going forward." That repositioning is what moves the conversation from one-time work to a service.

Four Lessons From the Eras That Came Before

The historical arc teaches four things. Each one maps directly to where MSPs are in the AI transition right now.

Don't be first. The earliest managed services MSPs over-promised and under-delivered, burning trust before the model was mature enough to sustain it. The lesson isn't to wait — it's to learn before committing. Fast followers, who built service practices after the tools and frameworks existed but before their competitors, consistently outperformed naive first movers. In AI, the tools and frameworks exist. The governance frameworks are defined. The service motion is mappable. You don't need to invent anything — you need to operationalize it.

Don't be last. The MSPs who held out on cloud until clients were already looking elsewhere lost the trusted advisor position to whoever stepped in first. They didn't get fired — they got marginalized. In AI, "too late" arrives faster than it looks. 92% of MSPs are seeing AI-driven client interest. Only 13% have turned it into meaningful revenue. That gap won't stay open indefinitely. The clients asking "can you help us with AI?" will find someone who can answer yes.

Keep it centralized. The MSPs who built managed services as a standardized, repeatable model outperformed those who handled every client ad-hoc. Same client, different process, different tools: that's a margin and quality problem. In AI, the equivalent failure mode is answering every client AI question differently — one-off tool recommendations, informal conversations, no documented governance structure. A repeatable AI service motion — assessment, AUP, controls, ongoing governance — is what separates an AI practice from an AI experiment.

Governance always comes after the breach. Unless you build it first. Backup became a strategic conversation after a client lost data. Security stacks became non-negotiable after ransomware. In every era, the MSPs who built governance into the offer before the incident happened didn't have to justify it retroactively — they were already the trusted advisor when it mattered. In AI, the breach equivalent at SMB scale hasn't hit yet. The window to offer governance proactively, before a client's free LLM usage surfaces in a compliance conversation, is still open.

"Keep it centralized" is the one most MSPs are getting wrong right now. The failure mode is well-intentioned but fragmented: one client gets Copilot rolled out, another gets ChatGPT Team, another gets a policy document, another just gets a conversation. That's not a service. That's ad hoc consulting that doesn't scale and doesn't protect the MSP.

Centralized, in practice, means a defined service motion every client goes through: AI usage assessment first, AUP tied to real workflows second, approved tool stack third, and governance reviews as an ongoing loop. Same steps, same deliverables, regardless of client. The output might vary slightly, but the process doesn't. That's what makes it margin-positive and defensible.

The other translation is avoiding the AI project trap. If every engagement is scoped as deploying a tool or automating a workflow, you stay stuck in one-time revenue. The MSPs winning right now are using those projects as entry points into a broader transformation conversation: "This is one use case. Now let's govern how your business approaches all of them going forward."

Where You Are in the Arc Determines What You Do Next

In every prior MSP transition, the provider population distributed across three positions. Some moved too early: before the tools or client demand were mature, burning resources on a model that wasn't ready. Most landed in the right-timed window: when demand was real and the tools existed, but before the scramble. And some moved too late: when competitors had already claimed the trusted advisor seat and clients weren't interested in switching.

Right now, most MSPs are in the right-timed window for AI. The demand is real: clients are asking. The frameworks exist: governance, AUP, technical controls, approved tool stacks are all defined. The wave hasn't fully broken yet: a meaningful share of SMB clients haven't had the AI conversation with their MSP at all.

That window closes in both directions. Moving before demand is established wastes resources. Moving after competitors have claimed the conversation means playing catch-up in a market where trust is already placed.

Where most MSPs actually sit today is early in that right-timed window, but still reactive. They're answering AI questions when clients bring them up, not proactively shaping the conversation. That's the inflection point. The ones who move from reactive answers to a defined "this is how we handle AI with clients" motion are the ones who pull ahead.

The right-timed action isn't "go build an AI practice from scratch." It's much simpler: define your first repeatable deliverable. Usually that's an AI assessment that surfaces usage and risk, followed immediately by a governance recommendation. That gives you something concrete to sell and something to build from.

From there, the model becomes continuous by design. AI usage doesn't sit still: new tools show up, new use cases emerge, policies get outdated quickly. The MSP's role becomes running a continuous improvement loop — assess what's changed, update governance, refine the approved stack, enable the client to use it. That's what turns this from a one-time initiative into a recurring service the client actually depends on.

The Wave Is Already Here

The MSPs that thrived through Break Fix, Cloud, and Cyber didn't get lucky. They paid attention to the arc, recognized the pattern before it forced their hand, and built competency while they still had the runway to do it deliberately.

The AI wave hasn't broken fully, but it's already in the water. 96% of MSPs expect client AI demand to keep growing. Clients came back from annual planning with AI on the agenda. The question isn't whether to engage. It's which position you're in when the wave completes.

The ones who built early will be the trusted advisors. The ones who waited will be explaining why.

AI Governance for SMBs: The MSP Service You're Already Qualified to Deliver

Wed, 24 Jun 2026 04:00:12 GMT

Your Clients Have Three AI Choices. Only One of Them Is Defensible.

When the topic of AI comes up with an SMB client, they're going to land in one of three places. They're going to ban it. They're going to let it run without guardrails. Or they're going to put a governance framework in place.

The first two options feel like decisions. They're not. They're abdications. Eventually, both create the same outcome: a data incident, a compliance conversation, or an employee who used a free AI tool to summarize something they shouldn't have.

The governed middle ground is the only defensible choice. And for MSPs, it's also a ready-made managed service.

MSPs see the same three archetypes across their client base. The ban client usually has a written policy — "AI tools are not permitted" — but their employees are still using ChatGPT Free on personal devices for email drafts and client summaries. The policy exists, but there's zero enforcement and no alternative. Usage goes underground immediately.

The free-for-all client is easier to spot. No policy, no approved tools, and employees actively using AI inside core workflows. Marketing teams feeding customer lists into public tools. Finance teams summarizing internal reports. Service teams rewriting ticket notes. Nothing is coordinated, and nothing is governed. Usage is already operational.

The governed clients are still the minority, but the pattern is consistent: they didn't start with policy, they started by understanding what was already happening. The shift happens when an MSP shows them their actual exposure and gives them a path that doesn't slow the business down. That's the entry point for the service.

What an AI Governance Framework Actually Covers

An AI governance framework isn't a policy binder on a shelf. It's an operational structure that answers four questions every SMB needs answered before an employee opens a browser tab to ChatGPT: what data is allowed in AI tools, which tools are approved, what happens if someone violates the policy, and how do the technical controls enforce all of the above.

What Data Is Allowed

This is where most SMB conversations start. The practical framework uses four tiers:

Public data: Anything already externally available — product descriptions, publicly known information, general research. This can go into any sanctioned tool without restriction.

Internal data: General business operations, internal processes, non-sensitive communications. Sanctioned tools only.

Confidential data: Client records, employee personal information, contracts, financial data. Sanctioned tools only, and only those with an executed Data Processing Agreement.

Restricted data: PHI, privileged legal communications, trade secrets, regulated financial data. No external LLM without explicit case-by-case approval. For most SMBs, this tier is a hard stop.

What actually works in practice is a simple order of operations, not dropping a full policy on clients day one. Andy's framework rolls out in sequence: first, surface where data is already being used in AI. Second, define the four data tiers using examples from the client's actual business. Third, map those tiers to real workflows. If an account manager handles client records every day, you don't explain "confidential data" abstractly. You show them exactly where their boundary is.

The language matters more than the framework. "Don't paste client data into AI" fails immediately. "If it has a client name, it only goes into these tools" gets followed. The more the classification maps to how employees already think about their work, the more it sticks without enforcement friction. The goal is for employees to self-classify in seconds. Every additional layer of interpretation introduces failure. Consistent behavior at the point of use is the target, not perfect classification.

Which Tools Are Approved

The approved list isn't a yes/no on AI. It's version-specific and account-specific.

Microsoft 365 Copilot processes data within the Microsoft 365 compliance boundary — for clients already in M365, this is the lowest-friction sanctioned option. ChatGPT Enterprise and Claude Team or Enterprise both offer Data Processing Agreements and don't use conversation inputs for model training by default. These belong in the Tier 1 (sanctioned) bucket.

Consumer versions — ChatGPT Free, ChatGPT Plus, Claude.ai free tier — are not appropriate for any data above the public tier. They go on the prohibited list for clients handling sensitive data, full stop.

What the Repercussions Are

A policy without enforcement is theater. The repercussions section of an AUP has two jobs: it establishes accountability, and it creates safe harbor for good-faith reporting.

The accountability piece is straightforward: violations of the data classification or approved tool rules are treated the same as other security policy violations. The safe harbor piece matters more than most MSPs realize. Employees who accidentally submit restricted data to an ungoverned tool are far more likely to report it if they know the disclosure won't cost them their job. That report is the difference between a contained incident and an undetected breach that surfaces during an audit months later.

The Technical Controls That Make It Real

Policy without technical controls is an honor system. For clients in regulated industries or with meaningful data liability, an honor system isn't adequate. The MSP's advantage is that enforcement happens at the infrastructure layer, and the tools to do it are already in the stack.

What works in practice is a clear implementation sequence, not turning everything on at once. The recommended stack is straightforward: DNS filtering (Cloudflare Gateway, Umbrella, or DNSFilter) for access control, application whitelisting (ThreatLocker) for endpoint enforcement, and Microsoft Purview for any M365 client. Most MSPs already have at least two of these deployed.

The sequence matters. Step one: establish the approved tool list. Step two: enforce it at DNS so employees can't access unapproved AI tools on managed devices. Step three: lock down endpoint-level AI apps through application whitelisting. Step four, for M365 clients only: enable Copilot with proper Purview policies and audit logging.

Where MSPs get stuck is trying to solve for content-level inspection. That's not the job. You're controlling access and environment. The policy governs behavior inside the boundaries. Trying to inspect prompts is a dead end for SMB clients.

The Approved LLM Allowlist

DNS-layer filtering can enforce which AI domains are accessible on company networks and devices. The configuration creates an allowlist: approved AI tools resolve normally, everything else is blocked. This is standard MSP capability applied to a new category.

One important caveat: DNS filtering controls access, not content. It prevents an employee from reaching an unapproved AI site. It cannot see the text of the prompt they send to an approved one. Policy and technical controls work together. DNS filtering isn't a substitute for data classification — it's the enforcement mechanism for tool access.

Application Whitelisting for AI Desktop Apps

For AI tools that run as installed applications — GitHub Copilot, local LLM clients, AI-powered desktop utilities — ThreatLocker-style application whitelisting is the enforcement layer. In a default-deny configuration, if the application isn't on the approved list, it doesn't run.

Most MSPs deploying ThreatLocker are already managing this infrastructure. Extending it to cover AI desktop applications is a configuration exercise within an existing deployment, not a new tool purchase. Native integrations with ConnectWise, Autotask, Datto, and N-able mean the MSP toolchain already supports it.

Microsoft Copilot Governance for M365 Clients

For clients already in Microsoft 365, Copilot governance is available directly in the M365 admin center. Since Ignite 2025, Microsoft Purview is integrated into the MAC with a dedicated Security tab for Copilot. Admins can control which users have access, apply DLP policies that block Copilot from processing files with specific sensitivity labels, and pull detailed audit logs capturing prompts, responses, and files accessed. SharePoint Advanced Management (included with M365 Copilot licenses) handles content access and permissions scoping.

For MSPs with M365 clients, this is the fastest path to a governed AI environment. The governance infrastructure is already there. It needs to be configured, not purchased.

Why This Is Already in Your Playbook

AI governance sounds like a new discipline. It isn't.

Break it down: policy creation (MSPs do this), data classification (MSPs do this), application management and whitelisting (MSPs do this), user access controls (MSPs do this), compliance documentation (MSPs do this). The only new element is that the subject matter is AI tools rather than general software and network access. The governance motion is the same one MSPs have been running for years on general IT security and compliance.

The MSP who walks into an AI governance conversation isn't starting from zero. They're applying existing expertise to a new surface area, with a client base that already trusts them to do exactly that.

62% of MSPs already bundle AI governance into recurring services, though delivery maturity varies. The MSPs building durable recurring revenue around this are anchoring it in a structured service motion: an initial AI assessment to surface what's already in use, AUP creation mapped to actual client workflows, technical controls implementation, and quarterly governance reviews to update policies as the AI landscape shifts.

The MSPs gaining traction are packaging this as a defined service, not an abstract capability. The entry point is a fixed-scope AI assessment, typically a mix of survey, interview, and lightweight discovery that produces one output: a clear view of where AI is already being used and where the risk sits.

That leads directly into the first paid deliverable: an AUP mapped to actual usage, plus a recommended tool stack and control plan. This is where most clients convert, because it translates risk into something concrete and solvable.

From there, the upsell motion is straightforward: ongoing governance. Quarterly reviews, policy updates, and re-assessment as new AI tools show up. The MSPs who structure this as a recurring advisory line item rather than a one-time project are the ones building durable revenue around it.

The Clients Who Need This Are Already in Your Book

Every client in an MSP's book is sitting in one of the three buckets. Most are in the free-for-all bucket, whether they know it or not. A meaningful number think they're in the ban bucket but aren't, because their employees figured out workarounds the MSP has no visibility into.

The MSP who shows up with a framework, a policy, and a technical controls plan isn't selling something the client doesn't need. They're solving a problem the client already has.

AI governance is an MSP-native service. The playbook exists. The tools exist. The client need exists. The only thing left is packaging it and walking in the door.

Shadow AI Risk Management for SMBs: Your Employees Are Already Using Tools You Haven't Approved

Mon, 22 Jun 2026 11:00:00 GMT

Your Employees Are Already Using AI Tools You Haven't Approved

Here's a number worth sitting with: 49% of employees are using AI tools their employer never approved. In most SMBs, IT has no idea which ones, what data went in, or what happened to it after.

That's not a discipline problem. That's a governance gap. And it's already open at most of your clients' businesses, whether they know it or not.

When an MSP runs a first-pass AI assessment across a new SMB client, the pattern is consistent. You don't find one or two tools. You find usage everywhere. Marketing is in ChatGPT writing campaigns. Sales is drafting outreach against CRM exports. Ops is pasting internal process docs for cleanup. All of it happening through personal accounts or free tiers, with no logs, no contracts, no visibility.

The first client conversation has changed. It's no longer "Are you using AI?" It's "Where is your data already leaking into systems you don't control?" Every owner has a gut sense the answer isn't zero.

The Scale of the Problem

The scope of Shadow AI in SMBs isn't a projection. It's the current baseline.

BlackFog's November 2025 survey found that nearly half of all employees (49%) are using AI tools their employer hasn't approved. 98% of organizations have employees using unsanctioned software, and AI tools now lead that category. SMBs with 11 to 50 employees average 269 unsanctioned tools per 1,000 employees, the highest density of any company-size segment. The typical enterprise runs 14 distinct AI tools. Its IT team knows about 4 or 5 of them.

The question is no longer whether your clients have Shadow AI. It's what's in it, and what happens when something goes wrong.

Why Employees Do It (And Why You'd Do the Same)

The employees reaching for unsanctioned AI aren't trying to create incidents. They're trying to finish their work.

41% say the tools are faster. 33% say they produce better results. 28% say IT approval takes too long. Only 22% of American office workers use exclusively company-approved AI tools. Only 34% of organizations have any generative AI policy at all. When there's no approved alternative and no policy, employees don't interpret the silence as "don't use AI." They interpret it as "figure it out."

The riskiest behavior isn't the generic prompt. It's the context-heavy one: when client names, financials, ticket histories, or internal documents get pasted in. That's where exposure actually happens. And it happens every day, across every department, without anyone flagging it as a risk.

ChatGPT's free and Plus tiers default to using conversation inputs for model training unless the user actively opts out in Settings. Most users don't know that option exists. The employee pasting a client list into ChatGPT to draft a follow-up email isn't being reckless. They don't think of it as sending data anywhere. They think of it like typing into Google.

The result: 33% of employees have shared enterprise research or datasets with unsanctioned AI tools. 27% have inputted employee data. 23% have submitted company financial information. None of them were attempting exfiltration. They were working.

What's Actually at Stake

In April 2023, three separate Samsung semiconductor engineers submitted proprietary data to ChatGPT within 20 days: source code, defect detection algorithms, and a confidential meeting transcript. The submissions weren't coordinated. Each engineer was solving a specific work problem. Samsung confirmed the data was irrecoverable from OpenAI's servers.

Samsung is a large company. The pattern is not.

Shadow AI is now implicated in 20% of data breaches and adds an average of $670,000 per incident. The average total cost of a Shadow AI-related breach: $4.2 million. 83% of organizations have no automated AI security controls at all.

The audit trail problem makes this worse. When an employee pastes customer data into a free LLM, no DLP alert fires, no log entry appears in the SIEM, and the compliance officer has nothing to review. This isn't a firewall problem. It's a visibility problem, and visibility requires governance, not just tooling.

For regulated SMBs, the stakes are even less abstract. Standard ChatGPT is not HIPAA compliant. OpenAI doesn't provide Business Associate Agreements for standard products, meaning any healthcare SMB whose staff uses ChatGPT Free with patient data has likely committed a reportable violation. HIPAA penalties can reach $2 million per violation category annually. Law firms have privilege exposure. Financial advisors have SEC and FINRA obligations. In healthcare and legal specifically, one question tends to close the conversation: "If this data went into ChatGPT Free, can you produce an audit trail?" The answer is always no.

Why Blocking Doesn't Work

The reflex is to block it. Block the domains, write a ban, run training. This approach is not only ineffective. It makes the problem worse.

46% of knowledge workers say they'd continue using AI tools even if explicitly banned. 47% access GenAI tools through personal, unmonitored accounts, so a web filter on company devices accomplishes nothing. More importantly, banning removes the pathway where an employee would ask IT to vet a new tool. Every AI adoption that follows happens in the dark, by definition.

The answer isn't to block. It's to govern.

The Governance Fix: What an AI AUP Actually Covers

An AI Acceptable Use Policy isn't a generic IT policy with "AI" in the header. It needs to do specific work.

Tool tiering: Tier 1 is Enterprise Sanctioned (vetted, procured, covered by data agreements). Tier 2 is Tolerated with restrictions (acknowledged but with data limits). Tier 3 is Prohibited.

Data classification: An explicit list of what cannot go into any AI tool without approval: PII, PHI, financial records, source code, legal documents.

Approved tool list with specificity: "ChatGPT" is not sufficient. ChatGPT Free and ChatGPT Enterprise have materially different data terms. The policy needs to name the version and account type.

Incident reporting and attestation: What an employee does when they think they've made a mistake, and a signed acknowledgment that they've read the policy.

What's working in practice is packaging this as structured onboarding, not a one-off document. The process starts with a lightweight AI usage assessment (survey, interview, tool capture), then a guided session to align on risk tolerance and real workflows. The AUP gets mapped to actual behavior already uncovered, which is why it sticks: employees recognize their own usage inside the policy. MSPs seeing traction are bundling the assessment, AUP creation, approved tool stack recommendations, and ongoing governance check-ins into a recurring advisory service.

Why MSPs Are the Right Party to Close This Gap

SMBs don't have a CISO. They don't have an AI governance team or a legal department reviewing vendor terms. They have an MSP.

The MSP has the broadest visibility into the client environment, enforcement capability at the infrastructure layer, and the relationship required to make policy actually stick. No other vendor in the stack can replicate that combination.

The market demand is real. 93% of businesses are using AI outside governed environments. 94% of MSPs say they're committed to AI governance services, but only 43% report high delivery maturity. That gap is where the competitive advantage sits.

The entry point doesn't need to be complicated: "We're running an AI usage assessment across our clients" opens the door without requiring the MSP to be an AI expert from day one. And once you map how a client uses AI, you get pulled naturally into automation, workflow, and tool consolidation. Governance is the wedge. The advisory relationship that follows is worth significantly more.

The MSPs that move now, building this into a repeatable service, aren't just adding a line item. They're becoming the trusted advisor for the defining technology problem their clients will face for the next decade.

The Monthly AI Council: A 60-Minute Format for SMB Leadership Decisions

Wed, 17 Jun 2026 20:19:55 GMT

The Monthly AI Council is a 60-minute standing leadership meeting facilitated by the VCAIO and chaired by the client's executive sponsor. It is the room where AI decisions land. The Council is a working session — not a status review. Six segments, fixed timing, named owners, decisions documented. Every TaaS engagement above ~50 employees runs a full Council; smaller engagements run the Compass Module instead.

Why the Monthly AI Council Anchors the MSP AI Practice

For MSPs, the Council is the part of the TaaS motion that separates a practice from a project. A project ends. A Council is a calendar event that recurs forever — which is exactly what makes the retainer defensible.

The 60-minute format is six segments.

Welcome (5 minutes). Executive sponsor opens. Agenda confirmed. Any urgent escalations surfaced.
Measurement Review (15 minutes). Three layers of measurement reviewed: training completion, AI observability (active users, sessions, agent invocations), and survey signal (employee sentiment, friction reports, shadow AI signals).
Use Case Spotlight (15 minutes). Two to three use cases reviewed — one from the active pipeline, one new candidate, one retrospective. The VCAIO presents the recommendation; the Council decides go/no-go.
Roadmap & Decisions (15 minutes). AI Maturity Score movement. Roadmap milestones tracked. AUP updates. Governance changes. Decisions documented with owners.
Q&A (5 minutes). Open floor for the sponsor and department heads.
Actions (5 minutes). Named owners and dates for everything decided. Documented and circulated within 24 hours.

What's not in the Council: status reports, technical deep dives, vendor demos, and individual employee reviews. Those happen elsewhere. The Council exists to make decisions and assign owners.

The reason the format matters is that AI Council failure is usually a format failure. When the Council drifts into status review, leadership disengages. When it drifts into technical detail, decisions slip. When it drifts into vendor demos, the sponsor stops attending. The 60-minute discipline is what keeps the Council alive at month 14.

How the Monthly AI Council Turns AI Strategy into SMB Leadership Decisions

For SMB leadership, the Council is the structural mechanism that turns AI from a topic into a discipline. The single best predictor of AI adoption success, according to Prosci's 25-year change-management benchmarking study, is active and visible executive sponsorship. BCG found employee AI positivity rises from 15% to 55% with active leadership support. None of those statistics describe a one-time kickoff meeting. They describe a recurring rhythm.

For your executive team, the Council is a 60-minute monthly commitment. In exchange you get:

A single room where every AI decision lands — instead of decisions happening in IT tickets, email threads, and hallway conversations.
A consistent record of what was decided, by whom, with which evidence. Removes the "I thought we agreed to" pattern.
A working forum where department heads commit owners — which is what turns Council decisions into Monday-morning action.
A predictable cadence so AI stays on the leadership agenda even when other priorities are loud.

The Council should be on your calendar at TaaS kickoff. If it isn't, your AI program does not have a decision forum — and the absence of a forum is the most common reason AI programs stall after Phase 3.

How Lemhi Automates Monthly AI Council Prep for VCAIOs

Lemhi makes the Council a sellable, repeatable artifact — not a custom motion the MSP reinvents at every client.

Standardized 60-minute agenda template. The six-segment format is built into the platform. The VCAIO walks in with the agenda pre-populated.
Automated Measurement Review pulls. Training reports, observability dashboards, and survey signal are curated by the platform before the meeting. The VCAIO reviews and selects what to surface; they don't assemble from scratch.
Use case pipeline scoring. The platform pre-scores use cases on fit, effort, and impact. The VCAIO selects which two or three to bring to the Council each month.
Decisions log integration. Decisions are captured in the platform and roll into the QBR AI Segment and the AI Maturity Score updates.
Compass Module alternative. For clients too small for a full Council, the 30-minute Compass format is built in. Same VCAIO, lighter cadence, same decision discipline.

The Council works because the platform makes the prep tractable. Without automation, the VCAIO drowns in prep work and the Council quality degrades. With Lemhi, the VCAIO can carry 12–18 Council clients sustainably.

AI Acceptable Use Policy (AUP) Template for SMBs: What to Include, What to Leave Out

Wed, 17 Jun 2026 04:00:04 GMT

An AI Acceptable Use Policy, or AUP, is the document that tells employees which AI tools they can use, on which data, with what controls, and what happens when the rules are broken. A good SMB AUP is short, plain-English, tied to concrete examples, and revisited every month based on real-world usage. The AUP is the cornerstone artifact of an AI governance program — and it is the first deliverable the VCAIO produces inside a TaaS engagement.

How MSPs Ship an AI Acceptable Use Policy in Phase 1 of TaaS

For MSPs, the AUP is often the easiest first deliverable to ship in a new TaaS engagement — and the easiest one to ship badly. A bad AUP is long, written in legal English, and disconnected from the tools employees actually use. It gets signed during onboarding and then ignored.

A good SMB AUP includes seven sections.

Approved tools list. Named tools, with the categories: approved, conditional, blocked. Include the consumer alternatives explicitly — if Claude is approved but Claude.ai personal accounts are blocked, say so.
Allowed data classifications by tool. Map each approved tool to the data sensitivity tiers it can handle (Public, Internal, Confidential, Restricted, Regulated). Be specific.
Prohibited use cases. Not what's allowed — what's not. Examples: pasting client contracts into consumer chat, using AI to write performance reviews without disclosure, generating customer-facing content without human review.
Disclosure rules. When employees must say AI was involved — for example, in customer communications, legal filings, or vendor proposals.
Incident response. What to do when a sensitive document is exposed to a non-approved tool. Who to call. How fast.
Training requirement. What training is mandatory, on what cadence. Tied to the Copilot 101/102/201/202 curriculum or equivalent.
Review cadence. When the AUP gets revisited (every Council, fully rewritten annually).

What to leave out: vague principle statements ("we use AI responsibly"), references to laws the SMB doesn't operate under, and clauses copied from someone else's AUP without testing against the client's actual workflows. The AUP should be three to five pages, not twenty.

The TaaS phasing is built around the AUP lifecycle. Phase 1 produces the first draft against the client's stated policies and observed environment. Phase 3 revises it once Copilot Quick Wins have shipped and actual usage patterns have emerged. Every Monthly AI Council reviews the AUP against new tool categories, new shadow AI findings, and new employee questions.

What Makes an AI Acceptable Use Policy Real for SMB Employees

For SMB leadership, the test of whether you have a real AUP is whether your employees can summarize it from memory. If they cannot, the AUP is not operating — it is a compliance prop.

Three things make an AUP operative inside an SMB:

Specific tools, not categories. Naming ChatGPT, Claude, Copilot, Gemini, and Perplexity individually is more useful than "generative AI tools." Employees know the products, not the categories.
Concrete examples. "Don't paste a signed contract into ChatGPT" lands. "Don't process Restricted-classification data with unapproved tools" doesn't.
A visible owner. The AUP should name the VCAIO (or the equivalent role) as the responsible person. When employees have a question, they need a name to ask.

The AUP is the single most important governance artifact your AI practice produces. It is also the artifact most likely to drift, because the AI landscape moves faster than the policy review cycle. The discipline of revisiting the AUP every month in the AI Council is what keeps it real.

How Lemhi Standardizes AI Acceptable Use Policy Delivery for MSPs

Lemhi standardizes the AUP delivery so every TaaS client gets a current, environment-matched policy without the MSP rewriting from scratch.

AUP template library. Standardized templates the VCAIO tailors to the client's tool inventory and data classifications. Phase 1 ships the first draft inside the engagement charter.
Phase 3 revision flow. Once Copilot Quick Wins ship and real-world usage data emerges, the platform surfaces the gaps for the VCAIO to address in the revised AUP.
Council integration. The Monthly AI Council includes a standing AUP review block. New tool categories, new shadow AI findings, and new employee questions all feed the next revision.
Sensitivity-label and conditional-access coordination. The Continuous Scanner detects misalignments between the AUP and the technical environment, surfacing them to the PSA queue for remediation.
Training tie-in. The AUP feeds the Copilot 101/102/201/202 curriculum, so what employees are taught matches what the policy requires.

The AUP works because the practice runs it. Lemhi sells the practice.

AI Readiness Assessment for SMBs: The 8 Dimensions Your MSP Should Be Measuring

Mon, 15 Jun 2026 11:00:01 GMT

An AI Readiness Assessment is a structured evaluation of an organization's preparedness to adopt and govern AI. A good SMB AI Readiness Assessment measures eight dimensions: Strategy & Leadership, Practice Readiness, Technical Foundation, Governance & Responsibility, People & Training, Commercial Model, Client Discovery, and Ongoing Delivery. The assessment is the input to Phase 1 strategy work inside a TaaS engagement and produces the baseline AI Maturity Score the VCAIO advances over time.

How MSPs Use the 8-Dimension AI Readiness Assessment to Win TaaS Engagements

For MSPs, the AI Readiness Assessment is the most common entry point into a TaaS conversation. Most SMB executives will agree to a structured assessment even when they will not agree to a full strategic engagement. The assessment opens the door.

The 8-dimension framework gives the assessment shape:

Strategy & Leadership. Does the organization have a stated AI strategy? Who owns it? Is the executive sponsor engaged?
Practice Readiness. Does the MSP have a packaged AI practice (TaaS or equivalent)? Are the artifacts standardized?
Technical Foundation. Is the M365 environment configured for Copilot? Are permissions, sensitivity labels, and identity in order?
Governance & Responsibility. Is there an AUP? Is shadow AI inventoried? Are incident response paths defined?
People & Training. Are AI Champions identified? Is training planned? Is the manager-modeling effect present?
Commercial Model. Is the AI engagement priced as a project or a practice? Is recurring revenue captured?
Client Discovery. Has the client articulated priority use cases? Are stakeholders mapped?
Ongoing Delivery. Is there a recurring cadence (Council, QBR AI Segment)? Are measurements in place?

Each dimension scores on a 0–6 scale, producing a total readiness score (0–48). Lemhi defines four tiers:

0–12: Not Yet. The organization is not ready for a structured AI practice. Start with foundational hygiene.
13–24: Getting Started. Some pieces are in place. Phase 0 and Phase 1 will close the gaps quickly.
25–36: Approaching Ready. Most pieces are in place; assessment surfaces specific blockers to remediate.
37–48: AI-Ready MSP/SMB. Practice can launch immediately. Phase 0 is mostly a formalization exercise.

The opening stats most MSPs use to frame the assessment conversation: Lansweeper found 90% of MSPs say AI is vital, only 41% have meaningful integration. Pax8's March 2026 Pulse research found 62% of SMBs are using AI, and 84% trust their MSP to lead their AI direction. The demand and the trust are present; the readiness is not.

What SMBs Learn from a Real AI Readiness Assessment

For SMB leadership, the AI Readiness Assessment is the structured way to find out what your organization needs to do before AI investment pays off. It is also the most honest mirror you will get into your current AI position.

The assessment outcomes you should expect:

A scored baseline across the eight dimensions, with the lowest-scoring dimensions highlighted.
A prioritized list of remediation items — sequenced by impact and effort.
A recommended package (Lemhi Engage produces Starter, Standard, and Advanced recommendations).
An ROI estimate — conservative and aggressive — for the proposed rollout, based on team size, blended rate, and license cost.
A go-live recommendation — pilot first vs. broader rollout, training cadence, executive sponsorship plan.

The most common assessment finding inside SMBs in 2026 is high readiness on Technical Foundation (Copilot licenses purchased, M365 hygiene reasonable) but low readiness on Governance & Responsibility (no AUP), People & Training (no Champions identified), and Ongoing Delivery (no recurring cadence). That pattern is precisely why projects fail and Practices succeed.

The assessment is not optional if you intend to spend meaningful money on AI. It is the cheapest investment you can make before the bigger decisions.

How Lemhi Engage Runs the AI Readiness Assessment as a Repeatable Motion

Lemhi Engage (GA June 2026 at Pax8 Beyond) is the platform that runs the AI Readiness Assessment as a sellable, repeatable motion.

AI Leadership Survey. Captures executive perspective on AI strategy, risk appetite, and intended outcomes.
Plan builder. Generates the prioritized remediation list, the recommended package, and the readiness score.
Tenant Readiness check (Microsoft's ARA). Surfaces the technical findings against the M365 environment.
ROI calculator. Produces conservative and aggressive savings projections based on team size, blended rate, and Copilot license cost.
Packaged proposal output. The MSP takes a single document into the client meeting that contains the score, the gaps, the recommended package, and the ROI math.

Engage is the front of the TaaS funnel. The MSP runs it as Phase 0; the output is a TaaS retainer the SMB can sign with eyes open. Once the retainer is signed, the assessment findings feed Phase 1 strategy, Phase 2 technical readiness, and the baseline AI Maturity Score the VCAIO advances quarter over quarter.

AI Governance for SMBs: The Practical 30/60/90 Day Plan

Thu, 11 Jun 2026 11:00:02 GMT

AI governance for SMBs is the set of policies, controls, monitoring, and decision forums that make AI use safe, accountable, and effective. A practical 30/60/90 day plan covers the AUP, shadow AI inventory, training rollout, technical hygiene (sensitivity labels, conditional access), Council convening, and ROI measurement. The plan is intentionally fast — most SMBs cannot sustain a six-month governance engagement, and they should not have to.

How MSPs Deliver SMB AI Governance in 30/60/90 Days

For MSPs, the 30/60/90 day governance plan is the operational artifact that takes Phase 0–3 of TaaS and lays it on a calendar the client can see. It removes the abstraction from "governance" and replaces it with named work, named owners, and named dates.

Days 0–30: Foundation.

AI Leadership Survey with the executive sponsor and department heads.
Tenant Readiness check (Microsoft's ARA) against M365.
Shadow AI inventory baseline using the Continuous Scanner.
AUP first draft, including the approved/conditional/blocked tool list.
AI Champions identified across departments.
Council and QBR AI Segment cadence scheduled.
Phase 0 → Phase 1 transition.

Days 31–60: Build.

Technical hygiene remediation against the ARA findings (permissions, sensitivity labels, conditional access).
Copilot Quick Wins identified and sequenced for rollout.
Training plan finalized; Copilot 101/102 sessions delivered to the pilot team.
First Monthly AI Council convened. AUP reviewed by leadership; first revisions captured.
AI Maturity Score baseline established across the 8 pillars.
Phase 2 work in flight.

Days 61–90: Activate.

Copilot Quick Wins deployed to end users.
AUP revised against observed real-world usage (Phase 3).
Use case pipeline launched from the AI Inventory.
Second Monthly AI Council convened. Decisions documented; owners named.
First quarterly AI Recap or QBR AI Segment delivered.
Practice transitions from onboarding mode to recurring rhythm.

What's not in the 30/60/90 plan: large custom agent builds, departmental AI projects, and broad organizational change initiatives. Those are Program-side work that lives outside the 90-day governance plan. The plan is governance, not strategy execution.

What SMB Leaders Should Expect at Each AI Governance Gate

For SMB executives, the 30/60/90 day governance plan is the answer to a question that often stalls AI investment: *how long until we have governance in place?* The honest answer is 90 days under a real practice.

What you should expect from your MSP at each gate:

Day 30 gate. AUP first draft in hand. Shadow AI inventory baseline produced. AI Champions named. Council on the calendar.
Day 60 gate. Technical hygiene closed against the ARA findings. First Council convened with leadership decisions captured. Pilot team trained.
Day 90 gate. Quick Wins deployed. AUP revised against real usage. Use case pipeline live. First QBR AI Segment delivered.

If your MSP cannot articulate the 30/60/90 plan in writing during Phase 0, you are likely buying a project rather than a practice. The plan is the most basic test of operational maturity.

The plan also names the dependency that fails most often: executive sponsorship. Active sponsorship is required at Day 0 for the AI Leadership Survey, at Day 30 for AUP approval, and at Day 60 for the first Council. If the sponsor is not available, the plan slips — and most plans slip on the sponsor, not the technical work.

How Lemhi Standardizes the 30/60/90 AI Governance Plan for MSPs

Lemhi makes the 30/60/90 governance plan a standardized, repeatable motion across the MSP's full client book.

Lemhi Engage runs the Day 0–30 motion. AI Leadership Survey, Tenant Readiness check, ROI calculator, AUP first draft.
VCAIO tooling runs the Day 31–60 motion. Council prep, ARA remediation tracking, AI Maturity Score baseline.
Continuous Scanner runs across all 90 days and beyond. Shadow AI, permissions, sensitivity labels — surfaced to the PSA queue.
Standardized artifacts for each gate. Day 30 gate checklist, Council agenda, AUP template, QBR AI Segment slides.
Compass Module variant. For clients too small for the full plan, the Compass Module compresses the 30/60/90 plan to fit the owner-led format.

The 30/60/90 plan is what governance looks like when it ships from a practice instead of from a consulting engagement. Lemhi sells the practice; the plan is the visible artifact.

The Compass Module: How Small Businesses Get a VCAIO Without a Full AI Council

Wed, 10 Jun 2026 11:00:01 GMT

The Compass Module is the lighter VCAIO operating rhythm Lemhi defines for SMBs too small for a full Monthly AI Council. Instead of a 60-minute multi-stakeholder Council, the Compass Module runs a 30-minute monthly working session with the owner or executive sponsor. Same VCAIO, same Practice, fewer hours, lower cost to serve. The Compass Module is what makes the VCAIO motion viable at the lower end of the MSP's client book — and it is the engagement shape for most owner-led firms under 50 employees.

How the Compass Module Extends the VCAIO Motion to Small SMB Books

For MSPs, the Compass Module solves the capacity problem that has historically kept VCAIO motions out of the SMB long tail. A full Council client takes 8–12 VCAIO hours per month and supports a book of 12–18. A Compass client takes 3–5 hours and supports a book of 25–35. The math is what lets MSPs offer Managed Intelligence to clients that would otherwise be too small to justify the practice.

What's different about the Compass Module:

Single-stakeholder format. The 30-minute working session is with the owner or executive sponsor — not a multi-stakeholder room.
Async measurement digest. The Measurement Review happens async before the meeting. The session focuses on decisions and unblocks.
Tooling-curated use case shortlist. The VCAIO surfaces 2–3 use cases per month; the owner picks one. The pipeline runs lighter.
Quarterly AI Recap instead of a full QBR AI Segment. Delivered async or in a 30-minute call. No separate quarterly meeting required.

What stays the same:

The Practice still runs. TaaS retainer, AI Maturity Score, AUP, Continuous Scanner, training rollout.
The Program still exists. The owner-operator is both the executive sponsor and the department head; the Program is collapsed but real.
Measurement still happens. Training, observability, surveys — all three layers, even if reviewed async.

The clearest decision rule for MSPs: Full Council fits when the client has 50+ employees, a defined leadership team, and an existing meeting cadence that includes a QBR. Compass fits when the client is owner-led, under ~50 employees, or has no functioning leadership forum to invite the VCAIO into. A mixed book in the 18–24 client range is achievable for one VCAIO when the book blends Council and Compass engagements.

What Owner-Led SMBs Get from a Compass Module Engagement

For owner-led SMBs, the Compass Module is the answer to a real frustration: AI advice is mostly built for companies with executive teams, change-management functions, and HR departments. None of that exists at a 20-person firm. The Compass Module gives the owner-operator the same AI discipline — without pretending the leadership infrastructure exists.

What the Compass Module gives a small SMB:

A named VCAIO who shows up every month for a focused 30-minute working session.
A monthly cadence so AI stays on the owner's agenda even when other priorities are louder.
A 2–3 use case shortlist every month — curated by the platform, not invented from scratch.
An AUP, training rollout, and Continuous Scanner — the same governance artifacts a larger client gets, scaled to fit.
Quarterly AI Recap — async or 30-minute call — so the owner can see ROI movement without committing to a separate QBR.

What the Compass Module costs you in time: 30 minutes a month, plus reading the async digest. That is a smaller commitment than most consultant engagements — and the work compounds because the cadence is recurring.

How Lemhi Makes the Compass Module Profitable at MSP Portfolio Scale

Lemhi makes the Compass Module a standardized, profitable engagement shape — not a custom-built lite version.

Compass Module runbook. 30-minute working session format built into the platform. The VCAIO walks in with the agenda pre-populated.
Async digest automation. Training completion, observability, and survey signal are curated and delivered async before the meeting. The session focuses on decisions.
Use case pipeline scoring scaled to Compass. The platform surfaces a shorter shortlist (2–3 per month) matched to small-team workflows.
Quarterly AI Recap template. Standardized async or short-call output replaces the QBR AI Segment for clients without a quarterly meeting cadence.
VCAIO capacity model. The platform's capacity planning supports mixed books and helps MSPs price Compass engagements profitably.

The Compass Module is how MSPs say yes to the owner-led SMBs they would otherwise have to turn away. It is also how MSPs build a defensible book at the lower end of the market — where competitors are still selling one-off workshops.

Why MSPs Need a VCAIO (Not Just a VCISO) for AI Risk

Tue, 09 Jun 2026 11:00:01 GMT

The Virtual CISO (vCISO) and Virtual Chief AI Officer (VCAIO) are adjacent roles, not duplicate ones. The vCISO owns enterprise security posture and compliance frameworks. The VCAIO owns AI-specific governance — acceptable use, shadow AI, data classification for AI use, and the AI Policy. Where they overlap (data classification, sensitivity labels, identity for Copilot), the two coordinate. The VCAIO does not write the security program. The VCISO does not write the AI roadmap. Both report to the same executive sponsor on shared concerns.

Why MSPs Need a VCAIO and a VCISO to Sell AI Risk

For MSPs, the VCISO/VCAIO boundary is one of the most commercially important distinctions in the 2026 channel. Drawing it correctly lets MSPs sell both practices in the same client without scope confusion. Drawing it incorrectly — collapsing AI into the vCISO motion — leaves significant revenue on the table and shortchanges the client's AI program.

What the vCISO owns:

Enterprise security posture. Risk frameworks, control catalogs, audit readiness.
Compliance frameworks. SOC 2, HIPAA, PCI, ISO 27001, NIST CSF, state privacy laws.
Incident response strategy. Breach detection, escalation paths, regulatory notification.
Vendor risk. Third-party assessments, contract review for security clauses.
Identity and access posture. MFA, conditional access, privileged access management.

What the VCAIO owns:

AI strategy. Roadmap, use case sequencing, Maturity Score.
AI governance. AUP authoring and enforcement, shadow AI inventory, data classification for AI use.
AI adoption and absorption. Training, manager modeling, Council facilitation.
AI observability. Active users, agent invocations, observability vs. survey alignment.
AI-specific incident response. Coordination with VCISO on overlap, but VCAIO leads on AI-specific incidents (model hallucination, prompt injection, data leakage into AI tools).

Where they overlap:

Data classification. Both roles use sensitivity labels. The VCISO sets the classification scheme; the VCAIO applies it to AI use.
Conditional access for Copilot. Both roles coordinate on Copilot identity and access policies.
Shadow AI as a security exposure. The VCAIO leads on AI-tool inventory; the VCISO advises on the broader exposure surface.
Compliance with AI-specific regulation. EU AI Act, NIST AI RMF, state-level AI disclosure laws — joint workstream.

The commercial logic for MSPs: a client paying for a vCISO retainer does not have an AI strategist in the relationship. The VCAIO sells separately. Most SMB AI risk — the AUP, shadow AI, the use case roadmap, the manager-modeling effect — falls in the VCAIO's lane, not the vCISO's. An MSP that sells only vCISO is missing the AI-side practice.

How SMBs Recognize the VCAIO vs. VCISO Boundary in Their Own AI Risk

For SMB executives, the VCISO/VCAIO question shows up as a buying decision: *we have a vCISO. Do we also need a VCAIO?* The honest answer for most SMBs in 2026 is yes — because the two roles are adjacent, not duplicate.

The fastest test:

Who at our MSP owns our AUP? If the answer is the vCISO, the AUP is probably under-developed because the vCISO's focus is broader security posture. The VCAIO is the dedicated owner.
Who runs our Monthly AI Council? The vCISO doesn't run AI Councils. The VCAIO does.
Who tracks our AI Maturity Score? Not the vCISO. The VCAIO.
Who decides which Copilot use cases we ship next? Not the vCISO. The VCAIO.
Who responds when ChatGPT shows up on the network without authorization? Joint — the VCISO on the security exposure, the VCAIO on the AUP and adoption response.

If your vCISO is trying to cover the AI lane, the practice is likely thin in both directions. The vCISO motion gets diluted; the AI motion never gets the dedicated strategist it requires. The fix is naming both roles.

How Lemhi Formalizes the VCAIO/VCISO Boundary for MSP Delivery

Lemhi formalizes the VCISO/VCAIO boundary inside the platform so MSPs can sell and deliver both motions without scope confusion.

Authority-level charter. The Phase 0 engagement charter explicitly maps VCAIO authority (operational, tactical, strategic) and identifies the VCISO coordination points.
Joint governance workstream. The platform supports shared work on data classification, conditional access, and AI-specific compliance — without overlap or duplication.
Council and QBR coordination. The vCISO can attend the Monthly AI Council as a contributor when security topics are on the agenda. The VCAIO can present in the security QBR when AI-specific findings warrant it. Neither role assumes ownership of the other's domain.
PSA integration. Technical remediation findings — whether they originate from the Continuous Scanner (VCAIO) or the vCISO assessment — flow to the same PSA queue, sequenced by impact.
Career path clarity. Lemhi defines distinct competency profiles for VCAIOs and VCISOs, so MSPs can hire and develop for each role specifically.

Selling both motions is the MIP strategy. Selling neither, or collapsing them, is how MSPs leave revenue and client value on the table.

How MSPs Can Sell AI as a Managed Service: The Three Motions Playbook

Thu, 04 Jun 2026 20:22:01 GMT

Selling AI as a managed service means converting one-off AI workshops, assessments, and Copilot rollouts into a recurring retainer that the MSP delivers every month. The repeatable model has three coordinated motions: Transformation as a Service (TaaS) is the commercial wrapper, the VCAIO is the named strategist who runs it, and the Monthly AI Council is the leadership room where decisions land. Together, the Three Motions are the operating playbook MSPs use to turn AI demand into a recurring revenue line instead of a one-time project bill.

How the Three Motions Convert AI Demand into Recurring MSP Revenue

The MSP channel is not short on AI demand. Lansweeper's 2026 research found 90% of MSPs say AI is vital to their business, but only 41% report meaningful integration. Pax8's March 2026 Pulse survey found 84% of SMBs trust their MSP to lead their AI direction. CRN reported Microsoft Chief Commercial Officer Judson Althoff calling managed services partners' AI "superpower." The demand is there. What's missing is a sellable motion.

The Three Motions playbook converts demand into a recurring service line by separating three jobs the MSP has historically tried to do inside one fixed-fee project:

TaaS — the commercial wrapper. A monthly managed retainer that absorbs the Phase 0–3 onboarding work, the same way Managed IT or VCISO retainers absorb initial deployment. Net negative for the first three to four months, strong recurring margin from month five forward.
VCAIO — the named strategist. A fractional Virtual Chief AI Officer who owns the AI roadmap, governs adoption, and reports outcomes to leadership. The role makes the practice possible to scale, because the VCAIO is the answer to "who owns AI at this client?"
Monthly AI Council — the leadership room. A standing 60-minute working session where the VCAIO surfaces decisions, the executive sponsor chairs, and department heads commit owners. The Council is where AI strategy stops being theory and becomes a calendar event.

The reason a single project motion never matured into a service line is that none of the three jobs above gets done well as a one-time deliverable. Strategy compounds over months. Governance requires ongoing enforcement. ROI shows up in quarter three, not week six. The Three Motions match the time horizon of the work to the commercial structure.

The MSP-side conversion playbook is straightforward:

Stand up the role. Name a VCAIO inside the MSP. Define the engagement charter, the authority levels (operational, tactical, strategic), and the capacity standard (12–18 Council clients, 25–35 Compass clients).
Repackage the offer. Convert your existing AI workshop, readiness assessment, or Copilot rollout into Phase 0–3 of a TaaS retainer. Same playbook, different commercial wrapper.
Schedule the cadence. Put the Monthly AI Council on the calendar at engagement kickoff. Schedule the QBR AI Segment inside the existing client QBR. Make the cadence visible from day one.
Standardize the artifacts. Council agenda, QBR AI slide segment, AUP template, AI Maturity Score rubric, observability dashboard — every one of these should ship the same way at every client.
Pick the lead engagement. Convert one existing client this quarter. Use the Council and QBR as proof points. The next ten conversions get easier because the case study is real.

How SMBs Can Tell If Their MSP Is Running the Three Motions

For SMB leadership, the Three Motions are how you tell whether your MSP is selling you a project or a practice. The test fits on one note card.

Do you know your VCAIO's name? If yes, your MSP has named a strategist accountable for your AI program. If no, your AI relationship is informal — and informal relationships drift.
Is the AI Council on the calendar? If yes, you have a monthly forum where AI decisions get made. If no, AI decisions are happening ad hoc — usually in IT tickets and email threads, neither of which produces strategic outcomes.
Does your QBR include an AI segment? If yes, your leadership team sees AI ROI alongside the rest of the MSP's quarterly report. If no, AI is invisible to your board until something breaks.

If two or three of those answers are no, you are likely in a one-off project relationship — and you are likely heading into the Trough of No Value. The Three Motions are the structural fix.

How Lemhi Productizes the Three Motions for MSP Portfolios

Lemhi is the platform that turns the Three Motions from a thesis into an operating system MSPs can run at portfolio scale.

Lemhi Engage (GA June 2026 at Pax8 Beyond) runs the Phase 0 sales motion. AI Leadership Survey, ROI calculator, Plan builder, Tenant Readiness — all unified into a packaged proposal the MSP can take into a client meeting and close as a TaaS retainer.
VCAIO tooling automates the prep work that would otherwise eat the strategist's hours. Observability pulls, training reports, AI Maturity Score updates, use case pre-scoring — the VCAIO walks into Council with the data already curated.
Council and QBR runbooks. The 60-minute Council agenda, the Compass Module 30-minute alternative, the QBR AI Segment slide structure — standardized so every VCAIO at the MSP delivers consistently.
Continuous Scanner. Permissions, sensitivity labels, shadow AI, and sharing risk across M365 surface to the PSA ticket queue every month — keeping technical hygiene moving in the background instead of accumulating as silent debt.

The thesis is the same as Lemhi's founding insight: MSPs don't have an AI tools problem. They have an AI operating-model problem. The Three Motions are the model. Lemhi sells the operating system.

Lemhi Launches the SaaS Platform MSPs Need to Deliver AI as a Recurring Managed Service

Mon, 01 Jun 2026 13:43:38 GMT

Exiting stealth with pre-seed funding from Top Down Ventures, the company is giving Managed Service Providers a SaaS offering and playbook to sell AI as a Managed Service alongside existing Managed IT and Managed Cybersecurity offerings.

INDIANAPOLIS — June 2, 2026 —

Lemhi , the AI Transformation-as-a-Service platform for Managed Service Providers (MSPs), launched out of stealth today. The company closed a pre-seed round led by Top Down Ventures and backed by Lookout Ventures and Start Something Ventures. Lemhi gives MSPs the tools to deliver AI to their customers at scale and turn that work into a recurring book of business.

Today, MSPs are fielding AI questions in every customer conversation, but they can't package the work the way they package everything else they sell. It keeps landing as one-off projects, consulting hours, and tool deployments that never make it onto a monthly invoice.

The demand isn't a problem. Turning it into a repeatable managed service is. Lemhi is built for that, giving MSPs a consistent motion to sell, deliver, govern, and measure AI as part of the same monthly agreement they already run with their customers.

"I've spent 17 years watching MSPs turn every major technology shift into recurring revenue," said John Harden, Founder and CEO of Lemhi. "AI is next, and this time the tools are already in our customers' hands. That makes it an operating model problem, not an AI tools problem. Lemhi gives MSPs the operating model and the software to execute it. The MSP earns a recurring revenue line that doesn't exist today, and the customer finally gets real value out of the AI they're already paying for."

Lemhi Engage, the company's first product, will be available for design partners beginning next week at Pax8 Beyond. It gives MSPs a way to run every AI engagement the same way every time, producing a workforce readiness score, an ROI plan, an M365 tenant assessment, and a phased rollout plan with owners, guardrails, and success metrics already built in. Engage is the front of the operating model: where the MSP scopes the work, sets expectations, and earns the right to run AI as a managed service.

Lemhi's approach supports an emerging category: AI Transformation-as-a-Service. The average MSP can only build custom AI workflows for about 10% of their clients each year, leaving the other 90% untouched. Lemhi flips that ratio. Engage gives MSPs a structure to deliver adoption, governance, strategy, and policy around the AI tools customers already pay for, so every client gets a roadmap, not just the top accounts. “This is the motion that can reach 100% of customers, making sure there are no ‘have nots’ in the client base,” says John Harden.

These “have nots” are a risk to the MSP as they represent future churn or share-of-wallet loss to competitors. Gartner reports that only 28% of AI initiatives meet ROI expectations without a structured, phased program. Lemhi is built to close that gap on a single bet: AI should augment the next generation of workers, not replace them.

Beyond the pre-seed round, Lemhi has been selected into Top Down Ventures' Vibe Studio and ConnectWise's PitchIT accelerator, two of the more selective programs vetting early-stage companies built for the channel. The company is a member of GTIA, Microsoft for Startups, and the International Association of Microsoft Channel Partners (IAMCP), where co-founder and CEO John Harden as the representative for Americas on the International Innovation Committee.

"Every MSP we talk to is feeling the pressure, but most of the activity in the market today is still ad hoc: licenses, pilots, disconnected projects,” said Chris Day, Founder & Chairman of Top Down Ventures. “There’s no durable business model behind it yet. Lemhi is one of the first software platforms we’ve seen that turns this into a structured, repeatable service MSPs can actually scale. That’s why Top Down is excited to invest."

This perspective is shared by the early design partners who have helped craft Lemhi’s product vision.

“AI is creating a new category of business conversation that many MSPs are not naturally equipped to lead,” said Robert Cioffi, Co-Founder of Progressive Computing. “As clients look for guidance on strategy, analytics, and operational impact, there’s a real risk they’ll turn elsewhere for that expertise. Lemhi empowers our team to lead those higher-value conversations and strengthen our role as a trusted business advisor.”

Lemhi is onboarding select cohorts of forward-thinking MSPs over the coming months, giving early partners a head start on a new AI service line before the rest of the channel does. Each cohort works directly with Lemhi's team to scope, price, and roll out the offering across their existing customer base. MSPs interested in joining can add their name to the waitlist at Lemhi.com .

About Lemhi

Lemhi is the AI Transformation-as-a-Service platform for managed service providers. The company gives MSPs a repeatable operating model to sell, deliver, govern, and measure AI as a recurring service line, the same way they run vCIO and vCISO offerings today. Built by MSP operators for MSP operators, Lemhi is defining AI Transformation-as-a-Service as the next recurring selrvice line for the channel.

Visit www.lemhi.com for more information.

AI Transformation as a Service (TaaS): The Managed Service Line MSPs Have Been Missing

Thu, 28 May 2026 01:26:24 GMT

What Is AI Transformation as a Service (TaaS)?

A Guide for MSPs

AI Transformation as a Service, or TaaS, is a monthly managed retainer that delivers AI strategy, governance, enablement, and observability inside an MSP's existing service motion. Instead of selling AI as a one-time readiness project that ends the day the assessment is delivered, MSPs sell TaaS as an ongoing practice that absorbs the up-front work into the retainer and stays accountable for outcomes month after month. In short: TaaS is what AI looks like when you stop billing for it like consulting and start delivering it like managed services.

How Transformation as a Service Reshapes the MSP Revenue Model

For most MSP owners, AI has felt like a category they are losing money on. Clients ask for Copilot. They ask for ChatGPT governance. They ask for "an AI strategy." The MSP scopes a project, sells a fixed-fee assessment, delivers a roadmap document, and then watches the relationship go quiet until the next renewal conversation. The hardest, most valuable work — turning Copilot on, training employees, writing the AUP — gets billed once and never compounds.

TaaS rewrites that motion. The same playbook still runs through the four onboarding phases — pre-contract & ROI, strategy & governance, technical readiness, AI roadmap kickoff. But under TaaS, the MSP absorbs those phases into a retainer. The first three to four months are net negative on margin. From month five forward, the retainer turns into strong recurring revenue — the same shape as a VCISO or Managed IT engagement.

There are three operational reasons MSPs are moving to TaaS:

AI value compounds when the practice stays in place. Microsoft's 2026 Work Trend Index found that 67% of AI's real impact comes from organizational factors — culture, manager modeling, talent practices — not from the tool itself. A one-time project cannot change the organizational factors. A managed practice can.
The bill of materials is repeatable. TaaS standardizes the deliverables across every client: an AI policy first draft in Phase 1, the AI Readiness Assessment in Phase 2, Copilot Quick Wins in Phase 3, then the Monthly AI Council and QBR AI Segment recurring. The MSP isn't reinventing the engagement each time.
It maps cleanly onto MSP economics. TaaS works because MSPs already understand absorbing onboarding cost in exchange for the long tail. The commercial logic is the same as a Managed IT rollout — and the channel knows how to price it.

For an MSP, the most concrete way to think about TaaS is: it's the commercial wrapper that lets you put a VCAIO on the org chart and a Monthly AI Council on the calendar without billing your client for the strategist's existence.

Why SMBs Get More Value from an AI Managed Service Than an AI Project

For an SMB executive, the version of this story is shorter and more honest. You probably already paid for an AI workshop or assessment in 2024 or 2025. You may have a roadmap document somewhere. Your team is still using ChatGPT in browser tabs you don't manage. Copilot licenses sit underused. The ROI you were promised hasn't shown up.

That is the Trough of No Value — the flat customer-value curve that follows any AI readiness project once the consultant walks away. It is not your fault. It is the shape of the engagement.

TaaS is what SMBs get when their MSP runs AI like a service rather than a project:

A dedicated AI strategist (the VCAIO) who shows up every month, owns the roadmap, and reports to your leadership team in language you understand.
A monthly leadership working session (the AI Council) where decisions get made, not just status reported.
Continuous M365 hygiene — permissions, sensitivity labels, shadow AI detection, AUP enforcement — instead of a one-time assessment that's stale within a quarter.
Quarterly visibility into ROI via the QBR AI Segment: maturity-score movement, hours saved, dollars returned, what shipped, what's next.

For SMB leadership, the test of whether your MSP is selling you TaaS versus a glorified consulting engagement is simple: ask them what is included next month. If they can answer in specifics — Council agenda, training module, observability metric, AUP review — you are in a managed practice. If they shrug, you are in a project.

How Lemhi Operationalizes Transformation as a Service for MSPs

Lemhi is a SaaS platform built specifically to help Microsoft-centric MSPs sell, deliver, govern, and prove AI outcomes — without reinventing the playbook for every client. We translate TaaS from a thesis into an operating system.

Engage (GA June 2026) is the sales-enablement module. It runs the AI Leadership Survey, calculates the ROI, builds the readiness score, and produces a packaged proposal the MSP can take into a client meeting and close.
VCAIO tooling automates the prep work — observability pulls, training reports, maturity scoring, use case pre-scoring — so the VCAIO at the MSP can carry 12–18 Council clients (or 25–35 Compass Module clients) without the engagement drowning in manual hours.
The Continuous Scanner runs in the background across every client's M365 environment, surfacing permissions risk, shadow AI, and sensitivity-label gaps to the PSA ticket queue.
Standardized artifacts — AUP templates, Council agendas, QBR slide segments, roadmap formats — mean that the practice ships the same way to every client.

The thesis is straightforward: MSPs don't have an AI tools problem. They have an AI operating-model problem. Lemhi sells the operating model.

Get Weekly Field Notes on AI Transformation for MSPs

Sign up for Field Notes to get weekly advice on everything MSPs need to know to harness AI and become Managed Intelligence Providers.

The Trough of No Value: Why AI Readiness Projects Fail

Wed, 27 May 2026 01:40:17 GMT

The Trough of No Value: Why AI Readiness Projects Fail

The Trough of No Value is the flat customer-value curve that follows an AI readiness project when no managed service is in place. The MSP runs an assessment, turns Copilot licenses on, delivers a roadmap document — and then the engagement closes. The client paid for readiness and never captured the ROI. The trough is the gap between turning AI on and someone keeping it on. It is the single most common failure pattern in SMB AI work in 2026 — and it is structural, not accidental.

Why the Trough of No Value Is the Margin Killer in MSP AI Projects

For MSPs, the Trough of No Value is the reason AI revenue has been hard to convert into AI margin. Most MSPs we talk to have done at least one of these motions in the last 18 months:

An AI readiness assessment scoped as a fixed-fee project.
A Copilot enablement workshop delivered as a half-day session.
A "custom AI strategy" engagement with a six-figure price tag.

Every one of those motions runs into the same trough — because the readiness, the workshop, and the strategy are all front-loaded work. The hardest, most billable hours are at the start. The ROI for the SMB doesn't materialize until months later, and only if someone keeps the practice in place. If the engagement ends at delivery, the value never compounds.

Gartner found that only 28% of AI initiatives meet ROI expectations without a structured, phased delivery model. Prosci's 25-year change-management benchmarking study found organizations are 3.5x more likely to meet transformation objectives when executive sponsorship is active and visible. BCG's 2025 research found that AI success is 70% people and change management, only 10% technology. None of these factors get addressed by a project. All of them get addressed by a practice.

The TaaS reframe is structural:

Same playbook. Pre-contract & ROI (Phase 0), Strategy & Governance (Phase 1), Technical Readiness (Phase 2), AI Roadmap Kickoff (Phase 3) — the same four phases the MSP was already running as a project.
Different commercial wrapper. Phase 0–3 is delivered as onboarding inside a managed retainer, not as a billable kickoff. The MSP absorbs the front-loaded hours, the same way Managed IT or VCISO rollouts absorb initial deployment work.
Recurring cadence after Phase 3. The Monthly AI Council, the QBR AI Segment, the Continuous Scanner, ongoing training rollout, AUP enforcement, use case sequencing — all of it continues every month.

The MSP is net negative on margin for months 1–4. From month five forward, the retainer is strong recurring revenue. The customer value line — flat under a project — climbs every month under TaaS.

The MSP question to ask honestly: *if our last AI engagement at this client ended, what's the next billable interaction?* If the answer is "they have to come back for another project," you're shipping the Trough of No Value.

How SMBs Recognize the Trough of No Value in Their Own AI Investments

For SMB executives, the Trough of No Value usually shows up six months after the project ended. You paid for an assessment. You got a slide deck. Maybe you signed up for some Copilot licenses. Then the IT team got pulled into something else, the champions you identified moved on or got busy, the AUP draft never got finalized, and ChatGPT use crept in through browser tabs nobody is monitoring.

The trough is not a sign that your MSP is bad or that you wasted money. The trough is the shape of every AI readiness project in the market today. It happens because:

The hardest work — getting employees to *actually use* the tools in their day-to-day — happens after the project ends.
Microsoft's 2026 Work Trend Index found 67% of AI's real impact comes from organizational factors (culture, manager modeling, talent practices) — and those factors take months of consistent leadership attention to move.
70% of AI success is people and change management, according to BCG. No project delivers ongoing people work.
Without an executive sponsor pulling the rope every month, employee AI positivity sits around 15%. With active leadership support, it rises to 55% (BCG 2025).

The TaaS answer is to convert the project into a practice. You still get all the same artifacts — the assessment, the roadmap, the policy, the training. But you also get a VCAIO who shows up every month, a Monthly AI Council where leadership decisions get made, and a QBR AI Segment where ROI gets reported. The value line keeps climbing instead of flatlining.

The honest test for SMB leadership: *do you know what your AI practice is delivering next month?* If yes, you're in a managed practice. If no, you're in the trough.

How Lemhi Helps MSPs Close the Trough of No Value with Managed Practice Delivery

Lemhi built the TaaS framework specifically because the founding team — 45+ years of combined MSP and SaaS experience, with two prior MSP SaaS exits — kept seeing the Trough of No Value in their own MSP partners' client books. The pattern was too consistent to be an execution issue. It was a model issue.

Engage (GA June 2026) runs the Phase 0 motion that lets MSPs convert an existing AI conversation into a TaaS retainer instead of a one-off assessment. The product runs the AI Leadership Survey, calculates ROI, builds the Plan + Readiness Score, and produces a packaged proposal.
VCAIO tooling automates the prep so the Council and QBR motions are sustainable across the MSP's full client book. The VCAIO walks into every meeting with curated observability, training, and survey data.
Standardized recurring artifacts — Council agenda, QBR slides, Maturity Score, AUP review cadence — mean the practice keeps shipping the same way every month, every client, every VCAIO.
The Continuous Scanner keeps Copilot and M365 hygiene moving in the background. Permissions, sensitivity labels, shadow AI, sharing risk — all of it surfaces to the PSA ticket queue instead of accumulating as silent debt.

Lemhi's whole product thesis is: the trough doesn't close itself. You have to wrap the project work in a practice. We sell the practice.

What Is a VCAIO (Virtual Chief AI Officer)? The MSP Guide

Tue, 26 May 2026 01:31:19 GMT

What Is a VCAIO (Virtual Chief AI Officer)? The MSP Guide

Why Every MSP Needs a Named Virtual Chief AI Officer

The VCAIO solves the question every MSP owner is being asked in 2026: *who owns AI at this client?* If you can't answer that, you have an account vulnerability. Somebody else will eventually walk in, name a VCAIO, and absorb the strategic relationship.

A VCAIO is not a help-desk role and not a data scientist. The Lemhi VCAIO profile is built on five required competencies:

Executive presence and facilitation — the VCAIO operates the Monthly AI Council and presents in the QBR. Comfort in the leadership room is mandatory.
Microsoft 365 and Copilot fluency — licensing, agent surfaces, governance levers, deep enough to hold a credible conversation with the technical team and the executive sponsor in the same hour.
Change management instinct — AI absorption is 70% people. The VCAIO has to recognize which lever (training, manager modeling, AUP, incentives) to pull when adoption stalls.
Use case judgment — reads the pipeline, scores fit, sequences pilots. Knows when to greenlight a custom agent vs. recommend out-of-the-box.
Governance and risk literacy — articulates the AUP, recognizes shadow AI patterns, coordinates with the VCISO on data classification.

Capacity matters. A VCAIO running full AI Councils carries 12–18 clients. A VCAIO running mostly Compass Module engagements carries 25–35. A mixed book averages around 18–24. These numbers assume the VCAIO is supported by tooling that automates the prep work — observability pulls, training reports, maturity scoring, use case pre-scoring. The judgment work — sequencing, sponsor relationship, in-room facilitation — is the irreducible human layer.

Authority is the second thing MSPs get wrong. Lemhi separates VCAIO authority into three levels:

Operational (Council agenda, QBR content, training cadence, observability config): the VCAIO decides alone.
Tactical (use case pipeline prioritization inside an approved roadmap, agent activation, AUP enforcement consistent with policy): the VCAIO decides; the Council reviews.
Strategic (roadmap revisions, AUP rewrites, executive sponsor changes, spend outside the retainer): the VCAIO recommends; the Council and sponsor decide.

Write these into the engagement charter at TaaS kickoff. Embedded strategists fail when their authority is fuzzy.

What the VCAIO Delivers to SMB Leadership Each Month

If you are an SMB executive, you have already met your VCAIO whether you call them that or not. They are the person on your MSP team who shows up to talk about Copilot, AI policy, and ChatGPT — but until now, that conversation has been informal, occasional, and easy for both sides to deprioritize.

Naming the VCAIO is what makes the conversation real. The VCAIO is your single accountable strategist for AI. They own:

The AI roadmap — what gets rolled out, in what sequence, with what success metrics.
The AI policy — the Acceptable Use Policy gets drafted in Phase 1, revised in Phase 3 once real usage data exists, and reviewed every Council meeting.
The Monthly AI Council — a 60-minute leadership working session that the VCAIO facilitates and your executive sponsor chairs. Decisions made, owners named, observability reviewed.
The QBR AI Segment — a 10–15 minute block inside your existing quarterly business review. Maturity-score movement, Copilot adoption, ROI metrics, next-quarter priorities.
The sponsor relationship between Councils — the VCAIO is available for unblock conversations when a decision can't wait a month.

The fastest test of whether you have a real VCAIO: can you name them? If yes, you have a strategist. If no, you have an AI vendor.

How Lemhi Helps MSPs Stand Up a VCAIO Practice at Scale

Standing up a VCAIO practice is hard from scratch. Lemhi's platform is designed to make it standardized and repeatable across an MSP's book of business.

Pre-built role artifacts. Engagement charter templates, authority-level boundaries, capacity standards, and the five-competency profile — all standardized so that every VCAIO at your firm delivers the same way.
Automated prep. Observability pulls, training reports, AI Maturity Score updates, and use case pre-scoring are continuous in the platform. The VCAIO walks into Council with the data already curated.
Council and QBR runbooks. The 60-minute Council agenda, the QBR AI Segment slide structure, and the Compass Module 30-minute format are built in.
The Compass Module. For clients too small for a full Council, Lemhi runs the lighter Compass cadence — same VCAIO, same roadmap, fewer hours, lower cost to serve.
Career path for the VCAIO. Because the platform handles the repetitive prep, your VCAIOs can specialize on the parts of the role that compound — sponsor relationships, in-room judgment, use case sequencing.

Adding a VCAIO is how MSPs go from "we do Copilot rollouts" to "we own the AI relationship." Lemhi is how MSPs do it at portfolio scale.

AI Practice vs. AI Program: The Distinction That Makes MSPs Profitable

Wed, 20 May 2026 01:58:48 GMT

AI Practice vs. AI Program: The Distinction That Makes MSPs Profitable

The AI Practice is the commercial offering an MSP sells — the packaged, repeatable service the MSP delivers across its client book. The AI Program is the portfolio of AI work, owners, outcomes, and policies that the client runs internally. The MSP's AI Practice supports the client's AI Program. Lemhi's vocabulary deliberately separates the two because mixing them is the most common cause of scope creep, margin erosion, and accountability confusion in MSP AI work.

How the AI Practice vs. AI Program Distinction Protects MSP Margin

For MSPs, the Practice/Program distinction is a survival tool. Without it, every client conversation drifts into questions like "can you also help us with this internal initiative" — and the MSP either says yes and loses margin or says no and damages the relationship. With it, the boundary is clear: the MSP delivers the Practice, the client owns the Program, and the VCAIO is the connective tissue.

What the Practice owns:

The commercial structure. Pricing, scope, SLAs, escalation paths.
The named role. The VCAIO who carries the relationship.
The recurring artifacts. Monthly AI Council, QBR AI Segment, AI Maturity Score, AUP, Continuous Scanner output, training rollout.
The standardized playbook. Phase 0–3 onboarding, ongoing cadence, exit criteria.

What the Program owns:

The strategic intent. Why the client is investing in AI, what outcomes they want, what risks they will not accept.
The internal owners. The executive sponsor, the department heads, the AI Champions inside the client.
The decisions. What the Council decides goes into the Program — but the Program is what executes against those decisions.
The accountability. When AI helps or hurts the business, the Program is where the consequences land.

The VCAIO is accountable to the MSP for delivering the Practice and accountable to the client for advancing the Program. Both lines of accountability are visible in the Monthly AI Council and the QBR AI Segment.

Where MSPs lose money: when they accept Program-side work (custom agent builds, departmental AI projects, internal change-management initiatives) inside the Practice retainer without re-scoping. The fix is not refusing the work — it is expanding the retainer or selling a separate project alongside the Practice.

What SMB Leaders Should Know About AI Practice vs. AI Program Ownership

For SMB executives, the distinction is the answer to a question your team is probably asking quietly: *who owns AI here, us or the MSP?* The answer is: you own the Program, the MSP runs the Practice that supports it. Both roles are real.

What this means concretely:

You own the strategic outcomes. AI is your investment, your risk, your competitive advantage. Your executive sponsor signs the budget; your department heads commit owners; your employees do the work.
The MSP owns the operating discipline. The VCAIO shows up every month. The Council convenes. The QBR reports ROI. The AUP gets revised. The Continuous Scanner runs. The training ships.
The handshake is the Monthly AI Council. That is where the Practice and the Program meet — where the MSP's standardized motion produces decisions the client's leadership team commits to.

If your AI relationship feels confused — if you can't tell whether you or the MSP "owns" a particular decision — the fix is to articulate the boundary in the next Council. Most ambiguity disappears once Practice and Program are named separately.

How Lemhi Enforces the AI Practice and Program Boundary in MSP Delivery

Lemhi enforces the Practice/Program distinction inside the platform — which keeps MSPs profitable and clients aligned.

Standardized Practice artifacts. The Council agenda, the QBR AI Segment slides, the Maturity Score rubric, the AUP template — all standardized so every Practice ships the same way.
Engagement charter. Phase 0 produces a written charter that names the boundary between Practice and Program. Owners on both sides are documented at kickoff.
VCAIO authority levels. Operational, tactical, and strategic decisions are pre-delegated or escalated based on the charter — so the VCAIO never has to negotiate authority mid-conversation.
Scope-creep guardrails. When Program-side work emerges (custom agent builds, large training initiatives, departmental projects), the platform flags it as outside Practice scope and prompts a re-scope conversation.
Compass Module for the Practice/Program edge case. At very small clients, the Practice/Program distinction collapses into the owner-operator. The Compass Module is designed for that reality.

The distinction is not pedantic. It is the operating discipline that makes the difference between an MSP that scales AI revenue and one that bleeds margin on every engagement.

The Managed Intelligence Provider: What Comes After the MSP

Tue, 19 May 2026 01:55:53 GMT

The Managed Intelligence Provider (MIP): What Comes After the MSP

A Managed Intelligence Provider, or MIP, is the next-stage evolution of the MSP. The MIP owns the AI practice for every client at portfolio scale — operating Transformation as a Service, naming a VCAIO inside every relationship, running Monthly AI Councils, reporting AI ROI in every QBR. The MIP category is the natural successor to Managed Services and Managed Security: where the MSP owned uptime, and the MSSP owned security posture, the MIP owns the strategic intelligence layer.

How MSPs Become Managed Intelligence Providers in 2026

For MSPs, becoming a Managed Intelligence Provider is the maturation arc the channel has been working toward since AI demand became unavoidable. The MIP framing answers a question every MSP owner has asked: *what's our category in three years if AI is in everything?*

The arc tracks cleanly with prior generations of managed services.

Managed Services (2000s–present) owned uptime. The pitch was "we keep your IT running so you can focus on your business."
Managed Security (2010s–present) owned security posture. The pitch was "we manage your risk so you can focus on growth."
Managed Intelligence (2026 and forward) owns the AI practice. The pitch is "we own your AI transformation so you absorb AI into how work gets done."

Becoming a MIP is not about adding an AI line item to the SOW. It is about restructuring the business around three operating motions: TaaS as the commercial wrapper, the VCAIO as the named strategist, and the Monthly AI Council as the leadership room. That structural change is what produces the MIP outcome.

Why this matters for MSP economics:

Recurring revenue. TaaS retainers compound. Adoption-as-a-project does not.
Defensible client relationships. Once a VCAIO is named and the Council is on the calendar, displacement risk drops. The competing MSP has to displace a strategist, not just a vendor.
Higher contract value. MIPs sell at higher ACV than traditional MSPs because the practice carries more strategic weight inside the client's leadership team.
Talent retention. MSPs that name a VCAIO role create a career path that retains senior delivery talent. Talent that has nowhere to go inside the MSP eventually goes elsewhere.

The channel context: Pax8 Pulse research found 84% of SMBs trust their MSP to lead their AI direction. CRN reported Microsoft's Judson Althoff calling managed services the partners' AI "superpower." Lansweeper found 90% of MSPs say AI is vital but only 41% report meaningful integration. The market is ready for the MIP transition. The question is which MSPs move first.

Why SMB Buyers Should Look for a Managed Intelligence Provider

For SMB executives, the MIP distinction is most useful as a buying criterion. When you are evaluating an MSP for AI work, the question is no longer "do you support Copilot?" — every MSP does. The question is whether the MSP is operating as a Managed Intelligence Provider.

The MIP test fits on a short checklist:

Do they offer Transformation as a Service (or an equivalent monthly managed retainer that absorbs onboarding), or do they price AI as a fixed-fee project?
Do they name a VCAIO as part of the engagement, or is the AI conversation distributed across whoever picks up the phone?
Do they run a Monthly AI Council with your executive sponsor, or do AI decisions happen in IT tickets?
Do they report AI ROI in your QBR , or is AI invisible to your board?
Do they operate a Continuous Scanner against your M365 environment, or do they assess once a year and call it done?

If the answer to most of those is no, your MSP is still operating as a Managed Services Provider. That may be fine for your IT needs. It is not fine for your AI program.

How Lemhi Powers the Managed Intelligence Provider Transition

Lemhi is the operating-model SaaS that makes the MIP transition possible at portfolio scale. The platform was built specifically because the Lemhi founding team — 45+ years of combined MSP and SaaS experience across two prior MSP SaaS exits — kept seeing MSPs try to make the transition without the operating system underneath.

Lemhi Engage (GA June 2026) runs the Phase 0 sales motion that converts a traditional MSP-client AI conversation into a TaaS retainer. The output is a packaged proposal the MSP closes as Managed Intelligence revenue, not as a one-time consulting bill.
VCAIO tooling makes the named strategist role sustainable across 12–35 clients depending on engagement mix. Without automation, the VCAIO role does not scale.
Standardized Practice artifacts — Council agenda, QBR slides, Maturity Score, AUP template — mean every MIP engagement ships the same way. Standardization is what separates a practice from heroics.
Continuous Scanner maintains M365 hygiene continuously, surfacing findings to the PSA queue. The Scanner is what keeps the MIP relationship strategic instead of reactive.
Career path for VCAIOs. Because the platform handles the repetitive prep, MSP delivery talent can specialize on the parts of the role that compound — sponsor relationships, in-room judgment, use case sequencing.

The thesis is direct. The MSP category is moving toward Managed Intelligence whether or not individual MSPs make the move deliberately. Lemhi exists to make the deliberate move repeatable.

Why We Wrote an Open Source AI Framework For the Industry

Wed, 25 Mar 2026 00:15:59 GMT

Write about something you know. If you don’t know much about a specific topic that will interest your readers, invite an expert to write about it.

One of the reasons AI feels so messy in the MSP world is simple. There isn’t a real framework.

Not a shared one.

Not a practical one.

Not something people can actually ground decisions in.

What exists instead is a mix of vendor narratives, half‑borrowed security models, and a lot of well‑intentioned guesswork. Everyone is trying to build structure at the same time they’re trying to figure out what AI even is in their business.

That’s a hard way to operate.

Most of what I see today isn’t really a framework. It’s paperwork layered on top of uncertainty. An attempt to look organized before there’s anything stable underneath it.

And that’s not a knock on effort. It’s just what happens when there’s nothing solid to anchor to.

This is actually why I ended up writing the Lemhi AI framework at all

Not because I wanted to introduce another abstraction, but because there wasn’t one to start from. There was no common language. No baseline for what “good” even looked like. No way to evaluate tools without starting from scratch every time.

Everyone was picking tools first and trying to justify them later. That’s backwards.

Without a framework, every AI decision feels heavyweight. Every new tool creates debate. Every customer conversation turns into a custom explanation. And every internal discussion becomes philosophical instead of practical.

A real framework does the opposite.

It gives you a place to stand.

It makes tradeoffs obvious.

It lets you evaluate tools against something instead of reacting to them emotionally or defensively.

Once we accepted that a framework was needed, the next decision was obvious. It had to be open .

If this lived behind a product, a paywall, or a consulting engagement, it would immediately lose credibility. It would feel like positioning instead of structure. Another opinionated take instead of a shared starting point.

That was the opposite of the goal.

The intent here is not to “win” the AI framework debate. It is to start it and open it to the community.

Open source forces discipline. Anyone can inspect it. Anyone can challenge it. Anyone can fork it. If something does not hold up in the real world, it gets exposed quickly. That is a feature, not a risk.

It also keeps the framework honest. The moment it turns into a sales asset, it stops being useful as a control system. MSPs already have enough vendor shaped narratives telling them how AI should work. They do not need another one.

So we gave it to the community and have decided to own changes. My take on it? You do not need to believe everything in it. You just need a place to stand.

If you have spent time in cybersecurity, the structure will feel familiar. That is intentional.

CIS works not because it is perfect, but because it respects how organizations actually adopt things. It recognizes that maturity is staged. That not every control matters on day one. That sequencing matters more than ambition. AI adoption follows the same pattern.

There is a massive difference between “we are experimenting” and “this is now part of how work gets done.” Treating those two states the same is how organizations either freeze or move too fast.

So instead of inventing something new, we copied the part that already worked.

What can you expect?

Implementation Groups.

IG1: Baseline – What must exist before AI is considered real

IG2: Scale – What prevents drift as adoption grows

IG3: Advanced – What only matters once AI is embedded into sensitive workflows

This is not about slowing teams down. It is about giving them permission to start honestly where they are.

Pillars

Pillars are not categories for organization. Each one maps to a failure mode we kept seeing in real environments.

Most AI problems are predictable. Missing ownership. Unclear data boundaries. No visibility. No rollback path. Pillars force teams to confront the parts they usually assume away.

What Each Pillar Represents

Each pillar answers a different “what breaks if we ignore this” question:

Strategy & Buy‑In – Who owns AI and why it exists

Policy & Governance – What is allowed, what is not, and how exceptions work

Technical Readiness – Whether the environment can actually support AI

Process Mapping – Where AI fits into real work, not demos

Data Security & Tagging – What data AI can see and what it never should

AI Observability – Whether usage, cost, risk, and quality are visible

Copilot Readiness – How Microsoft Copilot expands safely and deliberately

AI Tooling & Deployment – How pilots become production without chaos

Skipping a pillar usually shows up later as noise, risk, or rework.

What’s Inside Each Control

Every control is written to be executable, not theoretical.

Each one includes:

A clear objective

A concrete requirement

A defined cadence

A named owner

Evidence you can actually produce

Controls are not pass or fail judgments. They are orientation points. They tell you what matters now, what can wait, and what you should not skip.

The point of the framework is simple.

AI should feel boring once it is working. Owned. Governed. Measured. Improved over time.

If it does not, something upstream is missing.

Most MSP Problems Aren’t Technical, and AI is the Least of IT All (In your customer’s mind...)

Wed, 18 Mar 2026 00:16:00 GMT

There are so many good reasons to communicate with site visitors. Tell them about sales and new products or update them with tips and information.

The more conversations I have with MSPs about monetizing AI, the less convinced I am that their biggest problems are technical.

They feel technical. They show up as tool debates, platform decisions, AI comparisons, and architecture questions. What bothers me is everyone treats this AI problem like an engineering problem that just need better tools.

But that’s not actually where things break down.

What I hear most often isn’t “this tool doesn’t work.”

It’s “we’re not sure what to use.”

Or “we’re still testing a few things.”

Or “we don’t really know how to talk about this with customers yet.”

That last part matters more than people want to admit.

A lot of this came up in recent coffee chats. Someone will say they’re looking at Copilot, but also using ChatGPT, and then another AI product their vendor just showed them. They’re trying to decide which one to standardize on, whether they should offer multiple options, or whether they should even be selling AI at all yet.

None of that is a technical limitation. It’s a clarity problem.

MSPs don’t lack tools. They lack conviction.

Every option sounds plausible, and in a lot of cases they ARE plausible. Every vendor has a story. Every demo works in isolation. And because everything might be important, nothing gets fully committed to.

So teams keep evaluating. They keep experimenting. They keep waiting for the moment when it all becomes obvious. And in the meantime, selling AI feels hard.

But that is absolutely not because customers don’t want it. But because MSPs don’t know how to explain it without talking tools. That’s the part I think a lot of people miss. Selling AI isn’t hard because the technology is complex... iIt’s hard because the narrative is unsettled.

If you’re not clear on what AI is in your stack, what problem it actually solves, and where its limits are, then every sales conversation turns into a ramble. You hedge. You over‑qualify. You list tools instead of outcomes.

Customers feel that.

And when the story isn’t clear, trust doesn’t form. Deals stall. AI gets positioned as “interesting” instead of “necessary,” or they go on their own way and solve their own problems. AI isn’t a particularly difficult one to self-service, so that’s the path of least resistance.

That’s not a sales failure. That’s a prioritization failure.

Most MSPs don’t need better pitch decks or smarter demos... They need stronger filters.

They need to decide what they believe. They need a default answer. They need to say no to a lot of things so the yes actually means something.

That’s where ecosystems start to matter.

An ecosystem reduces choice. It forces consistency. It gives your team shared language instead of a dozen different explanations depending on which tool someone last tried.

When the internal story stabilizes, selling gets easier. Not slicker just clearer. Most MSP problems aren’t technical. And most MSP AI sales problems aren’t either. They’re narrative problems. They’re clarity problems. They’re commitment problems.

AI didn’t create that. It just exposed it. And until that’s addressed, no new tool is going to make AI easier to sell. It’ll just add another option to an already crowded list.

This is where my skepticism keeps leading me.

The real question isn’t how do we sell AI? It’s what are we actually willing to stand behind?

Once that’s clear, the rest starts to quiet down.

In an AI World Full of Noise, I’m Being Skeptical on Purpose

Wed, 11 Mar 2026 00:16:00 GMT

The new season is a great reason to make and keep resolutions. Whether it’s eating right or cleaning out the garage, here are some tips for making and keeping resolutions.

I’ve been labeled skeptical a bit recently around AI. I’m fine with that.

But it’s worth saying what that skepticism actually is (and what it isn’t).

I’m not anti‑innovation. I build things for a living. I like new ideas. I like progress. I like when technology actually moves the ball forward. What I’m against is noise. And right now, MSPs are drowning in it.

Every cycle brings a new framework, a new model, a new set of tools, a new abstraction layer that promises to “change everything.” The language is confident. The diagrams are clean. The demos are impressive. And yet, when you step back, a lot of it doesn’t survive contact with reality.

That’s where my skepticism comes from. I’ve been in this space for 15+ years. I know what the beginning of a cycle looks like. It often follows the same patterns and the same experimentation. And for a decade and a half, it’s mostly landed in the same ending position, whether cloud, cyber, or AI: repeatable and monetizable at scale.

I don’t start by believing vendors. I don’t start by assuming the abstraction is necessary. I don’t start by trusting that because something is popular, it’s useful. I start by asking a much more boring question: Does this actually hold up when you try to run it, scale it, support it, and charge money for it?

Most things don’t fail because they’re bad ideas. They fail because they’re fragile, expensive, hard to explain, or impossible to operationalize. Or they only work under perfect conditions that never exist outside a demo. And in today’s era, with the break neck speed that things get done, none of that is acceptable.

I think a lot of people miss this. Especially in AI.

There’s a temptation to treat intelligence as magic instead of infrastructure. To stack more layers, more orchestration, more cleverness on top, and assume value will appear. But intelligence that can’t be repeated, governed, or monetized isn’t progress. It’s a science project, and its irresponsible if you’re doing it in your customers environments.

Healthy skepticism is how you protect yourself from that.

It forces you to slow down and separate what’s interesting from what’s durable. What sounds smart from what actually compounds. What helps one team ship a demo from what helps an organization operate at scale. And it’s the exercise you need to stop feeling so overwhelmed with the noise.

This is where my head goes with it: if something can’t be explained simply, deployed repeatdely, and improved incrementally, it’s probably not ready.

So yes, I’m skeptical. On purpose. Because skepticism is how you calm the noise. And once the noise is gone, the real work can start.

Look forward to sharing more of my learnings soon! (They’ll be a little less skeptical, I promise)