La mitad de las veces que un cliente pregunta algo documentado, el artículo existe y no lo ha encontrado. Escribir otro empeora el problema: ahora hay dos resultados mediocres compitiendo por la misma búsqueda.
Este post explica qué hace que un centro de ayuda funcione, para las personas que lo leen y para la IA que lo usará para responder.
¿Qué hace que un centro de ayuda se lea?
Que cada artículo responda una sola pregunta, se titule con las palabras del cliente, dé la respuesta en la primera frase y esté enlazado desde la pantalla donde surge la duda. Y que alguien mire cada mes las búsquedas que no devolvieron nada. Lo demás (diseño, categorías, portada) importa mucho menos de lo que parece.
Antes de escribir nada
Mira si ya está escrito. Busca en tu centro de ayuda las palabras con las que preguntó el cliente, no las vuestras. Si el artículo aparece, el problema está en el buscador o en el título, y escribir otro lo empeora.
Ordena por frecuencia y coste, no solo por frecuencia. Una pregunta que llega cinco veces al mes y acaba pasando a ingeniería cuesta más que una que llega cincuenta y se responde en dos minutos. La segunda sale primero en cualquier informe, y es la que menos importa. Si no tienes tu coste por ticket, aquí está el método.
Separa lo que se puede documentar de lo que no. «¿Cómo invito a un compañero?» se documenta. «¿Por qué no me deja invitar?», no, porque depende de los asientos de ese plan. Ningún artículo resuelve el segundo tipo, y confundirlos es lo que hace que un proyecto de documentación decepcione. Está desarrollado en reducir tickets repetidos.
Cómo escribir cada artículo
El título es el de tu cliente
Si vosotros lo llamáis «política de retención» y el cliente escribe «cuánto tiempo guardáis mis datos», el artículo se llama lo segundo. El vocabulario interno es lo que más daño hace a un centro de ayuda.
La fuente está en tu bandeja: copia tal cual cómo lo escribe la gente. Tres cambios de título que multiplican las visitas:
- «Gestión de miembros del espacio» → «Cómo invitar a alguien de mi equipo»
- «Facturación y ciclos» → «Cuándo me cobráis y cómo cambio la tarjeta»
- «Configuración de webhooks» → «No me llegan los webhooks: qué revisar»
La respuesta va primero
La primera frase responde la pregunta; el contexto va después, para quien lo necesite.
Así, además, el fragmento se puede citar: los buscadores y los sistemas de IA que leen tu documentación se quedan con las primeras frases, y si ahí solo hay una introducción, se quedan con la introducción.
Un artículo, una pregunta
El artículo que explica cuatro cosas no sale bien en ninguna de las cuatro búsquedas. Mejor veinte artículos cortos que cinco largos. Si un artículo necesita índice, son varios artículos.
Los pasos son pasos
Numerados, uno por acción, con lo que el cliente ve después de cada uno. Si un paso necesita una explicación de tres líneas, ese paso son dos.
Di lo que no se puede hacer
Los artículos que solo explican el caso en que todo sale bien generan tickets. Si la función tiene un límite («solo en el plan Pro», «máximo diez por espacio», «no se puede deshacer»), dilo en el artículo. El cliente que se lo encuentra sin aviso escribe, y además molesto.
Fecha y versión, si el producto cambia
Un artículo con la captura de una pantalla que ya no existe hace más daño que no tener artículo: el cliente cree que el que falla es él. Pon la fecha de la última revisión y ten una lista de artículos a revisar cada vez que cambie una pantalla.
Cómo organizarlo
Menos categorías de las que te apetece: cinco o seis, con nombres de tarea («Empezar», «Facturación», «Equipo y permisos», «Integraciones», «Problemas frecuentes») y no de módulo del producto. Nadie busca «Módulo de administración».
Y un buscador que perdone sinónimos, faltas de ortografía y las palabras del cliente. Si solo encuentra coincidencias exactas, es como si la mitad de tus artículos no existieran.
Dónde ponerlo
Un artículo enlazado desde la pantalla donde surge la duda se lee. El mismo artículo en un centro de ayuda al que hay que ir a buscarlo, no.
Es el cambio con más efecto y el que menos se hace, porque exige que soporte pueda tocar el producto: un enlace en el mensaje de error, un «¿cómo funciona esto?» junto al ajuste, una sugerencia en el chat cuando el cliente escribe las primeras palabras. Es lo que hace sugerir artículos.
Lo que hay que medir
- Las búsquedas sin resultado. Son la lista de artículos que faltan, escrita gratis por tus clientes, y casi nadie la mira.
- Los artículos más vistos que acaban en ticket. Si la gente sale de un artículo muy leído para escribirte, ese artículo no responde. Revisarlo vale más que escribir tres nuevos.
- Cuántas visitas al centro de ayuda terminan sin contacto. Es la tasa de desvío, y solo significa algo si además el cliente no vuelve al día siguiente por otro canal.
- Qué preguntan en el chat que no está escrito. Si tienes un agente de IA delante, te lo dice él: las preguntas que no supo responder son tu lista de artículos pendientes, ordenada por frecuencia.
El centro de ayuda como base de un agente de IA
Si vas a poner un sistema de IA encima, ten en cuenta que no puede responder mejor de lo que está escrito. La calidad de tu documentación marca el techo, y eso cambia las prioridades:
- Los artículos ambiguos producen respuestas ambiguas, con más seguridad de la que merecen.
- Los artículos desactualizados producen respuestas incorrectas, y ahora a escala.
- Los huecos no se notan: el sistema recupera lo más parecido que encuentra y redacta con eso.
- Los artículos que mezclan cuatro temas hacen que el fragmento recuperado sea el equivocado.
Antes de conectar nada, revisar los veinte artículos más leídos rinde más que cualquier ajuste del modelo. El detalle está en preparar la documentación para un agente de IA.
Y al revés: un agente que responde desde el centro de ayuda es la forma más barata de saber qué artículos faltan, porque cada «no lo sé» señala un hueco concreto.
En orden
- Clasifica cien conversaciones de tu bandeja
- Revisa si lo documentable ya está escrito y no se encuentra
- Retitula con las palabras del cliente
- Escribe lo que falte, por frecuencia y coste
- Coloca los enlaces donde surge la duda
- Mide las búsquedas sin resultado, cada mes
Los pasos 2 y 3 son gratis y suelen resolver más que el 4.
Preguntas frecuentes
¿Base de conocimiento o centro de ayuda?
El centro de ayuda es lo que ve el cliente; la base de conocimiento es todo lo que sabe el equipo, público o no. Un agente de IA puede leer las dos y responder solo con la parte pública. Más en ¿base de conocimiento o centro de ayuda?.
¿Cuántos artículos necesito para empezar?
Los que respondan a las veinte preguntas más frecuentes de tu bandeja. Mejor veinte artículos que responden que cien que rellenan.
¿Necesito un centro de ayuda para usar un agente de IA?
No necesariamente: el agente puede leer documentos internos, notas o una carpeta. Pero un centro de ayuda público sirve para las dos cosas a la vez. Más en ¿necesito un centro de ayuda para usar una base de conocimiento?.
¿En qué idioma escribo si tengo clientes en varios?
En uno, y bien. Un agente responde en el idioma de la pregunta aunque el artículo esté en otro; traducir todo el centro de ayuda puede esperar.
¿Cada cuánto hay que revisarlo?
Los veinte más leídos, cada vez que cambie una pantalla del producto. El resto, una vez al trimestre con la lista de búsquedas sin resultado delante.
