Claude recommends buying vs. building
We had a demo call recently with an MSP that had an all-too-familiar problem: an enterprise customer, a UK-based ServiceNow team on the other side, and a service desk drowning in manual work trying to keep two systems in sync by email.
Before we got into any of that, though, we asked the question we always ask: how did you find us?
“I was trying to vibe code my own solution, and Claude pointed me in your direction. Claude’s a good asset. He was like, why are you wasting your time with this? You should speak to these guys.” -MSP integration lead, on a recent demo call
We’d love to see that exchange ourselves. But it’s hard to argue with the advice.
The setup
The MSP had built a solid customer portal experience: a stack of custom forms their client’s staff could use to raise requests, which land as tickets in the MSP’s ConnectWise instance. For most of those tickets, that’s the end of the story. But a subset need to be visible on the customer’s own ServiceNow instance too, because that customer runs a large, UK-based ServiceNow team who own their side of the relationship.
Twelve months ago, the answer was email. Someone raises a ticket, someone else forwards the details across, and both service desks do their best to keep the two records lined up by hand. It’s the same pairing we walk through in ConnectWise to ServiceNow in under 12 minutes - just without the manual re-keying.
That was never going to last. Email doesn’t hold up as an integration layer once real volume shows up: it doesn’t carry attachments cleanly, it isn’t bi-directional, and any update on either side means someone manually re-keying it on the other. As the relationship matured and volume grew, keeping the two systems in parity became a real drag on the service desk, not an occasional annoyance.
This is close to the most common shape of problem we see in co-managed IT: a portal or PSA that owns ticket intake, and an enterprise or government customer that needs some of those tickets mirrored into their own ITSM platform, on their terms, because that’s what their governance model requires.
Why vibe code an integration when someone can build and maintain it for you
The instinct to reach for an AI coding tool and knock up a sync script is understandable. The APIs are documented, ServiceNow and ConnectWise are both well-worn platforms, and it feels like a weekend project.
It isn’t, and this is exactly the gap Claude picked up on. We’ve written about this before: a hand-rolled integration can move a ticket from A to B. What it can’t easily do, without a lot of unglamorous engineering, is:
- Stay in sync bi-directionally, so a status change or comment on either side reflects on the other without someone watching for it
- Carry attachments, rich text, and full comment history across cleanly, rather than a stripped-down summary
- Survive the two platforms’ independent release schedules, rate limits, and the occasional API change that breaks a hard-coded assumption
- Hold up under real production volume, where a bulk status update on one side can fire dozens of sync events at once
- Answer the governance questions an enterprise security team will ask before they’ll sign off on data crossing a company boundary
None of that is a reason to avoid the integration. It’s a reason to buy the part that’s already been built, tested, and hardened by someone who does nothing else, and spend the engineering time on the parts of the business that are actually differentiated.
That’s the whole premise behind Support Fusion: a platform purpose-built for exactly this pattern, running in Australia, the US, and the UK across dozens of live customer connections, ISO 27001 certified, with support for filtering which tickets are in scope, mapping custom fields, and carrying a reference number back to the source ticket. Set it up once, and it’s someone else’s job to keep it running.
Why this matters beyond one MSP
If you’re an MSP fielding requests through your own portal or PSA, and any of your customers run their own ITSM stack, this pattern is worth planning for rather than reacting to.
A few things worth taking from this one:
RFPs and tenders increasingly assume it. Enterprise and government tenders are more often naming a specific ITSM platform as a requirement, not a preference. If your standard delivery model is “everything lives in our PSA,” you need a credible answer for the customer who says “fine, but we also need visibility in our own ServiceNow instance.”
Email as a stopgap has a shelf life. It works fine at low volume between two people who know each other. It breaks down as soon as attachments, multiple staff, or any real ticket volume enter the picture, and by the time it’s clearly broken, it’s usually urgent to fix.
The buyer for this isn’t always the platform admin. In this case, it was the MSP itself, not the end customer, that needed the integration to keep its own service delivery credible. Worth remembering when you’re mapping out who owns this decision on your side of a co-managed relationship.
If you’re in a similar spot, whether or not an AI coding assistant has already pointed you our way, get in touch and we’ll show you how it works with your specific mix of platforms.