Preparar los datos de soporte para la IA: tickets, macros y contenido de conocimiento

Por Linh Ngo · Actualizado el 11 de octubre de 2026

Preparar los datos de soporte para la IA significa poner en orden tres activos antes de que un modelo toque a un cliente: una base de conocimiento precisa, inequívoca y vigente, un historial de tickets con etiquetas coherentes y resoluciones limpias, y una biblioteca de macros que coincida con la forma en que su equipo responde en realidad. Un agente de IA responde con lo que usted le dé. Si el centro de ayuda se contradice, el bot también lo hará, y lo dirá con cortesía y a escala.

Esta guía está dirigida a líderes de soporte, Directors de CX y managers de soporte que están a punto de activar un agente de IA, o que ya lo hicieron y ven respuestas equivocadas. Se ubica bajo la visión general de la IA en el servicio al cliente y profundiza en lo que decide la mayoría de los resultados: el contenido y los datos que hay debajo de la herramienta.

Datos clave

• En el estudio del NBER «Generative AI at Work», un asistente de IA aumentó las incidencias resueltas por hora en cerca de 14% en promedio entre 5179 agentes de soporte al cliente, y en 34% en el caso de trabajadores novatos y de baja cualificación (NBER w31161).
• Los mismos autores encontraron indicios de que la IA «difunde las mejores prácticas de los trabajadores más capaces», algo que solo funciona si esas prácticas existen en una forma registrada y utilizable (NBER w31161).
• La documentación de Intercom afirma que, a diferencia de los lectores humanos, la IA «depende en gran medida de una estructura clara, una redacción inequívoca y una fuerte alineación con la intención del cliente» (Intercom Help Center).
• Intercom recomienda revisar cada semana las sugerencias de contenido de la IA y las marcas de los compañeros, y revisar cada mes los artículos de mucha intervención y baja resolución (Intercom Help Center).
• La guía de Zendesk para su agente de IA indica que se evite la información desactualizada o poco fiable, porque los agentes de IA la usan (Zendesk Help Center).

Qué datos de soporte necesita realmente la IA

La mayoría de las herramientas de soporte con IA se divide en dos familias, y cada una lee un activo distinto.

La primera responde preguntas a partir de su documentación. Recupera artículos de ayuda relevantes y redacta una respuesta con ellos, un patrón conocido como generación aumentada por recuperación. En términos del ACE Framework, es el patrón rag-assistant. Su calidad queda limitada por su contenido de conocimiento. El modelo no puede citar una política que usted nunca puso por escrito, y no puede saber cuál de dos artículos en conflicto es el verdadero. La página sobre el agente de IA de base de conocimiento explica cómo se comporta ese agente una vez que el contenido está en su lugar.

La segunda clasifica y enruta. Lee un ticket entrante, le asigna una categoría, una urgencia o un sentimiento, y lo envía a la cola correcta. Es el patrón scoring-routing, y aprende de sus tickets históricos. Si sus etiquetas son incoherentes, aprende hábitos incoherentes. Vea el agente de IA de triaje de soporte para saber qué hace una versión bien alimentada.

Las macros se sitúan entre ambas. Son la redacción aprobada de su equipo, y alimentan tanto las herramientas de redacción como las sugerencias del agent assist.

Para ver el panorama de datos más allá del soporte, la preparación de datos para la IA recorre las comprobaciones generales.

Las brechas más comunes

Cinco problemas aparecen una y otra vez en las operaciones de soporte antes de un lanzamiento de IA.

Contradicciones entre artículos. Dos páginas sobre reembolsos, escritas con dos años de diferencia, dan plazos distintos. Un agente humano sabe cuál es la correcta. Un sistema de recuperación puede mostrar cualquiera de las dos. El propio centro de ayuda de Zendesk señala que los agentes de IA usan información desactualizada o poco fiable, y un artículo viejo es justamente eso.

Conocimiento que vive en la cabeza de las personas. La solución para ese extraño caso límite de facturación existe solo en la memoria de su agente más sénior. Es la brecha que señala el estudio del NBER: la IA difunde las prácticas de los mejores, pero solo las que puede encontrar en forma registrada.

Proliferación de etiquetas. Tras tres años hay 140 etiquetas, seis de las cuales significan «problema de facturación», y los agentes eligen la que aparece primero en el menú desplegable. Un modelo de enrutamiento entrenado con ese historial reproduce la confusión.

Notas de resolución vacías. Los tickets cerrados con «Resuelto» o «Hecho» no enseñan nada. El valor está en la línea que dice «El certificado SSO del cliente venció; se renovó en la configuración de administración y se volvió a sincronizar».

Macros que sobrevivieron a su política. La macro que promete un plazo de devolución de 30 días sigue en el menú de atajos mucho después de que la política cambiara a 14 días. Las herramientas de agent assist la sugieren con toda fidelidad.

Cómo es un buen contenido de conocimiento

La guía de prácticas de Knowledge-Centered Service (KCS) v6 del Consortium for Service Innovation es el método más establecido para esto. Organiza el trabajo en un Solve Loop, donde los agentes capturan, estructuran, reutilizan y mejoran el conocimiento mientras resuelven tickets, y un Evolve Loop, que abarca la salud del contenido, la integración de procesos, la evaluación del desempeño y el liderazgo (KCS v6 Practices Guide). Sus cuatro prácticas del Solve Loop encajan bien con la preparación para la IA:

• Capturar (incluido «Capture Knowledge in the Moment»): escriba el artículo mientras resuelve el ticket, no en un sprint trimestral de documentación.
• Estructurar («Use A Simple Template»): una plantilla coherente, como problema, entorno, resolución, causa, hace que el contenido sea fácil de interpretar tanto para las personas como para los sistemas de recuperación.
• Reutilizar («Search Early Search Often», «Linking»): vincular los tickets con el artículo usado muestra qué contenido se usa de verdad.
• Mejorar («Flag It or Fix It»): quien encuentre un artículo erróneo lo corrige o lo marca, de modo que se detecte el deterioro.

No necesita adoptar KCS por completo para beneficiarse. El principio es que el conocimiento es un subproducto de resolver tickets y tiene un responsable.

La guía de los proveedores apunta en la misma dirección. Intercom dice que la IA depende de una estructura clara y de una redacción inequívoca, y que los artículos con un propósito o un alcance poco claros pueden recuperarse para el tipo de consulta equivocado (Intercom Help Center). Una regla práctica: si una persona recién contratada preguntaría «un momento, ¿cuál se aplica a mí?» después de leerlo, la IA va a adivinar.

Algunos hábitos de redacción que ayudan:

1. Ponga la respuesta en la primera frase y después las condiciones y las excepciones.
2. Nombre el segmento de clientes, el plan o la región a los que se aplica la respuesta.
3. Use en el título las palabras que usan los clientes («Cambiar el correo de mi cuenta»), no la jerga interna.
4. Mantenga una tarea por artículo y enlace en lugar de copiar los pasos compartidos.
5. Indique dentro del artículo la versión del producto o la fecha de la política para que los revisores detecten los obsoletos.

Limpiar el historial de tickets y las macros

El historial de tickets es donde la IA aprende su lógica de clasificación, y donde las herramientas de agent assist encuentran ejemplos de respuestas.

Etiquetas. Redúzcalas a una lista controlada que un agente nuevo pueda memorizar, normalmente de 15 a 40 motivos según la complejidad. Escriba una definición de una línea y un ejemplo para cada una. Fusione sinónimos, retire la cola larga y haga obligatorio el campo del motivo de contacto principal. Luego vuelva a etiquetar una muestra (unos pocos cientos de tickets bastan para probar) y compare el resultado con lo que los agentes eligieron originalmente. Un gran desacuerdo significa que las categorías no son claras, no que los agentes sean descuidados.

Notas de resolución. Añada un campo obligatorio de «qué lo arregló» o una plantilla de cierre. Incluso una nota breve y específica convierte cada ticket en un posible artículo de conocimiento y en un mejor ejemplo de entrenamiento.

Datos sensibles. Los tickets contienen nombres, fragmentos de tarjetas, datos de salud y contraseñas que la gente pegó por error. Decida qué se enmascara o se excluye antes de usar cualquier texto de tickets para entrenamiento o recuperación. Involucre pronto a su responsable de privacidad o de seguridad.

Macros. Exporte la lista completa con los conteos de uso. Retire todo lo que lleve un año sin usarse, asigne un responsable a cada macro restante y vincule cada una con la política que expresa. Cuando una política cambia, el responsable actualiza la macro y el artículo correspondiente en el mismo cambio.

Paso a paso: dejar listos los datos de soporte

1. Elija el primer caso de uso. Un bot de deflexión (desvío de consultas) para preguntas de contraseñas y facturación necesita buenos artículos. Un modelo de triaje necesita buenas etiquetas. Empiece por el activo del que depende su primer proyecto y use la guía de preparación de datos por patrón para ver qué necesita cada patrón.
2. Audite los 50 temas principales. Extraiga sus principales motivos de contacto por volumen. Para cada uno, compruebe que exactamente un artículo vigente lo responde. Marque los que faltan, los duplicados y los que están en conflicto.
3. Arregle primero las contradicciones. Fusione duplicados, elimine o redirija al perdedor y resuelva la cuestión de la política con quien sea su responsable. Es la mejora de precisión más rápida que obtendrá.
4. Llene las brechas con tickets reales. Para los principales temas sin cobertura, lea 20 tickets resueltos y escriba el artículo a partir de la mejor resolución. Es la «captura» de KCS hecha por lotes.
5. Estandarice la plantilla. Adopte una estructura de artículo y un estilo de título. Reescriba primero los 50 principales, no toda la biblioteca.
6. Limpie etiquetas y notas. Publique la lista controlada de etiquetas con sus definiciones, reasigne el historial a ella y exija notas de resolución de aquí en adelante.
7. Revise las macros. Retire, actualice o asigne responsables, y vincule cada una con una política.
8. Fije responsables y fechas de revisión. Cada artículo y cada macro recibe un responsable con nombre y un intervalo de revisión. Ordene por fecha de última actualización, empiece por los artículos de mayor tráfico y ponga la revisión en un calendario regular.
9. Construya un conjunto de prueba. Escriba de 50 a 100 preguntas reales de clientes con la respuesta correcta para cada una, incluidas las preguntas que el bot debería rechazar. Ejecútelo antes del lanzamiento y después de cada cambio de contenido.
10. Abra un ciclo de retroalimentación. Dé a los agentes una forma de un clic para marcar una respuesta equivocada o ausente, y revise las marcas cada semana. Intercom recomienda revisar cada semana las sugerencias de contenido de la IA y las marcas de los compañeros, y revisar cada mes los artículos que la IA usa mucho pero que rara vez resuelven la pregunta (Intercom Help Center).

Lista de preparación de los datos de soporte

Puntúe cada fila con 0 (no es cierto), 1 (en parte cierto) o 2 (cierto). Cualquier resultado inferior a 10 de 16 en el primer bloque significa que debe arreglar el contenido antes de lanzar un bot de cara al cliente.

Use la puntuación para iniciar una conversación con el equipo, no como una nota de aprobado o reprobado. Las filas con menor puntuación son su primer sprint.

Ejemplos por función

Son escenarios ilustrativos, no casos de estudio medidos.

Soporte al cliente. Imagine un equipo de soporte de software con dos artículos de restablecimiento de contraseña, uno para el inicio de sesión antiguo y otro para el inicio de sesión único. Fusionarlos en un solo artículo, con una breve sección «¿qué inicio de sesión usa?» al comienzo, le da al bot una única fuente. Su propio conjunto de prueba es lo que le dirá cuánto mejora la precisión.

Soporte de facturación y finanzas. La política de reembolsos suele tener excepciones que solo conoce el responsable de facturación: planes anuales, normas regionales, uso parcial. Escribirlas como una tabla de reglas explícita en un solo artículo permite que tanto la IA como los agentes nuevos las apliquen de forma coherente.

Soporte técnico. Digamos que los ingenieros corrigen los problemas en el código, pero soporte nunca registra la solución provisional. Añadir una nota obligatoria de «causa y solución» a la plantilla de cierre crea un flujo constante de borradores de artículos, que un especialista de soporte puede revisar cada semana.

Onboarding y éxito del cliente. Si los CSM responden las mismas preguntas de configuración con plantillas personales, trasladar las mejores versiones a macros compartidas y con responsable da al equipo una redacción coherente y a la IA algo aprobado de dónde tomar.

Operaciones y calidad. Un responsable de QA puede muestrear cada semana las respuestas de la IA frente al conjunto de prueba y registrar cada falla como una corrección de contenido, una corrección de etiquetado o una pregunta de política. Cuando las fallas pasan de brechas de contenido a casos límite poco frecuentes, el trabajo sobre el contenido está dando resultado.

Errores que conviene evitar

• Importarlo todo. Alimentar a la IA con cada artículo, hilo de foro y nota de versión antigua hace que cite los obsoletos. Seleccione el conjunto de fuentes y excluya el contenido archivado.
• Tratar una mejora del modelo como una corrección de contenido. Un modelo mejor no resolverá dos políticas contradictorias. Se contradirá con más elocuencia. Vea la alucinación de la IA para entender por qué las respuestas equivocadas pero fluidas son el principal riesgo.
• Reescribir primero toda la biblioteca. Empiece por los temas que generan volumen. Diez artículos excelentes valen más que 500 depurados por los que nadie preguntó.
• Sin responsables. El contenido sin responsable se deteriora. El primer cambio de política después del lanzamiento romperá algo.
• Saltarse el conocimiento privado. Los runbooks internos y las reglas de escalación importan tanto como los artículos públicos, y a menudo son lo menos organizado. Decida de forma deliberada qué funciones de IA pueden leerlos. Zendesk señala que las respuestas generativas se basan sobre todo en artículos de acceso público, por lo que el contenido restringido puede no usarse.
• Ignorar a las personas. Los agentes que escriben el conocimiento necesitan tiempo y reconocimiento por ello. Vea los roles del equipo de soporte y la IA para saber cómo el trabajo de contenido cambia quién hace qué.
• Lanzar sin un conjunto de prueba. Si no puede medir la calidad de las respuestas antes del lanzamiento, se enterará por los clientes.

Siguientes pasos

Elija los 20 principales motivos de contacto, compruebe que cada uno tiene un artículo vigente y arregle los conflictos. Esa sola auditoría suele aportar más que cualquier configuración de herramienta. Luego construya el conjunto de prueba, fije los responsables y ponga en marcha la revisión semanal de marcas. Después use la visión general para ubicar este trabajo en el despliegue más amplio.