What to Get Right Before You Point AI at Your MSP, By Jasper Grewal

The following is a guest post from Jasper Grewal, owner of ROI Technology and a member of Syncro’s Partner Advisory Council. Jasper builds on top of the Syncro MCP server and helped shape our first Service Desk plugin for Claude, so we asked him what an MSP should get right before connecting these tools to its business. Read on to learn more.

First, the Foundation

Your techs are already using AI. So are your clients. Most of them did not ask first.

We run about ten people plus contractors, 30 to 40 clients, and a little over a thousand endpoints, mostly in Washington state. B2B only. A good chunk of our book sits in verticals with compliance frameworks attached, everything from law firms and financial advisors to higher education and aerospace. So when I say people will use these tools whether you approve them or not, I mean I have watched people try it on networks where the paperwork says they can’t.  

You could spend the next year picking tools. I would spend it on something else.

The tooling is temporary. Your standards are not.

Plugins and skills are going to matter a lot for MSPs over the next couple of years. I build plugins today, but I expect the next generation of models will natively handle most of what today’s plugins do. Most of what a plugin consists of is structured prompting to get (mostly) consistent output and subject matter-specific context. 

That context is the durable part. Today’s models aren’t aware of how your shop runs, what you promised in your MSAs, or which client cannot tolerate a reboot before 6 pm. You can certainly give today’s models context about your specific business, but that gap does not close on its own, and it is the thing worth investing in right now. 

So build the layer that outlives the tool.

1. Write the policy document

Decide what your standards are as an organization and put them in writing. Not a wiki page somebody wrote once. An actual document covering how you name things (workstation vs endpoint), how you handle client data, what you will and will not automate, and what requires a human approval step.

Put it somewhere with version control. We use GitHub. The format matters less than the history, because in six months you will want to see what changed and why.

Treat it as a living document. It gets better every time something bites you.

Now the part that makes it pay off. Reference it at the start of every project. My first message on any build is some version of “bootstrap this project, here is our policy document.” These models do noticeably better work when you hand them your reference material instead of hoping they infer it from fragmented memories. This one habit has done more for our output quality than any prompt trick you’ll find online.

If you do nothing else on this list, do this one.

2. Close the doors you can actually close

Block unapproved LLM domains at the network level. For our compliance-heavy clients we standardize on Microsoft Copilot and block everything else, so an employee cannot start a personal account and begin pasting sensitive material into it.

Then claim your domain with the providers. You can lock down Anthropic and OpenAI accounts so nobody spins up a new tenant with a company email address. They have to come to whoever owns it and ask. This takes an afternoon and it closes the most common hole.

Your clients need this more than you do. Most of them have decided they want an assistant and will go get one themselves. We give them a system prompt to start from, run an account review to lock the settings down, and steer them toward a savvy internal champion, because most will not pay for a seat so we can administer it. Do it for your own shop first, then sell it.

3. Train people, because the controls don’t exist yet

This is the part nobody wants to hear. None of the providers give you real organization-level content control. You can claim your domain, force SSO, turn off retention, and set a system prompt. None of that touches what a user actually types. 

So the control has to be the person. Models can be talked out of the best written system prompts, so it’s up to us to make sure everyone knows what these tools are approved for, and what they aren’t. Write it down in your living policy document, but more importantly, walk people through it.

4. Turn off training, and be honest about what you are trusting

Go turn off the training and retention options in every account you own. Then sit with the uncomfortable part. You are trusting the provider to do what they say they’re doing. Normally we say “trust but verify” – but in this case, there is no ‘verify’ step you can run yourself. 

I have made peace with that, because the product doesn’t work unless you trust them. Say that out loud to your clients instead of implying a guarantee you can’t enforce. Repeat it during business conversations (whether that’s a QBR, or something more frequent).

5. Assume it breaks differently next month

We have been building a skill for quick QBR reports. Partway in, file downloads stopped behaving the way they had. Same request, different result, no announcement. We worked around it.

The lesson is not that particular bug. It is that provider behavior changes constantly, so build with flexibility in mind. 

What it looks like when the foundation is there

Our first real skill came out of level 1 techs raising their hand on tickets outside their skill set. Now a junior runs the research themselves and brings us something we can react to. Fewer questions reach me now, which probably means fewer overall crossing the level 1 -> 2 boundary. I’ve also heard level 2 techs comment that the research skill surfaced ideas they had not considered. I should be tracking this more rigorously than I am, and that is fair criticism – but anecdotally, it’s working. 

The one my team actually reacted to was onsite prep. When you are a two man shop with a few clients you know what is out there. When you’ve grown to a 30 or 40+ client shop, with your entire team remote, two techs driving to the same client on different days for different tickets is an inefficiency you can’t afford. I watched it happen, for silly things like monitor moves. Now before someone heads out they can ask what else is open at that site, including tickets outside their default view in Syncro, and with the added context the plugin or skill brings to the table, the model can surface every ticket that needs onsite work at the client without waiting for the rest of the team to look.

None of that needed a new tool. It needed us to decide on a standard, and provide the context. 

Why I am not keeping this to myself

Fair question. 

Knowledge is power, but how you use that knowledge is just as important as having it. 

What we are building depends on Syncro’s MCP server being good today and getting better tomorrow. If those of us doing the work don’t engage with our vendors, they cannot know what we need, and every one of us stays stuck reinventing the same wheel privately. I would rather build something good together now that becomes the foundation for something better later.

This philosophy changed how I deal with vendors generally. For the last couple years I have gone into every “quarterly account sync” conversation with every vendor we use, not as a buyer, but with a simpler frame: here is what your product does that makes us pay you today, and here is what would keep us paying you tomorrow. I also ask all of them whether they have a partner advisory council, and if not, why not.

Where to start

• This week. Claim your domain with every AI provider you use, and turn off training in those accounts.
• This week. Block unapproved LLM domains on your own network before you sell that to a client.
• Next two weeks. Write version one of the policy document and put it in version control. Update the document when the model shifts under you, or your needs change. 
• Every project after that. Hand the model your policy document before you ask it for anything.

None of this is the interesting part of AI. It is the part that decides whether the interesting part works.

Share

• Share on Facebook
• Share on X
• Email this Page