Migrar tu helpdesk sin cerrar la atención al cliente
Pasamos tickets abiertos, plantillas y artículos desde tu helpdesk actual a AgentDesk, con los dos sistemas conviviendo hasta el corte. Tu equipo sigue atendiendo durante la migración y tus clientes no reciben ningún aviso.
Cómo es el paso de tu helpdesk actual a AgentDesk
Durante la convivencia, AgentDesk lee en paralelo los buzones de correo sin marcar los mensajes como leídos, mientras el equipo sigue trabajando en la herramienta anterior. Una regla en esa herramienta cierra los hilos que ya llevan la referencia de AgentDesk, para que nadie conteste dos veces. Esas semanas sirven para probar la clasificación y la IA con correo real.
El corte se hace canal a canal. En el chat, se apaga la entrada en el sistema anterior y los chats que siguen vivos se concilian uno a uno: los ya atendidos allí se cierran con una nota y los pendientes pasan a la cola de AgentDesk. Después se cargan por API todos los tickets abiertos de cada canal, y el equipo sigue atendiendo mientras dura la carga.
Ningún cliente recibe un correo por la migración: la conversación previa entra en cada ticket como nota interna. La herramienta anterior se da de baja cuando la conciliación cuadra, y conviene hacerlo antes de que renueve el periodo. El histórico de casos cerrados no se carga como tickets vivos; queda en un buscador de solo lectura dentro de AgentDesk, donde el equipo lo consulta cuando un cliente escribe por algo antiguo.
Qué sacamos de tu helpdesk actual
Si tu helpdesk está en la nube, lo normal es que tenga API para leer tickets y contactos; si está instalado en un servidor propio, leemos la base de datos. En los dos casos hacemos antes una prueba de extracción, porque cada API deja fuera cosas distintas.
Qué se migra y qué no
La lista cerrada sale de la prueba de extracción, antes de fijar la fecha del corte.
Se migra
- Tickets abiertos de todos los canales, sin importar su antigüedad, con la conversación previa como nota interna
- El cliente asociado a cada ticket
- Plantillas de respuesta y macros, incluidas las plantillas de correo y las de ticket
- Artículos de la base de conocimiento, separando los internos de los públicos
- El histórico de tickets cerrados, en un buscador de solo lectura
- Departamentos y etiquetas, revisados a mano para aprovechar el cambio
No se migra tal cual
- Reglas de asignación y SLA cuando la API no los expone. Se configuran de nuevo en AgentDesk con el equipo
- Lo que hace cada macro: hay APIs que dan el nombre pero no sus acciones, y entonces se rehacen
- El centro de ayuda. Suele compensar rehacerlo en lugar de copiarlo
- Los adjuntos antiguos en bloque. Se decide si se copian o se consultan bajo demanda, según lo que ocupan y cuándo se apaga el sistema viejo
- Casos cerrados que el cliente reabre: si vuelve a escribir por uno migrado y cerrado, se abre un ticket nuevo
Lo que la API de tu herramienta no da conviene saberlo en la prueba de extracción, no la noche del corte.
La migración paso a paso
Seis fases. Las cuatro primeras se hacen con tu equipo trabajando como siempre en la herramienta actual.
Inventario y prueba de extracción
Pedimos acceso de lectura a la API (o a la base de datos si el helpdesk está en tu servidor) y sacamos una muestra de tickets, conversaciones, plantillas y artículos. Aquí aparece lo que la API no da.
Mapa de campos y categorías
Estados, departamentos, etiquetas y campos personalizados de la herramienta vieja se asignan a los de AgentDesk. Es buen momento para rehacer las categorías con datos en lugar de arrastrar las de hace años.
Convivencia
AgentDesk empieza a leer los buzones sin marcar nada como leído y una regla en el sistema anterior evita respuestas dobles. Así se prueban la clasificación y la IA con correo real sin que el cliente note nada.
Plantillas y conocimiento
Se importan plantillas, macros y artículos. Lo interno pasa a respuestas tipo del equipo y lo público va al centro de ayuda, revisado.
Corte canal a canal
Se apaga la entrada en el sistema viejo de un canal cada vez, se concilian los casos vivos y se cargan los tickets abiertos sin enviar nada al cliente.
Conciliación y baja
Contamos tickets en origen y en destino, limpiamos duplicados y revisamos lo que la API dijo haber hecho. Solo entonces se da de baja la herramienta anterior.
Qué puede salir mal y cómo lo resolvemos
Cuatro problemas típicos al migrar un helpdesk y cómo los resolvemos.
La API responde que sí y no hace nada
Al cerrar tickets en el sistema de origen, la API puede devolver 200 y dejar el ticket abierto. Por eso la conciliación cuenta en origen y en destino, y un barrido vuelve a cerrar lo que quedó a medias.
Tickets duplicados durante la convivencia
Un cliente escribe por correo mientras su ticket se está migrando y aparece dos veces. Emparejamos por email del cliente con una ventana de dos días a cada lado, y los pocos que se cuelan se limpian después.
El servidor de correo deja de responder
Si el correo falla durante la convivencia, un proceso periódico rescata lo que ha quedado pendiente en la herramienta anterior, para que no se pierda ningún mensaje mientras vuelve.
La red deja a la IA fuera
Una restricción de red en el servicio de IA puede dejarla sin funcionar justo cuando más falta hace. Por eso, antes de migrar, probamos la IA desde el mismo servidor y la misma red que se usarán en producción.
Cómo evitamos perder datos
Conciliación antes de apagar
Contamos tickets por canal en origen y en destino y revisamos duplicados. Mientras no cuadra, el sistema anterior no se da de baja.
Sin parar el servicio
Los dos sistemas conviven desde semanas antes. El corte se hace canal a canal y el equipo sigue atendiendo durante la carga.
Marcha atrás posible
Mientras el helpdesk anterior sigue activo se puede volver a él. Lo que se limpia después de migrar va a una papelera restaurable.
Dudas habituales sobre migrar un helpdesk
¿Se puede migrar a AgentDesk sin perder el histórico?
Sí, siempre que los datos se puedan leer por API o desde la base de datos. Antes de comprometer alcance hacemos una prueba de extracción con tu herramienta, porque cada API deja fuera cosas distintas. El histórico cerrado puede quedar en un buscador de solo lectura dentro de AgentDesk.
¿Cuánto tarda la migración de un helpdesk?
El corte es corto; lo largo es prepararlo. Los dos sistemas conviven durante semanas antes de cargar los tickets abiertos, y la carga se hace con el equipo atendiendo. El plazo depende del volumen, de cuántos canales haya y de lo que la API de origen deje sacar.
¿Hay que parar la atención al cliente durante la migración?
No. AgentDesk convive con el sistema anterior leyendo los mismos buzones y el corte se hace canal a canal. Los casos vivos de cada canal se concilian en el momento del corte y el equipo sigue atendiendo mientras se cargan los tickets.
¿Se migran las macros, las reglas de asignación y los SLA?
Depende de lo que exponga la API de tu herramienta. Hay APIs que dan las plantillas pero no las acciones de las macros ni las reglas de asignación o SLA; en ese caso se configuran de nuevo en AgentDesk con el equipo. Lo comprobamos siempre en la prueba de extracción.
¿Se enteran los clientes de que hemos cambiado de herramienta?
No reciben ningún aviso: la carga de tickets no envía correos y la conversación anterior entra como nota interna. Si también cambia el centro de ayuda, las URLs antiguas se redirigen con 301 a las nuevas para que los enlaces guardados sigan funcionando.
Antes y después de migrar
Dinos desde qué helpdesk vienes
Con la herramienta, los canales y un volumen aproximado te decimos qué se migraría, qué habría que rehacer y cómo plantearíamos el corte.