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

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)