Jueves, 5 de noviembre de 2026

Cambiar de proveedor de soporte IT sin que los usuarios lo noten

Muchas empresas siguen con un proveedor de soporte que no las convence porque cambiar les parece más riesgoso que quedarse. Qué hace que una transición salga mal, cómo se ordena para que la mesa de ayuda siga atendiendo el día del cambio y qué conviene dejar escrito en el contrato antes de firmar.

El contrato con el proveedor de soporte vence en marzo. El servicio no es malo, pero tampoco es lo que la empresa necesita hoy: los tiempos de respuesta se fueron estirando y cada pedido nuevo termina en una negociación. Aun así, en la reunión de presupuesto alguien pregunta qué pasa si se cambia de proveedor y el lunes siguiente la mesa de ayuda no responde. La renovación se aprueba igual.

Ese miedo tiene fundamento. Una transición mal hecha se nota enseguida, con usuarios que llaman a un número que ya no atiende o tickets abiertos que nadie retoma. Pero un cambio de proveedor también se puede hacer bien. En Novatium tomamos servicios que operaba otro proveedor en empresas con operación en todo el país, y en esta nota contamos cómo se ordena una transición para que los usuarios casi no la noten.


Lo que de verdad hay que transferir

Cuando se habla de cambiar de proveedor, la conversación suele girar alrededor del equipo: cuántos analistas y con qué perfil. Es la parte más visible y, por lo general, la más fácil de resolver. Lo que más cuesta es lo que el proveedor saliente sabe y nunca escribió. Por ejemplo, cómo se resuelve el error que aparece en el sistema de facturación a fin de mes, o a quién se escala un problema de red en una planta del interior.

A eso se suman los accesos a las herramientas y el historial de tickets. Y la base de conocimiento, cuando existe, que pesa todavía más si el servicio ya trabaja con agentes de IA en el primer nivel: el agente va a responder con lo que encuentre ahí desde el primer día.


Cómo se ordena una transición

Cada transición tiene su propio calendario, pero las que salen bien suelen seguir un orden parecido.

  • Relevamiento. Inventario de los servicios que se traspasan, los volúmenes por canal y por horario, los niveles de servicio vigentes, las herramientas y los tickets abiertos. Es el momento de encontrar lo que no figura en ningún contrato pero el usuario da por hecho.
  • Transferencia de conocimiento. El equipo nuevo trabaja junto al saliente durante un período acordado: primero observa y después atiende con el otro equipo al lado. Todo lo que aparece en esas semanas se documenta en la base de conocimiento.
  • Cambio. Con fecha y hora definidas, un plan para volver atrás si algo falla y la comunicación a los usuarios lista. Lo que más les importa saber es qué cambia para ellos, como un número, un canal o un portal, y qué sigue igual.
  • Estabilización. Las primeras semanas después del cambio, con más supervisión y reuniones de seguimiento frecuentes, hasta que los indicadores se acomodan en los niveles acordados.

El tiempo de cada etapa depende del tamaño del servicio y de cuánto conocimiento esté documentado al empezar. Por eso el relevamiento es la etapa que más conviene no apurar.


Dos transiciones que hicimos

En una de las principales empresas de energía del país asumimos en octubre de 2023 la Mesa de Ayuda corporativa, que hasta ese momento operaba otro proveedor. Es un servicio 24×7×365 en español y en portugués que hoy recibe más de 20.000 contactos por mes, y la transición se completó en un mes.

En otro caso tomamos el soporte técnico de una red de más de 600 estaciones de servicio propias y franquiciadas en todo el país, sin interrupciones en la operación. Son sitios que atienden las 24 horas, donde un punto de venta que no funciona un domingo a la noche se nota de inmediato.

Son operaciones donde un corte se nota en minutos, y por eso el plan de transición importa tanto como el equipo que toma el servicio.


Lo que conviene dejar escrito antes de firmar

Buena parte de una transición se define mucho antes, cuando se firma el contrato con el proveedor que algún día se va a reemplazar. Vale la pena que ese contrato incluya:

  • La obligación de colaborar con la transición durante un período definido, aun después de la fecha de fin.
  • La entrega del historial de tickets y de la base de conocimiento en un formato que se pueda importar en otra herramienta.
  • La documentación de accesos, integraciones y procedimientos de escalamiento.
  • Que los datos del servicio y la base de conocimiento son de la empresa, no del proveedor.

Si el contrato vigente no dice nada de esto, la renovación es un buen momento para sumarlo, aunque se termine renovando con el mismo proveedor.


Antes de renovar por costumbre

Quedarse con un servicio que no funciona también tiene un costo, aunque no figure en la planilla de presupuesto: horas que los usuarios pierden esperando y problemas que se repiten mes a mes. Si tu contrato de soporte vence en los próximos meses y estás evaluando alternativas, contanos cómo está armado hoy tu servicio y te mostramos cómo sería la transición en tu caso. Conversemos.