Migración sin cortes: dos helpdesks funcionando en paralelo

Hay equipos que pueden reservarse un fin de semana tranquilo y cambiar de helpdesk de una sola vez. Otros no: el soporte funciona a todas horas, el volumen no baja nunca o un lunes accidentado sale sencillamente demasiado caro. Para ellos existe otro patrón: el funcionamiento en paralelo. En lugar de un evento de cambio, la migración se convierte en un mando gradual: dos helpdesks vivos a la vez y el tráfico pasando del antiguo al nuevo canal a canal, con la herramienta antigua apagada solo cuando los números digan que ya es seguro.

Bien hecho, los clientes no se enteran y los agentes no se caen por ningún precipicio. Hecho a la ligera, aparecen los dos fallos clásicos: clientes que reciben dos respuestas de dos personas distintas, o ninguna porque cada herramienta daba por hecho que la otra se encargaba. La diferencia son un puñado de reglas.

El principio: enruta lo nuevo, vacía lo antiguo

Una sola regla sostiene todo el patrón: las conversaciones nuevas empiezan en la herramienta nueva; las que están en curso terminan donde nacieron.

Nada se mueve a mitad de hilo. Un cliente que escribió el martes en el sistema antiguo recibe su respuesta del jueves desde el sistema antiguo, de un agente que ve el intercambio completo. Un cliente que escribe por primera vez después del cambio aterriza en la bandeja nueva. Cada conversación tiene exactamente una casa, decidida por dónde empezó, así que en todo momento los dos equipos y las dos herramientas saben sin ambigüedad qué le toca a cada uno.

El helpdesk antiguo deja de ser tu sistema de soporte y pasa a ser una cola que se vacía: sin entradas nuevas, con una pila de pendientes que encoge y una meta a la vista.

Cambia los canales de uno en uno

El funcionamiento en paralelo funciona porque nunca te juegas todos los canales a la vez. Un orden típico, del menor riesgo al mayor:

1. El chat de la web. Cambias un fragmento de código, es reversible al instante y las conversaciones de chat son cortas: vaciar lo que está en curso lleva horas, no semanas. Es tu ensayo con poco en juego.
2. Un alias de correo secundario: la dirección de poco volumen, no la principal. Observa una semana entera de tráfico de punta a punta: enrutado, asignación, escalados, CSAT.
3. El correo principal de soporte. A estas alturas el proceso ya está probado; lo único que cambia es el volumen.
4. Mensajeros y redes sociales: suelen depender de pasos de reconexión del lado de la plataforma, así que agenda esa revinculación en vez de darla por hecha.

Dale a cada canal un periodo de asentamiento —unos días funcionando en la herramienta nueva mientras compruebas que no se escapa nada— antes de cambiar el siguiente. La escalera entera suele durar de dos a cuatro semanas. Ir más despacio no pasa nada; saltarse peldaños es la forma de acumular sorpresas.

Datos coherentes en dos herramientas a la vez

La arquitectura tentadora es una sincronización bidireccional en vivo entre los dos sistemas. Resístete. La sincronización bidireccional entre helpdesks es fontanería frágil que se rompe en silencio, y existe para resolver un problema que la regla de enrutado ya resolvió: nadie necesita que las dos herramientas guarden todas las conversaciones durante el solape; lo que hace falta es que cada conversación tenga una única casa ahora y que la herramienta nueva tenga el registro completo al final.

El patrón que sí funciona es mucho más simple:

• Una importación masiva antes de que empiece el periodo en paralelo: histórico, contactos, base de conocimiento y macros aterrizan en la herramienta nueva para que los agentes tengan contexto desde el primer día.
• Una importación delta al final: cuando la cola de la herramienta antigua se haya vaciado, una última pasada recoge todo lo que se creó allí durante el solape. El registro queda completo justo cuando la herramienta antigua se jubila.
• Los contactos convergen por correo electrónico como clave de deduplicación, así que un cliente que aparezca en las dos herramientas durante el solape se fusiona en un único registro en lugar de convertirse en gemelos.

Quién responde dónde: repartir el equipo sin cerebro partido

Reparte el equipo por canal, no por veteranía: quien lleva el chat trabaja en la herramienta nueva el día que el chat cambia; la gente de correo cruza cuando le toca al correo. Cada agente pasa al otro lado al mismo tiempo que un cambio de enrutado, así que nadie atiende dos colas a la vez, y atender dos colas a la vez es exactamente lo que produce la respuesta duplicada.

Dos reglas de apoyo:

• Los campeones cruzan primero. Los agentes que aprenden más rápido se llevan el primer canal y, para cuando cambia el correo principal, la herramienta nueva ya tiene expertos internos en todos los turnos.
• La herramienta antigua tiene fecha de fin en el calendario, a la vista de todo el mundo. Los periodos en paralelo sin final acaban en acampada en la cola —agentes que se quedan a vivir en la herramienta de siempre— y terminas pagando dos sistemas por pura inercia.

Métricas durante el periodo doble

Los números mezclados mienten durante un solape: la cola de la herramienta antigua encoge por diseño y la de la nueva crece por diseño, así que cualquier media combinada mide sobre todo la mezcla, no el servicio. En su lugar:

• Mide el tiempo de primera respuesta y el tiempo de resolución por herramienta, y compara los números de la nueva con la línea base previa a la migración de la antigua: esa es la comparación honesta, manzanas con manzanas.
• Vigila la curva de pendientes de la herramienta antigua. Debe bajar de forma monótona; una meseta significa que algo sigue enrutando entradas allí, y encontrar esa fuga es la tarea más importante del día.
• Cuenta con que los números de la herramienta nueva empiecen algo peor y crucen la línea base en una o dos semanas por canal, a medida que se asientan los hábitos.

Criterios de salida: cuándo apagar la antigua

Escríbelos antes de que empiece el periodo en paralelo, para que la decisión sea una lista de control y no un debate:

• Todos los canales enrutados a la herramienta nueva, cada uno con su periodo de asentamiento terminado.
• La cola en curso de la herramienta antigua vaciada por debajo del puñado acordado, con los rezagados reasignados de forma explícita.
• La importación delta ejecutada y comprobaciones al azar que confirmen que el registro está completo.
• Métricas por canal de la herramienta nueva en la línea base previa a la migración o por encima.
• Integraciones, webhooks y automatizaciones verificadas: apuntan solo a la herramienta nueva.
• Visto bueno del equipo: los responsables de turno confirman que ya no depende nada del sistema antiguo.

Después: herramienta antigua en solo lectura hasta que termine el ciclo de facturación (seguro barato y referencia honesta), cancelación confirmada por escrito y la exportación del archivo guardada en un sitio que controles tú.

Los fallos contra los que hay que diseñar

• Respuestas duplicadas: siempre son síntoma de un agente atendiendo las dos colas o de un canal enrutado a las dos herramientas. La regla de enrutado y el reparto del equipo por canales lo impiden de forma estructural.
• Alias huérfanos: esa dirección de reenvío olvidada que sigue alimentando la herramienta antigua después de que «todo» haya cambiado. La meseta en la curva de pendientes la delata.
• Integraciones que escriben al cadáver: un webhook o un script que sigue creando tickets en el sistema antiguo. Por algo están en los criterios de salida.
• El solape eterno: pagar las dos herramientas durante seis meses porque nadie se hizo dueño de la fecha de fin. Ponla el primer día.

Dónde encaja MoveDesk

MoveDesk está pensado para el patrón en paralelo: la migración guiada gratuita incluye tanto la importación masiva inicial como la pasada delta final, los puestos ilimitados permiten que todo el equipo viva en las dos herramientas durante el solape sin echar cuentas de licencias, y la prueba de 14 días cubre con holgura los primeros peldaños de la escalera de canales. Si estás valorando qué te espera al otro lado del solape, la comparativa con Intercom detalla el camino de migración.

Elige tu primer canal —seguramente el chat— y pon hoy la fecha de fin de la herramienta antigua. Una migración en paralelo sin fecha de fin no es una migración; es una segunda suscripción.