Chatbot para empresas: qué resuelve, qué no y cuándo necesitáis un agente

Casi todo el mundo recuerda un chatbot que no servía para nada: el de una web que repetía las mismas tres respuestas y acababa dando un teléfono. Esa experiencia dejó a muchas empresas con la idea de que esto no funciona.

Lo que ha cambiado no es que ahora «entiendan mejor». Es que ya no hace falta anticipar las preguntas. Antes alguien tenía que escribir cada rama de la conversación, y bastaba con que un cliente preguntara de otra manera para que el bot se perdiera. Hoy el sistema puede leer vuestra documentación y responder sobre ella, lo que mueve el trabajo de escribir diálogos a tener buenas fuentes.

Pero «chatbot para empresas» sigue nombrando tres productos muy distintos, con costes, riesgos y resultados que no se parecen. Elegir el que no toca es la forma habitual de repetir la decepción.

Los tres que se llaman igual

1. El bot de flujos

Un árbol de conversación escrito a mano. El usuario elige entre opciones y el bot le lleva por una ruta prevista.

Resuelve trámites acotados y repetitivos: pedir una cita, consultar un estado, recoger los datos de un formulario antes de pasar a una persona.

No resuelve nada que no estuviera previsto. Toda pregunta nueva es trabajo de alguien.

Cuándo conviene. Cuando las peticiones son pocas y siempre las mismas, y lo que queréis es ahorrar la parte mecánica. Es barato, predecible y no se inventa nada.

Cuándo no. Como atención general. Es el que dejó mala fama a la categoría.

2. El asistente sobre vuestra documentación

El sistema busca en vuestros manuales, procedimientos, fichas o histórico y responde citando de dónde sale cada cosa.

Resuelve las preguntas cuya respuesta ya está escrita en algún sitio, pero repartida en documentos que nadie se lee enteros.

No resuelve lo que no esté documentado. Si la respuesta vive en la cabeza de una persona, el asistente no la va a encontrar, y conviene saberlo antes de empezar y no después.

Cuándo conviene. Es donde más veces hemos visto que compensa, y casi siempre primero hacia dentro: soporte al propio equipo sobre procedimientos, normativa interna, especificaciones técnicas o condiciones de cliente.

Cuándo no. Cuando la documentación está desactualizada o se contradice. Entonces el asistente hace visible el desorden a gran velocidad, que puede ser útil, pero no es lo que habíais comprado.

3. El agente que ejecuta

Además de responder, hace: consulta sistemas, crea un registro, prepara un presupuesto, avisa a quien corresponda, abre una incidencia.

Resuelve el trabajo, no solo la pregunta. Es la diferencia entre decir «vuestro pedido salió ayer» y gestionar la reclamación.

No resuelve nada sin permisos, reglas y trazas. Un agente que escribe en vuestros sistemas es software de producción, con lo que eso implica.

Cuándo conviene. Cuando el proceso está claro, el resultado es verificable y se puede empezar con confirmación humana.

Cuándo no. Como primer proyecto, si todavía no sabéis qué preguntan vuestros equipos ni con qué precisión responde el sistema.

La comparación

	Preguntas imprevistas	Riesgo de error	Coste inicial	Mantenimiento
Bot de flujos	Ninguna	Muy bajo	Bajo	Escribir cada caso nuevo
Asistente documental	Alta	Medio	Medio	Mantener las fuentes
Agente	Alta	Alto	Medio	Reglas, permisos y excepciones

Lo que no aparece en la tabla y decide el proyecto es el estado de vuestras fuentes. Un asistente sobre documentación ordenada funciona la primera semana. Sobre una carpeta compartida con tres versiones de cada procedimiento, no hay presupuesto que lo arregle.

Primero, dos preguntas

¿Quién pregunta? Un empleado y un cliente no toleran lo mismo. Con el equipo propio, una respuesta imprecisa se detecta y se corrige. Con un cliente, puede convertirse en un compromiso que alguien tiene que cumplir. Por eso casi siempre recomendamos empezar hacia dentro: el mismo trabajo, menos riesgo, y los primeros meses sirven para medir.

¿Qué pasa si se equivoca? Si la respuesta es «nada, se pregunta otra vez», se puede ir rápido. Si es «perdemos un cliente» o «incumplimos una condición», hay que medir antes de abrirlo y dejar siempre una salida a una persona.

Lo que hace que fracasen

Cuatro cosas, y ninguna es el modelo.

No citan la fuente. Una respuesta sin el documento del que sale no se puede verificar. En cuanto alguien pilla un error, deja de usarse, y con razón.

No saben decir que no saben. Un sistema que prefiere improvisar antes que decir «esto no está en la documentación» es peor que no tenerlo, porque el error se descubre tarde.

No se miden. Sin un conjunto de preguntas con respuesta conocida, nadie sabe si el asistente va bien. Y sin eso, cualquier cambio es a ciegas.

No tienen dueño. Las fuentes envejecen. Si nadie es responsable de actualizarlas, a los seis meses responde con el procedimiento del año pasado.

Dos preguntas más que conviene hacer por escrito antes de firmar, y que no van de tecnología: qué datos salen de vuestra empresa y a dónde van, porque aquí hay documentación interna y conversaciones de clientes, y qué os lleváis si os vais, que además de las fuentes incluye las preguntas de evaluación y el histórico de conversaciones.

Cómo se mide de verdad

El número de conversaciones no dice nada. Lo que hay que medir es esto:

• Precisión sobre un conjunto de preguntas conocido. Se escriben entre cincuenta y doscientas preguntas reales con su respuesta correcta, y se mide contra ellas cada vez que se cambia algo.
• Cobertura. Qué porcentaje de lo que se pregunta está en las fuentes. Lo que falta es una lista de qué documentar.
• Resueltas sin escalar. De las que llegan, cuántas terminan ahí.
• Errores detectados. Y, sobre todo, cuántos los detectó el sistema y cuántos una persona.

Esto no es teoría. En Mike, un asistente legal para agentes inmobiliarios, el trabajo consistió exactamente en eso: pasó del 40 % al 97 % de precisión medida sobre un conjunto de preguntas de referencia. El salto no vino de cambiar de modelo, sino de ordenar las fuentes, acotar el alcance y medir cada iteración.

El detalle de cómo se monta un asistente así, con sus fuentes y sus criterios de evaluación, está en asistentes de IA sobre documentación técnica.

El caso concreto de la atención al cliente

Es lo primero que casi todo el mundo pregunta, y merece respuesta aparte porque es donde más proyectos se tuercen.

Un chatbot de atención funciona cuando puede consultar el estado real de algo. «¿Dónde está mi pedido?» solo tiene respuesta si el bot ve el sistema donde vive el pedido. Sin esa conexión, lo único que puede hacer es explicar el procedimiento, que es justo lo que el cliente no estaba preguntando. Por eso un chatbot de atención es, antes que nada, un proyecto de integración.

Tres cosas que conviene decidir antes de abrirlo al público:

La salida a una persona. Tiene que estar siempre, visible y en cualquier punto de la conversación. Un bot que no deja salir genera más llamadas de las que evita.

El horario. Buena parte del valor está en las horas en las que no hay nadie. Si el bot solo responde cuando el equipo está disponible, compite con el equipo en lugar de complementarlo.

Lo que no puede decir. Precios fuera de tarifa, plazos que no estén confirmados, condiciones particulares de un cliente. Eso no se resuelve pidiéndoselo por escrito al modelo: se resuelve no dándole acceso a esa información o filtrando la respuesta con una regla.

Y una expectativa realista: el objetivo razonable de un primer año no es sustituir a nadie, es que las preguntas repetidas dejen de llegar al equipo para que el equipo atienda las que de verdad necesitan a una persona.

Dónde está la frontera con el agente

La línea no la marca la tecnología, la marcan los permisos. Un asistente que lee es reversible: si se equivoca, se corrige la respuesta. Un agente que escribe deja rastro en vuestros sistemas.

Por eso el orden sensato es: primero leer, medir y ganar confianza. Después ejecutar, empezando por acciones de bajo impacto y con confirmación. Lo que define un agente bien hecho no es que haga muchas cosas, sino que esté claro qué puede hacer sin preguntar, qué tiene que confirmar y dónde queda registrado.

Si lo que buscáis ya es esa parte, lo tratamos en consultoría e implantación de IA.

Lo que cuesta ahora

La parte de software ha dejado de ser lo caro. Montar un asistente sobre un conjunto de documentos, con sus citas y su evaluación, es hoy trabajo de semanas, no de trimestres, y eso ha cambiado qué empresas pueden planteárselo.

Lo que no ha bajado es lo demás: ordenar las fuentes, escribir el conjunto de preguntas de evaluación, decidir qué pasa con lo que no sabe y asignar a alguien que lo mantenga. En un proyecto de este tipo, esa parte es la mayoría del esfuerzo, y es la que determina si al año sigue sirviendo.

La consecuencia práctica es que la pregunta ya no es si os lo podéis permitir, sino si vuestra documentación aguanta. Una empresa de treinta personas puede tener hoy un asistente interno decente. La misma empresa, con los procedimientos sin actualizar desde 2021, no.

La pregunta que decide si esto va a funcionar

No es cuál elegir ni cuánto cuesta. Es si alguien de vuestra empresa puede señalar, hoy, el documento que está vigente para un procedimiento cualquiera. Si la respuesta tarda más de un minuto, ese es el proyecto, y el asistente viene después.

Suponiendo que sí: un ámbito, un grupo de usuarios y un conjunto de fuentes que alguien reconozca como vigentes. Durante las primeras semanas, con el equipo interno y con las respuestas a la vista de quien sabe si son correctas.

De ahí sale lo único que importa para decidir si seguir: qué porcentaje de preguntas resuelve bien, qué parte de lo que se pregunta no está documentado y cuánto tiempo le ahorra a quien antes contestaba esas preguntas.

Si no tenéis claro qué ámbito elegir, el diagnóstico de IA ayuda a localizarlo en diez minutos y devuelve un informe con el primer proceso que merece la pena.