When your client won't move to your PSA

Every MSP has been there. You've landed a solid client, the relationship is growing, and then you hit the wall: they have their own ticketing system and they're not switching.

Maybe it's a larger organisation with an established internal IT team. Maybe they've invested heavily in their platform and have workflows built around it. Whatever the reason, the conversation where you suggest they adopt your PSA doesn't go the way you hoped.

So what happens next? Your technicians end up jumping between platforms. Time tracking becomes a guessing game. Ticket updates get missed. And that promising client relationship starts to feel like a burden.

The scenario most MSPs recognise

We recently spoke with a US-based MSP supporting a client in the Midwest. The client has a large employee base, a sizeable internal IT team, and runs FreshService. The MSP uses Halo PSA.

As one of their senior team members put it: "This was not going to be a client of ours that we were really going to be able to force over into our ticketing system."

The client's IT operation was simply too mature. They had their workflows, their reporting, their processes. Asking them to move wasn't realistic.

But the work was good. Standard level one support: password resets, access requests, printer issues, Microsoft 365 troubleshooting. The kind of steady, valuable work that MSPs want more of.

The question became: how do you serve this client properly without destroying your own operational efficiency?

The DIY trap

The instinct for many technical teams is to build something. Surely there's a way to connect these systems with some automation tooling?

The MSP we spoke with tried exactly this approach, exploring integrations through N8N. The result? Complexity that didn't quite work, particularly around the nuances of email actions and workflow triggers.

"That's the part when I was looking at this, and then trying to do it with N8N, that I was struggling the most with."

The problem isn't that automation tools can't move data between systems. They can. The problem is that IT service management has layers of complexity that generic automation doesn't account for: status mappings, private versus public notes, closure workflows, category hierarchies that don't match between platforms.

Building and maintaining these integrations becomes a project in itself. And when something breaks at 2am, it's your problem to fix.

What actually works

The solution that worked for this MSP was straightforward: bidirectional ticket synchronisation that lets each party stay in their own platform.

Tickets created in FreshService flow through to Halo PSA. Updates, status changes, and comments sync back and forth. Attachments transfer. When a ticket closes on one side, it closes on the other.

The technicians work in Halo, the tool they know. The client's IT team and end users interact entirely through FreshService. Neither side needs to change their behaviour.

"We want to be able to have the technicians on our side be able to work out of the same platform they do on a day-to-day basis."

The configuration handles the translation between platforms: mapping statuses, flattening category hierarchies where needed, ensuring closure processes trigger correctly on both sides.

The communication question

One detail that comes up in every integration conversation is email notifications. When a ticket update happens, who sends the email to the end user?

The answer, almost universally, is that communications should come from the client's system. Their users expect emails from support@client.com, not from your MSP domain. Mixed communications create confusion and erode trust.

A proper integration handles this by syncing the content of updates without triggering duplicate notifications. Your technician adds a note in Halo, it syncs to FreshService, and FreshService sends the notification to the end user. Clean and professional.

The business case

There's a category of client that many MSPs struggle to serve efficiently: organisations large enough to have their own IT infrastructure and tooling, but still needing external specialist support.

These aren't your typical break-fix clients. They often come with structured agreements, predictable hours, and longer-term relationships. In the case of the MSP we spoke with, the client operates on a 40-hour weekly agreement.

But without integration, serving these clients means operational friction that eats into margins. Technicians waste time on duplicate data entry. Supervisors can't get accurate reporting without manually consolidating information from multiple systems.

Integration removes that friction. Time tracked in your PSA stays in your PSA, where your reporting and billing workflows expect it. The client gets visibility through their own platform. Everyone works the way they want to work.

A different kind of client relationship

The MSP managing both sides of this integration made an interesting observation about maintenance burden. With an external integration platform handling the synchronisation, they're not responsible for keeping custom automation running.

"I wanted to kind of leverage something externally with low maintenance outside of N8N between these two because it's a client. It's not like an us-to-vendor integration. It's an us-to-client."

That distinction matters. Vendor integrations are your problem to solve. Client integrations are part of the service you're delivering. The reliability expectations are different.

When integration is the mechanism through which you deliver service, it needs to work consistently. That's not a side project for your automation enthusiast to maintain between other responsibilities.

The takeaway

Not every client will adopt your PSA. Some of the best clients won't.

The question isn't how to force the issue. It's how to serve these clients without compromising your own operations. Proper ticketing integration makes that possible.

Your technicians stay productive in familiar tools. Your client's users get consistent service through their expected channels. The relationship grows instead of becoming a source of friction.

Sometimes the best way forward isn't changing the client's behaviour. It's adapting your operations to meet them where they are.

Support Fusion provides bidirectional ticket synchronisation between IT service management platforms. If you're supporting clients on different ticketing systems, book a demo to see how it works.