Histórico de tickets y retención de datos: qué conservar al migrar

Toda migración de helpdesk obliga a responder una pregunta que la mayoría de equipos lleva años aplazando: ¿para qué sirve en realidad todo este histórico? Diez años de tickets parecen un activo hasta que hay que moverlos; entonces se convierten en una factura, medida en horas de exportación, tiempo de importación, almacenamiento y ruido en las búsquedas. La respuesta honesta es que el histórico de tickets hace tres trabajos, cada uno con su propia caducidad, y en cuanto les pones nombre la decisión de conservar o archivar casi se toma sola.

Los tres trabajos que hacen los tickets antiguos

Trabajo 1: contexto para el agente. «¿Este cliente nos ha escrito antes? ¿Qué le prometimos?» Es el uso del día a día, y está muy escorado hacia lo reciente. Mira los datos de tu propia herramienta antes de fiarte de la regla general de nadie: comprueba cuándo fue la última vez que un agente abrió un ticket de más de un año. En la mayoría de equipos, las consultas se concentran de forma abrumadora en los últimos seis a doce meses, con una cola fina para cuentas grandes en activo y disputas abiertas.

Trabajo 2: informes y tendencias. Curvas de volumen, mezcla de temas, patrones de temporada. Los informes necesitan agregados, no conversaciones en bruto — y los agregados se calculan una vez, se exportan como números y se guardan para siempre a un coste ridículo. No hacen falta diez años de tickets en bruto para recordar que enero es tu pico.

Trabajo 3: alimentar a la IA. El trabajo más nuevo y el peor entendido, así que merece su propia sección.

Fíjate en lo que no aparece en la lista: nada exige un histórico en bruto de una década dentro de tu herramienta de trabajo. El primero quiere lo reciente, el segundo quiere números y el tercero — como veremos ahora — quiere criterio. El instinto de migrarlo todo viene de la aversión a la pérdida, no de ningún trabajo que los datos hagan de verdad.

Lo que tu IA necesita de verdad (menos de lo que crees)

Hay una intuición tentadora: más histórico, IA más lista. El funcionamiento de la IA de soporte moderna apunta justo al revés.

Los agentes de IA responden a partir de tu base de conocimiento — artículos actuales y bien mantenidos —, no escarbando en años de conversaciones en bruto. Donde los tickets pasados ayudan algo es en los recientes y bien resueltos: enseñan cómo se expresa tu equipo hoy, sobre el producto que vendes hoy. Los tickets antiguos describen productos que has cambiado, políticas que has sustituido y apaños que ya has arreglado. Meterlos dentro no añade sabiduría; añade contradicción, y las contradicciones salen a la superficie como respuestas equivocadas dichas con total seguridad.

Hay un efecto de segundo orden que se le escapa a los equipos: el histórico caducado también contamina la búsqueda de los agentes. Cuando un agente busca «política de reembolsos» y le salen resultados de tres generaciones distintas de esa política, la respuesta que la IA redacta sobre esa búsqueda hereda la confusión. Un corpus podado y reciente no es una concesión a cambio de calidad de IA: es calidad de IA. Por eso una migración es, sin hacer ruido, el mejor evento de preparación para la IA que le puede pasar a un equipo de soporte: obliga a hacer la limpieza del corpus que nadie programa por su cuenta.

El marco conservar / archivar / borrar

Tres cajones, decididos por clase de dato y no ticket a ticket:

• Conservar (migrar en vivo): los últimos 12–24 meses de conversaciones, todos los contactos con sus campos personalizados, la base de conocimiento entera y las disputas abiertas o cerradas hace poco, tengan la edad que tengan. Esto cubre casi todas las consultas reales y todo lo que le sienta bien a la IA.
• Archivar (exportar, guardar, no importar): todo lo anterior, como exportación de solo lectura en formato estructurado — JSON con un índice le gana a CSV para cualquier cosa que algún día quieras buscar —, más los adjuntos, en un almacenamiento que controles tú. Los archivos son para la auditoría rara, la disputa o la consulta nostálgica; no pintan nada en el índice de búsqueda de tu herramienta de trabajo.
• Borrar: tickets cerrados como spam, intercambios de una palabra, restos de correos rebotados y tickets de prueba. Esto no es minimalismo temerario; es quitar ruido. Nadie ha necesitado jamás el archivo de las respuestas automáticas.

El marco tiene un efecto secundario agradable: tu helpdesk nuevo arranca rápido y sigue rápido, porque su índice de búsqueda lleva señal en lugar de sedimento.

Obligaciones de retención, en lenguaje llano

Aquí es donde los equipos o prometen de más o se quedan paralizados, así que vamos a ser claros y honestos. Las normas de retención existen, varían — y este artículo no es asesoramiento legal.

Hay unas cuantas formas generales que conviene conocer:

• En algunos sectores y jurisdicciones, ciertos registros llevan asociada una retención mínima obligatoria — normalmente cosas como la correspondencia ligada a la facturación, las reclamaciones en sectores regulados o los registros vinculados a contratos. La obligación suele ir pegada al tipo de registro, no al helpdesk en su conjunto.
• Las normativas de privacidad empujan en sentido contrario: los principios de minimización de datos esperan que no guardes datos personales más tiempo del necesario para una finalidad declarada. «Lo guardamos todo para siempre porque migrar era más fácil» no es una finalidad.
• Archivar no exime a los datos de las obligaciones de privacidad. Un ticket en almacenamiento frío sigue siendo un dato personal: las solicitudes de supresión, las de acceso y los deberes ante una brecha también llegan hasta allí.

El movimiento práctico: antes de la migración, pide a quien lleve lo legal o el cumplimiento en tu empresa que escriba los periodos de retención por clase de dato — tickets, contactos, adjuntos, CSAT —, aunque la respuesta sea una tabla sencilla de tres filas. La migración se limita después a implementar esa tabla. Esa es toda la relación entre ambas cosas: el criterio legal decide, la migración ejecuta.

Cómo tratar los datos personales del archivo

Si sigues el marco, el archivo es donde se concentran los datos personales antiguos, así que trátalo con intención:

• Restringe el acceso. El helpdesk de trabajo tiene permisos por rol; tu archivo también debería tenerlos. Un cubo de almacenamiento abierto al mundo con diez años de conversaciones de clientes es un pasivo, no una copia de seguridad.
• Mantén un manifiesto: qué contiene el archivo, rangos de fechas, formato y quién aprobó su periodo de retención. El tú del futuro, atendiendo una solicitud de supresión, buscará en el manifiesto y no en el volcado en bruto.
• Diseña pensando en el borrado. Guarda los datos por cliente de forma que puedas eliminar los registros de una persona sin desempaquetarlo todo. Un archivo del que no puedes borrar es una obligación que no puedes cumplir.
• Ponle fecha de caducidad. Decide cuándo se revisa o se destruye el propio archivo, y llévalo al calendario. Retención sin fecha de fin es acumular con un documento de política delante.

Qué significa esto para tu plan de migración

La decisión sobre la retención reconfigura la propia migración, y para bien: la importación en vivo se reduce a una fracción del plan ingenuo de «moverlo todo», lo que significa ventanas de importación más cortas, búsquedas limpias desde el primer día y un corpus de IA que arranca afilado en lugar de turbio. Los equipos que eligen 12–24 meses más las disputas suelen ver la importación terminar en horas en vez de días.

La migración de MoveDesk te deja elegir la profundidad del histórico en el momento de importar — y, como la migración guiada es gratuita y las dos herramientas pueden convivir en paralelo, puedes empezar con 12 meses, vivir con ello un mes e importar histórico más profundo más adelante si la realidad llega a pedírtelo. Por nuestra experiencia, rara vez lo pide.

Escribe esta semana la tabla de los tres cajones — conservar, archivar, borrar, con un periodo de retención por clase. Es una página, hace la migración más pequeña y, de paso, mejora tu forma de tratar los datos.