Cómo migrar conversaciones de clientes sin perder contexto

Una migración de conversaciones de clientes no termina cuando la importación llega al 100 por ciento. Termina cuando un agente abre un caso real en el sistema nuevo y todavía entiende quién es el cliente, qué ocurrió, quién es responsable del siguiente paso y qué mensaje no debe enviarse otra vez.

Los planes suelen empezar por campos y cantidades. Esas comprobaciones no demuestran que la operación haya sobrevivido al cambio. Un estado o una etiqueta puede llegar con otro significado. Todos los mensajes pueden estar presentes mientras faltan el cliente, el pedido, el consentimiento o el responsable.

Define qué debe seguir siendo cierto

Antes de mapear datos, escribe unas condiciones breves que deben cumplirse después del cambio.

• Cada conversación pertenece al cliente y a la identidad de canal correctos.
• Los mensajes, notas privadas, adjuntos y fechas conservan el orden adecuado.
• El trabajo abierto tiene un responsable actual, un estado, un plazo y una siguiente acción.
• El consentimiento, la baja y la procedencia siguen diferenciados de las etiquetas comunes.
• Los informes separan el historial migrado del trabajo creado después del lanzamiento.

Este es el contrato de aceptación. La guía de exportación actual de Zendesk muestra por qué el formato importa. CSV no incluye comentarios ni descripciones, mientras que JSON y XML tienen otra cobertura y límites. Un archivo válido puede ser la fuente equivocada.

Mapea el significado antes que los campos

No empieces por una hoja donde un estado de origen equivale a un estado de destino. Primero pregunta qué comportamiento producía cada valor en la operación anterior.

Si esperando al cliente y esperando al proveedor se convierten en pospuesto, desaparece la diferencia entre un compromiso y una dependencia externa. Los recordatorios y los informes cambian sin error técnico.

Mapea el significado de identidades, estados, prioridades, etiquetas, asignaciones, relaciones y fechas. Registra definiciones, comportamiento y pruebas. Conserva los identificadores antiguos en un campo externo para mantener la trazabilidad.

Una conversación no es solo texto. La API de conversaciones de Intercom documenta contactos, estado, responsables, etiquetas, atributos, partes y objetos vinculados, además de un límite de 500 partes. Comprueba la integridad en vez de asumir que una respuesta contiene toda la historia.

Separa el trabajo activo del historial

El historial cerrado y el trabajo activo necesitan planes distintos. Un registro histórico puede quedar en solo lectura. Una conversación abierta sigue recibiendo respuestas y acercándose a sus plazos.

La documentación actual de Pylon migra por su vía tradicional los tickets cerrados como instantáneas, pero no los abiertos, porque el canal no se transfiere con el registro. Sea cual sea la plataforma, pregunta dónde llegará la siguiente respuesta.

Elige una sola autoridad para la actividad nueva. Mantén los casos abiertos en el sistema anterior, muévelos con un procedimiento controlado o cambia la entrega en un momento definido y concilia el solapamiento. Dos emisores crean duplicados y responsabilidad dividida.

Construye un conjunto de prueba difícil

Incluye en el piloto una conversación larga, varias identidades de un cliente, un caso abierto con plazo, un caso reabierto, una prueba de consentimiento y un caso vinculado a otro objeto de negocio.

Comprueba las relaciones por separado. La API actual de tickets de HubSpot hace explícitas las asociaciones con contactos, empresas y actividades. Si el ticket llega sin esos vínculos, el texto sobrevive y el contexto no.

Compara orden, autoría, zonas horarias, adjuntos, identidad, estado, responsable, relaciones y siguiente acción. Después, pide a un agente que ejecute la siguiente tarea real. El registro debe ser utilizable, no solo parecido.

Haz el cambio por capas

Durante las pruebas, congela etiquetas, estados, campos y reglas, no la atención. Obtén una exportación protegida, prueba, importa el historial, concilia cantidades, resuelve el trabajo activo y cambia la entrega una vez.

Vigila importaciones fallidas, casos sin responsable, identidades duplicadas, notificaciones y adjuntos ausentes. Define la vuelta atrás antes del lanzamiento. Perder trabajo activo, romper una identidad, alterar el consentimiento o enviar duplicados debe detener el cambio.

Conserva solo lo que puedas justificar

Migrar también implica decidir qué conservar. La guía británica sobre limitación del almacenamiento indica que los datos personales no deben mantenerse más de lo necesario y que el periodo debe justificarse. Decide qué sigue operativo, qué va a un archivo restringido y qué se elimina. Conserva las obligaciones de borrado y las retenciones legales.

Haz que el nuevo registro sirva para trabajar

Una bandeja compartida mantiene historial, asignación, notas y estado alrededor del mismo trabajo. Un registro de cliente conectado mantiene campos, etiquetas, consentimiento y responsabilidad utilizables.

Al evaluar DripTell u otro destino, lleva el conjunto de prueba. Pide ver los registros importados y completar la siguiente acción. Una buena demostración es un agente que continúa una conversación real sin pedir al cliente que reconstruya el pasado.

Preguntas frecuentes

Qué datos de conversaciones deben migrarse

Migra el contenido y las relaciones necesarios para continuar el servicio, cumplir las obligaciones de conservación, explicar decisiones anteriores e informar con precisión. Archiva o elimina lo demás según una política documentada.

Cómo deben tratarse las conversaciones abiertas

Da a la actividad nueva una sola autoridad. Mantén los casos abiertos en el sistema anterior hasta cerrarlos, muévelos mediante un proceso controlado o cambia la entrega en un momento definido y concilia el solapamiento.

Cómo puede comprobarse que no se perdió contexto

Usa un conjunto de prueba difícil y compara identidad, cronología, autoría, adjuntos, estado, responsable, relaciones, plazos y siguiente acción. Después, ejecuta una tarea real en la plataforma nueva.

Deben copiarse exactamente las etiquetas antiguas

No de forma automática. Conserva una etiqueta solo después de documentar qué significa, quién la aplica, qué regla la utiliza y cómo reproducirá ese comportamiento el sistema de destino.