Tienes una documentación decente: una guía de inicio, artículos sobre cada función, la referencia de la API y unas notas de versión que alguien mantiene con cariño. Y aun así, la mitad de lo que llega a soporte es gente preguntando cosas que están escritas ahí. No es que no la lean por pereza: es que buscar en una documentación cuesta más que preguntar.
Un chatbot que responde con esa documentación cambia el reparto: el cliente pregunta como pregunta siempre y recibe la respuesta que ya teníais escrita. La condición es que responda solo con lo que está en tus documentos, y que sepa decir «esto no lo sé» cuando no está.
La respuesta corta
Un chatbot que responde con la documentación de tu software busca en tus documentos los fragmentos que tratan la pregunta y redacta la respuesta solo con ellos. Funciona bien para lo que está escrito y es igual para todos los clientes: cómo se configura algo, qué hace una función, qué significa un error. No sirve para lo que depende de la cuenta de quien pregunta, como su plan o su uso, que necesita consultar tus sistemas, ni para lo que no está escrito en ningún sitio. Para no inventar, tiene que derivar a una persona cuando no encuentra nada que responda, y la documentación tiene que mantenerse al día, porque el chatbot repetirá con toda seguridad lo que diga aunque esté desfasado.
Cómo funciona por dentro
No hace falta entrenar un modelo con tus documentos. Lo habitual, y lo que funciona, es esto:
- Se trocean tus documentos en fragmentos de unos pocos párrafos.
- Cuando llega una pregunta, se buscan los fragmentos que hablan de lo mismo, aunque no usen las mismas palabras: «no me llegan los avisos» encuentra el artículo de «configurar notificaciones».
- El modelo redacta la respuesta con esos fragmentos delante y con la instrucción de no salirse de ellos.
- Si la búsqueda no encuentra nada que trate la pregunta, no responde de memoria: lo dice y pasa la conversación a una persona.
El punto 4 es el que separa un chatbot útil de uno peligroso. Por qué esta técnica funciona mejor que reentrenar el modelo, en RAG o fine-tuning para soporte.
Qué documentación sirve y cuál no
| Fuente | ¿Sirve? | Por qué |
|---|---|---|
| Centro de ayuda / guías de uso | Sí, la mejor | Está escrita para el cliente y por temas |
| Referencia de la API | Sí | Responde dudas de integración con ejemplos exactos |
| Notas de versión | Sí, con fecha | Explican qué cambió y desde cuándo |
| Respuestas de soporte buenas, pasadas a artículo | Sí | Son las preguntas reales, ya respondidas |
| Documentación interna de ingeniería | Con cuidado | Mezcla lo que el cliente puede hacer con lo que no |
| Hilos de Slack o correos sueltos | No | Contradicciones, contexto que falta y datos de otros clientes |
| Presentaciones comerciales | No | Prometen; no explican cómo se hace |
Una regla práctica: si no le mandarías ese documento a un cliente tal cual, no se lo des al chatbot.
Qué preguntas resuelve y cuáles no
| Tipo de pregunta | Ejemplo | ¿La resuelve con docs? |
|---|---|---|
| Cómo se hace algo | «¿Cómo invito a alguien a mi equipo?» | Sí |
| Qué significa algo | «¿Qué quiere decir el error 429?» | Sí |
| Si algo es posible | «¿Puedo exportar a CSV?» | Sí, si está documentado |
| Depende de su cuenta | «¿Cuántos usuarios me quedan en mi plan?» | No: hay que consultar la cuenta |
| Pide que se haga algo | «Cámbiame al plan anual» | No: hay que actuar en tus sistemas |
| No está escrito | «¿Por qué me cobrasteis dos veces?» | No: necesita a una persona |
Las dos filas del medio no son un límite del todo: un agente que además puede consultar la cuenta y llamar a tu API las resuelve. Cómo se monta eso, en automatizar las peticiones de cuenta de un SaaS.
El caso de la documentación técnica
Si tu software tiene API, buena parte de las dudas son de integración: autenticación, límites de uso, webhooks, códigos de error. Son las que más tiempo cuestan a soporte, porque exigen leer código, y las que mejor responde un chatbot con la referencia delante: el ejemplo de petición está escrito, el límite también.
Dos cosas que ayudan mucho:
- Que cada error tenga su página con qué significa, por qué pasa y cómo se arregla. «Error 401» con solo la definición no basta.
- Ejemplos completos, no fragmentos. «Añade la cabecera» no dice qué cabecera ni dónde.
Cómo evitar que se invente cosas
- Que no responda sin fuentes. Si la búsqueda no encuentra nada que trate la pregunta, debe derivar, no improvisar.
- Que lo que tiene que decir siempre no dependa de la búsqueda. Un precio, una política de reembolso o un plazo legal no pueden estar solo en un artículo que a veces no aparece: van en las instrucciones fijas del agente. Más en instrucciones para un agente de IA de soporte técnico.
- Que la documentación no se contradiga. Si dos artículos dicen cosas distintas sobre el mismo límite, el chatbot elegirá uno. Borra o fusiona antes de conectar.
- Revisar las respuestas que fallan, no solo las que se derivan. Qué hacer cuando una respuesta sale mal, en qué hacer cuando un agente de IA da una respuesta incorrecta.
Mantenerlo al día cuando el producto cambia
El chatbot no sabe que habéis cambiado una pantalla: repetirá el artículo viejo con total seguridad. Tres hábitos lo evitan:
- La documentación forma parte del lanzamiento, como las notas de versión: no se da por terminada una función sin su artículo.
- Los artículos llevan fecha de revisión, y los que no se tocan en seis meses se repasan.
- Las preguntas que no encuentra respuesta se leen cada semana. Son la lista exacta de lo que falta por escribir. Cómo sacarla, en cómo detectar qué le falta a la documentación de tu software.
Cómo lo hace Intake
El agente de Intake responde con lo que le conectes: archivos, carpetas de documentos, páginas de tu web, el centro de ayuda y pares de pregunta y respuesta. Responde en el idioma de la pregunta aunque el artículo esté escrito en otro, y cuando la búsqueda no encuentra nada que trate la pregunta, deriva la conversación al equipo en lugar de responder de memoria. Lo tienes explicado en responder con tu documentación.
Preguntas frecuentes
¿Hace falta entrenar un modelo con mi documentación?
No. Lo habitual es buscar en tus documentos los fragmentos que tratan cada pregunta y dárselos al modelo para que responda con ellos. Es más barato, se actualiza al momento y no se inventa lo que no está.
¿Puede responder dudas de la API?
Sí, si la referencia está conectada y cada error y cada endpoint tienen su explicación con ejemplos. Son de las preguntas que mejor resuelve.
¿Qué pasa si la respuesta no está en la documentación?
Debe decir que no lo sabe y pasar la conversación a una persona con la pregunta delante. Un chatbot que responde de memoria cuando no encuentra nada es el que se inventa cosas.
¿Sirve la documentación interna de ingeniería?
Con cuidado. Mezcla lo que el cliente puede hacer con lo que no, y a veces incluye datos internos. Mejor pasar a artículos de cliente lo que sirva.
¿Cómo sé si le falta documentación?
Leyendo cada semana las preguntas que no encontraron respuesta o que se derivaron por falta de información. Esa lista es lo que hay que escribir.
