Cómo crear un agente de IA de soporte técnico para un SaaS

El equipo de soporte de un SaaS recibe el mismo tipo de preguntas una y otra vez: no puedo iniciar sesión, mis cambios no se guardan, la integración dejó de funcionar. Responder cada una a mano es lento, y un chatbot que solo repite enlaces genéricos a la documentación tampoco resuelve nada — el cliente sigue sin saber qué botón tocar.

En esta guía montamos, paso a paso, un agente de IA que diagnostica el problema con preguntas concretas y responde con pasos reales de tu documentación técnica, sin inventar una solución que no ha verificado — y que sabe admitir cuándo no puede resolver algo y escala a una persona en vez de dar por cerrado un caso que no lo está.

Por qué diagnosticar antes de responder

Un enlace genérico a "la documentación" no resuelve nada si el cliente ya la leyó y no encontró su caso. El agente que vamos a configurar hace lo que haría un buen técnico de soporte:

1. Pregunta antes de responder: pide detalles concretos (qué mensaje de error ve, qué intentó antes, en qué plan está) en vez de dar una respuesta genérica a la primera.
2. Responde con pasos reales, citando los nombres exactos de menús y botones de la documentación — nunca una solución inventada o aproximada.
3. Admite lo que no sabe: si el problema no está cubierto por la documentación, lo dice con honestidad y escala a una persona, en vez de improvisar o dar el caso por resuelto.

Paso 1: elige el caso de uso en el asistente

Al crear un agente de texto nuevo, el asistente muestra las plantillas disponibles organizadas por caso de uso. Para soporte técnico, la plantilla ya viene orientada a diagnóstico y resolución — no a ventas ni a agendamiento — con un flujo pensado para confirmar el problema antes de ofrecer cualquier solución.

Al seleccionarla, el asistente deja preconfiguradas las dos herramientas que este agente necesita:

• Base de conocimiento, para responder con la documentación real del producto.
• Transferencia, para pasar la conversación a una persona cuando el agente no pueda resolver el caso con honestidad.

A diferencia del agente de recepción o del de cualificación de leads, este no necesita calendario ni herramienta de clasificación — su trabajo es resolver o escalar, nada más.

Paso 2: dale contexto real al agente

Si aportas la web del producto, el asistente adapta automáticamente el rol, el objetivo y el backstory del agente con el nombre real de tu SaaS — en vez de dejar los ejemplos genéricos de la plantilla.

La parte que más importa aquí es la base de conocimiento: cuanto más específica y actualizada sea tu documentación técnica, menos veces el agente tendrá que decir "no tengo esa información disponible" o escalar un caso que en realidad tenía solución conocida.

Si quieres partir de una base en vez de empezar de cero, puedes descargar las mismas plantillas de ejemplo que usamos para configurar el agente de este artículo — documentadas para Kanbo, un producto ficticio de gestión de tareas en tableros kanban:

Documentación técnicaArchivo MD Preguntas frecuentesArchivo MD

Sube ambos archivos como base de conocimiento: el primero cubre errores concretos y sus pasos de solución (cuenta, sincronización, integraciones, límites por plan), el segundo las preguntas generales de producto y facturación que no son un error puntual a diagnosticar.

Paso 3: revisa las herramientas del agente

Una vez creado, el agente queda representado como un flujo con sus dos herramientas conectadas: base de conocimiento y transferencia a un humano. A diferencia de otros casos de uso, aquí no hay ningún paso adicional de conexión externa que configurar — con la documentación subida, el agente ya puede empezar a responder.

Así se ve una conversación real

Esta es una conversación real con Kai, probada desde el widget de chat en vivo: un cliente reporta que la integración con Slack dejó de enviarle notificaciones. Antes de decir nada, el agente pregunta por detalles concretos — plan contratado, desde cuándo, si hay algún mensaje de error — en vez de lanzar una lista de pasos genéricos a la primera.

Con el dato de que el error es "Token caducado", el agente consulta la documentación real y responde citando los nombres exactos de la interfaz — "Ajustes del tablero → Integraciones → Slack", el botón "Reconectar" — no una aproximación ni un paso inventado.

Qué hacer si el agente no puede resolver algo

El cliente sigue con un tema que Kai no puede resolver por su cuenta: un cobro duplicado. El agente no inventa una solución ni promete un reembolso que no puede gestionar — cuando el cliente pide explícitamente hablar con una persona, escala de verdad, y el chat pasa de estar atendido por Kai a estar atendido por un agente humano real.

Es mejor que el agente diga "voy a conectarte con nuestro equipo" a que invente una solución que no ha verificado — un cliente frustrado por una respuesta incorrecta cuesta más que uno que esperó unos minutos más por una persona real.

El prompt final, para verlo completo

Todo lo anterior — la plantilla, la documentación técnica y las preguntas frecuentes — es lo que el asistente combina para generar el prompt final del agente. Si quieres ver exactamente cómo queda ese resultado, puedes descargar el prompt ya resuelto para Kanbo, el mismo producto ficticio que usamos en esta guía:

Prompt del agente de soporteArchivo MD

Úsalo como referencia de la estructura y el nivel de detalle que conviene darle a un agente de soporte — no hace falta escribirlo desde cero: el asistente genera algo muy parecido a esto automáticamente en cuanto le das la web y la documentación real de tu producto.