How I'm bringing AI L1 technicians to Syncro MSPs.

See it work

A real password-reset ticket, hands-off in 90 seconds.

A locked-out user opens a ticket in Syncro. Within 15 seconds, the dispatcher classifies it as a password reset and routes it to the specialist agent. The agent verifies identity, resets the password, and updates the ticket. No human touch required.

What you're seeing is one deploy pattern: customer portal + secondary email loop for identity verification. That's our default ship because most Syncro MSPs already have those pieces in place. Different environment? Different verification flow works fine. No portal, SMS instead of email, AD lookup against your domain, your own escalation path. The dispatcher and specialist pattern stays the same. Only the verification step adapts to what you actually have.

The problem

Half the L1 queue is the same handful of categories.

Run an MSP on Syncro and you know the shape: 2,000–3,000 tickets a month, and a depressing portion of L1 volume is the same handful of categories. Industry data has consistently put password resets and account lockouts alone at 20–35% of help-desk volume. Gartner has been citing the 20–50% range for years, and more recent MSP-segment surveys land around a third. At the MSP where I built this, the rest of the L1 mix was the predictable shape every Syncro shop will recognize:

• Password resets and account lockouts: by far the largest single category, consistent with the 20–35% industry figure
• M365 user lifecycle work: new-hire onboarding, offboarding, license changes, mailbox handoffs (volume varies enormously by client churn)
• Distribution list and group membership changes: small ticket count, but every one is a quick win that doesn't develop your tech
• Printer issues: the canonical complaint that's almost never actually about the printer

Together these four are easily half of the L1 queue at most small-to-mid MSPs running M365-centric stacks. They're repetitive, procedural, and consume your L1's time on work that doesn't develop their skills or grow your business. They're also the categories where customers expect near-instant resolution, but a human L1 in a small shop can't deliver that during peak hours.

The standard MSP playbook for this is some combination of: scripts that handle the easy 20% but break on edge cases, hiring a second L1 (expensive, and they leave), outsourcing to a BPO (cheap but quality is uneven and clients hate the language barriers), or building automation in Make/Zapier with limited LLM integration.

None of these solve the actual problem, which is: an L1 ticket queue is a natural-language problem, not a workflow problem.

Why AI-native, not "automation"

Everything routes through a language model first, not string matching.

The reason this works where traditional automation struggles: everything routes through a language model first, not through string matching.

Concrete example: adding someone to a distribution list. Traditional automation needs the exact list name and the exact user identifier. If the ticket says "add Sarah to the marketing DL" instead of "add sarah.thompson@client.com to Marketing-Team@client.com," the script fails. If it says "the marketing list" or "marketing alias," it fails. If it says "markeitng" with a typo, it fails.

An LLM-based tech handles all of these. It looks up Sarah's actual address from Graph, resolves "the marketing DL" against the actual group list (handling misspellings, nicknames, and shorthand naturally), confirms the match, and executes. Same for groups, security policies, shared mailboxes, license assignments. Edge cases that break wildcard-based automation just resolve naturally.

And when the lookup is genuinely ambiguous, say there are two plausible "Sarahs" or two distribution lists with similar names, the tech writes back to the requesting user with the candidates and asks which one they meant. Just like a human technician would on the same ticket. It's not brute-forcing a guess.

It knows when to ask.

That's the actual unlock. Microsoft adding native AI features to their admin tools is interesting, but it's a different problem: those tools assume the user knows what they want inside the admin console. An L1 ticket is the opposite. A customer typing what they need in plain English, and the work is figuring out what that actually means in M365/AD/Syncro terms.

Why we're not an "AI helpdesk"

No migration. No rip-and-replace. Just techs inside your Syncro.

Most "AI helpdesk" vendors are selling you a new platform. New ticketing system, new client portal, new workflows, new training, new everything. The pitch is always "the destination is worth the migration."

Maybe. But every MSP owner who's actually done a platform migration knows it's an 18–24 month project that often never fully completes. New helpdesks get bought; old helpdesks rarely get fully decommissioned. You end up running two systems, with techs who default back to the one they know.

Prismatic is structured differently. We don't sell you a platform. We sell you AI-powered techs that plug into the Syncro instance you already have. Each tech does a specific job: passwords, DLs, M365 admin, ticket triage, knowledge-base answers, dispatch. They run 24/7. They don't quit. They cost less per month than a human L1 hire costs per week.

You keep your Syncro. You keep your workflows. You keep your client portal. You keep your billing setup. You keep your contracts. You just add L1 capacity, the way you'd add a human hire. Except this one is already trained and already integrated.

No migration. No rip-and-replace. No 2-year project. Just a tech that works for you.

What proved out

The honest accounting.

Honest accounting of what actually went into production versus what was built and demonstrated:

Spanish-to-English translation: live in production. Eliminated the bottleneck of routing Spanish tickets to one specific tech and removed the team's dependence on Google Translate for context. This was the clearest single win. Every Spanish ticket got translated automatically the moment it hit the queue, with the original preserved in the audit trail.

Dispatcher: built and operational. The architecture for routing tickets to specialist techs worked as designed. Tickets came in, got classified, and got handed off to the right tech.

M365 onboarding/offboarding, password reset, DL management, and printer triage techs: built and demonstrated. All wired to MS Graph for the actual operations, all working end-to-end in test conditions, all reporting back to Syncro tickets correctly. None of these reached unattended 24/7 production before the role ended.

I'm not going to claim numbers I don't have. The Spanish translation tech saved real time and frustration. The rest worked in demonstration but didn't run long enough to generate the kind of metrics a buyer would want.

The honest framing is: the architecture is proven, the techs are built, and Prismatic is the productized deployment for MSPs that want to run this in production from day one.

Why now, why me

I built this stack at one MSP. I want to deploy it at others.

I built this stack at one MSP. I want to deploy it at others. The Syncro and MS Graph integration code is already written; Prismatic is the wrapper that delivers it to MSPs that don't have an in-house developer to build it themselves but absolutely want the outcome.

If you run a small or mid-size Syncro MSP and any of this resonates, I'd value a 15-minute conversation. Not pitching, just validating. I'm running 10–15 of these conversations over the next few weeks to make sure what I'm productizing is what MSPs actually want, before scaling outbound.