Many companies stay with a support provider they're not happy with because switching feels riskier than staying put. What makes a transition go wrong, how to organize it so the help desk keeps answering on the day of the change, and what's worth putting in writing in the contract before you sign.
The contract with the support provider expires in March. The service isn't bad, but it isn't what the company needs today either: response times have been stretching out and every new request turns into a negotiation. Even so, in the budget meeting someone asks what happens if they switch providers and the following Monday the help desk doesn't answer. The renewal gets approved anyway.
That fear is well founded. A badly handled transition shows immediately, with users calling a number that no longer answers or open tickets that no one picks up. But a change of provider can also be done well. At Novatium we have taken over services previously run by another provider at companies operating across the country, and in this article we explain how a transition is organized so that users barely notice it.
What really has to be transferred
When people talk about switching providers, the conversation tends to revolve around the team: how many analysts and with what profile. That's the most visible part and, generally, the easiest to solve. The hardest part is what the outgoing provider knows and never wrote down. For example, how to fix the error that shows up in the billing system at month-end, or who to escalate a network problem to at a plant in the interior.
On top of that come the access to tools and the ticket history. And the knowledge base, when it exists, which matters even more if the service already works with AI agents at the first level: the agent will answer with whatever it finds there from day one.
How a transition is organized
Every transition has its own schedule, but the ones that go well usually follow a similar order.
- Assessment. An inventory of the services being handed over, the volumes by channel and by time slot, the service levels in force, the tools and the open tickets. This is the moment to find what isn't written in any contract but the user takes for granted.
- Knowledge transfer. The new team works alongside the outgoing one for an agreed period: first observing and then handling cases with the other team beside them. Everything that comes up during those weeks is documented in the knowledge base.
- Cutover. With a set date and time, a plan to roll back if something fails and the communication to users ready. What matters most to them is what changes for them, like a number, a channel or a portal, and what stays the same.
- Stabilization. The first weeks after the change, with closer supervision and frequent follow-up meetings, until the indicators settle at the agreed levels.
The time each stage takes depends on the size of the service and on how much knowledge is documented at the start. That's why the assessment is the stage you least want to rush.
Two transitions we handled
At one of the country's leading energy companies, in October 2023 we took over the corporate Help Desk, which until then was run by another provider. It's a 24×7×365 service in Spanish and Portuguese that today receives more than 20,000 contacts a month, and the transition was completed in one month.
In another case we took over technical support for a network of more than 600 company-owned and franchised service stations across the country, with no interruption to operations. These are sites open around the clock, where a point of sale that doesn't work on a Sunday night is noticed right away.
These are operations where an outage shows within minutes, and that's why the transition plan matters as much as the team taking over the service.
What's worth putting in writing before you sign
Much of a transition is decided long before, when you sign the contract with the provider you'll one day replace. It's worth making sure that contract includes:
- The obligation to cooperate with the transition for a defined period, even after the end date.
- The handover of the ticket history and the knowledge base in a format that can be imported into another tool.
- The documentation of accesses, integrations and escalation procedures.
- That the service data and the knowledge base belong to the company, not to the provider.
If your current contract says nothing about this, the renewal is a good moment to add it, even if you end up renewing with the same provider.
Before you renew out of habit
Staying with a service that doesn't work also has a cost, even if it doesn't show up in the budget spreadsheet: hours users lose waiting and problems that repeat month after month. If your support contract expires in the coming months and you're weighing your options, tell us how your service is set up today and we'll show you what the transition would look like in your case. Let's talk.