Cómo diseñar bien un bot, paso a paso (y por qué casi nadie lo hace así)

El orden correcto

1. Primero decide qué NO hace el bot

Antes de pensar en cómo habla, decide qué tareas concretas hace y —más importante— dónde está la frontera: qué situaciones pasa siempre a una persona. Un bot con un trabajo pequeño y claro funciona; un bot que «atiende todo» no atiende nada bien.

Quien lo hace mal: quiere que haga de todo desde el primer día y no define ninguna frontera. Así el bot acaba improvisando precisamente en los casos donde jamás debería decidir solo.

2. Escribe las reglas de tu negocio antes de tocar nada

Tus servicios, tus precios, tus políticas, qué se ofrece solo si lo piden, qué va siempre a una persona. Todo escrito, en un único documento. El bot leerá de ahí.

Quien lo hace mal: no las escribe. Las va descubriendo en producción, cada vez que una conversación revienta. Termina enterándose de sus propias normas por los errores del bot.

3. Dibuja la conversación entera antes de programar

En un papel, mapea los caminos: el fácil (todo va bien) y, sobre todo, los raros: el cliente cambia de idea a mitad, pide dos cosas a la vez, se equivoca, o contesta algo que no esperabas. Aquí decides algo clave: quién lleva el timón, la IA o un guion fijo. Uno de los dos, no los dos.

Quien lo hace mal: no dibuja nada. Programa el camino fácil, lo ve funcionar en una demo y da por hecho que ya está. Los caminos raros —que son la mayor parte de la vida real— los va tapando a parches después.

4. Decide dónde vive el estado y por dónde pasan las acciones

Antes de escribir la primera línea de verdad, contesta dos preguntas: ¿en qué único sitio se guarda en qué punto está cada conversación? ¿Por qué único camino pasan las acciones que importan (reservar, cobrar, cancelar)? Es la parte aburrida, y es exactamente la que separa un bot fiable de uno que se rompe solo.

Quien lo hace mal: no lo decide. El estado acaba repartido por cinco sitios que no coinciden, y la misma acción escrita en tres. Luego arregla un fallo y reaparece idéntico la semana siguiente en otro rincón.

5. Construye primero la parte que actúa, como si la IA no existiera

La lógica que reserva y cobra tiene que funcionar y ser segura por sí sola, sin IA de por medio. La IA se pone después, encima, como quien entiende lo que el cliente quiere y llama a esa lógica. Nunca al revés.

Quien lo hace mal: pone la IA a ejecutar directamente. Le da las llaves de la caja a algo que, por diseño, a veces se inventa cosas.

6. Ata la IA para que no pueda afirmar lo que no ha hecho

Tener ese núcleo sólido por debajo permite una regla de oro: el bot solo puede decir «hecho» si de verdad lo hizo y tiene la prueba en la mano. Que mentir sea imposible, no solo improbable.

Quien lo hace mal: deja que la IA diga lo que quiera y luego intenta cazar las mentiras con filtros. Persigue el error río abajo en vez de impedirlo río arriba.

7. Ensaya con conversaciones reales antes de soltarlo

Reúne un puñado de conversaciones de ejemplo, incluidas las raras, y pásalas por el bot antes de cada cambio. Si algo se rompe, te enteras tú, no un cliente.

Quien lo hace mal: prueba en directo. Su banco de pruebas son sus clientes.

8. Suéltalo poco a poco y míralo

No lo enciendas para todo el mundo de golpe. Empieza con una parte, con una persona vigilando y un sitio donde ver qué está haciendo. Amplía cuando aguante.

Quien lo hace mal: lo enchufa a todos el primer día y se entera de los problemas por las quejas.

El patrón detrás de todos los errores

Si te fijas, quien lo hace mal no es tonto: hace justo lo contrario del orden bueno, y siempre por el mismo motivo. Empieza por lo vistoso —el bot que habla bonito en una demo— y se salta lo aburrido e invisible: las reglas escritas, el mapa de la conversación, dónde vive el estado, la red de pruebas.

Y tiene una lógica perversa detrás. Lo vistoso da resultado en una tarde y lo enseñas orgulloso. Lo aburrido no se ve, no luce, y encima parece que «frena» el proyecto. Así que la gente optimiza para lo que parece progreso, no para lo que sostiene el bot cuando llegan los clientes de verdad.

¿Esto es un fallo puntual o pasa mucho?

Aquí va la parte honesta: pasa muchísimo. No es la excepción, es casi el camino por defecto. Y no porque la gente sea descuidada, sino por cuatro razones de fondo.

Primero, las herramientas de hoy hacen que la demo que habla sea facilísima de montar. Cuando lo fácil y lo lucido es empezar por el final, casi todo el mundo empieza por ahí.

Segundo, los fallos no aparecen en la demo. Aparecen semanas después, con clientes reales y casos raros. Para cuando el problema te enseña la lección, ya lo estás sufriendo en producción. El aprendizaje llega tarde, y por eso se repite tanto.

Tercero, quien monta estos bots muchas veces no es un arquitecto de software: es el dueño del negocio, alguien de marketing o un técnico generalista uniendo piezas. No lo hacen mal a propósito; es que «dónde vive el estado» o «un solo camino para cobrar» no es el trabajo de nadie en la sala.

Y cuarto, la cultura de «lánzalo ya» premia la demo visible por encima de los cimientos invisibles. Nadie aplaude unos cimientos. Todo el mundo aplaude un bot que contesta.

Por eso, cuando ves diez bots con problemas, no son diez mala suertes distintas: son casi siempre las mismas causas repitiéndose, porque casi todos se construyeron saltándose los mismos pasos. Lo que parece un incidente aislado —«a veces confirma citas que no existen», «a veces cobra dos veces»— suele ser el mismo agujero de diseño asomando en sitios distintos.

La buena noticia, y por eso esto no es inevitable: los bots que sí se construyen en el orden bueno no dan estos sustos. No es magia ni cuestión de presupuesto; es aburrimiento bien invertido al principio. La parte tediosa —reglas escritas, conversación dibujada, estado en un sitio, pruebas antes de soltar— es justo la que evita la mayoría de los desastres. Es menos emocionante que la demo, pero es la que hace que el bot siga en pie dentro de seis meses.

Nuestra postura

Cuando montamos bots y automatizaciones, hacemos primero la parte aburrida: definimos la frontera, escribimos las reglas, decidimos dónde vive el estado y por dónde pasan las acciones, y solo entonces ponemos la IA encima —como intérprete, no como ejecutora ciega. No porque seamos especiales, sino porque es el orden que evita los disgustos. Un bot que habla lo monta cualquiera en una tarde; uno que actúa sin darte sustos se construye en el orden correcto.