Diseñar la conversación antes de programar

1.Por qué se diseña antes de programar

La tentación al empezar es abrir el editor y escribir if (texto === "hola"). Funciona los primeros diez minutos; luego aparece el cliente que escribe «buenas, quiero 3 panes y una gaseosa, ¿hacen delivery?» y el código se vuelve un enredo de condiciones.

Un bot es una conversación guiada, y las conversaciones se diseñan igual que una pantalla: primero en papel. Diseñar antes te ahorra reescribir porque respondes preguntas que, si no, te hace el código a las 11 de la noche:

• ¿Qué quiere lograr el cliente cuando escribe?
• ¿Qué debe poder hacer el bot solo, y qué debe pasar a una persona?
• ¿Cómo se ve el bot cuando algo sale mal?

En esta lección no escribirás un bot, sino el plano de uno. En la lección 4 lo convertirás en código, y en la lección 5 el mapa de estados que dibujes aquí se vuelve una estructura de datos.

2.Casos de uso: qué debe y qué NO debe hacer

Un caso de uso es una tarea concreta que el cliente quiere cumplir. Para el minimarket, los más frecuentes son:

La regla práctica: automatiza lo repetitivo y predecible; entrega a una persona lo delicado, lo excepcional y lo emocional. Un bot que intenta hacerlo todo falla en lo difícil y arruina la imagen del negocio.

Escribe, antes de seguir, dos listas cortas. Para el minimarket:

• El bot hace: mostrar horario y dirección, enseñar el catálogo, armar y confirmar pedidos, avisar el estado del pedido.
• El bot NO hace: resolver reclamos, aceptar devoluciones, prometer descuentos que no están publicados, pedir datos de tarjeta, hablar de temas ajenos al negocio.

3.El tono del bot

El tono es cómo «suena» el bot. Es una decisión de marca y se toma una vez para todos los mensajes:

• Tuteo o usted. Un minimarket de barrio puede tutear; una clínica o un estudio legal suele usar «usted». Elige uno y no los mezcles.
• Corto. Se lee en el celular, de pie, con prisa: frases de una o dos líneas, una idea por mensaje.
• Dices lo que puedes hacer. «Puedo mostrarte el catálogo, tomar tu pedido o decirte el horario» orienta mejor que «¿En qué puedo ayudarte?».
• Honesto sobre ser un bot. Un cliente que descubre que hablaba con un programa que fingía ser persona se siente engañado. Una línea basta: «Soy el asistente virtual de Minimarket La Esquina».
• Sin emojis en este curso. Los mensajes de ejemplo no los llevan; en un negocio real son una decisión de marca que puedes tomar después, con moderación.

Compara dos versiones del mismo mensaje:

4.Un flujo de conversación

Un flujo es el camino que sigue la conversación, de la bienvenida al final. Antes de programarlo, dibújalo. Este es el flujo principal del minimarket:

Y este es el flujo de los casos informativos, mucho más corto:

Fíjate en que todo flujo vuelve al menú o a un final claro. Una conversación sin salida es una de las quejas más comunes: el cliente queda escribiendo a un bot que ya no sabe qué hacer.

5.Del flujo al mapa de estados

Un flujo dibujado es fácil de entender; para programarlo conviene pasarlo a una tabla de estados. Un estado es «en qué punto de la conversación está este cliente ahora». Por cada estado anotas qué dice el bot, qué acepta como entrada y a qué estado pasa:

Esta tabla es la columna vertebral del bot. Cuando algo falle, preguntarás: «¿en qué estado estaba el cliente y qué entrada recibió?». La lección 5 la traduce a código.

6.Botones, listas y texto: qué formato usar

WhatsApp permite mensajes de texto libre y mensajes interactivos, que facilitan la respuesta del cliente porque tocan en lugar de teclear. Los dos que usarás son:

• Botones de respuesta (reply buttons): hasta 3 botones debajo del mensaje. Ideales para decisiones cortas: Confirmar / Cambiar / Cancelar.
• Lista (list message): un botón que abre un menú desplegable con varias filas, agrupables en secciones. Ideal para elegir entre 4 a 10 opciones, como el menú principal o las categorías.

Los límites son estrictos. Si los superas, la API rechaza el mensaje y el cliente no recibe nada. Estas son las cifras que figuran hoy en la documentación oficial de Meta:

La decisión es mecánica:

Y un detalle de ingeniería importante: no todos los clientes ven los mensajes interactivos igual (versiones antiguas de la app, otras plataformas). Un bot robusto siempre puede degradarse a una versión de texto numerada («Responde 1 para…, 2 para…»). En el ejercicio escribirás la función que genera ese texto, junto con las que validan botones y listas antes de enviarlos. Un título de 25 caracteres no debe llegar a Meta: lo recortas tú, con criterio, antes.

Ejemplo de menú de respaldo:
1. Ver catálogo
2. Hacer un pedido
3. Horario y dirección

7.Mensajes de error y de «no entendí»

Tu bot se va a equivocar y los clientes van a escribir cosas imprevistas. Lo que diferencia a un bot bueno de uno frustrante es cómo maneja ese momento. Estas son las pautas:

1. No culpes al cliente. «No entendí» (el bot es quien no entendió), no «escribiste mal».
2. Di cómo seguir. Ofrece las opciones disponibles, no solo el fallo.
3. Varía el mensaje la segunda vez. Si el cliente falla dos veces, repetir exactamente lo mismo desespera. Cambia el enfoque: «Parece que no estoy ayudando. ¿Quieres hablar con una persona?».
4. Cuenta los fallos seguidos. Dos o tres «no entendí» consecutivos es la señal para ofrecer una persona.
5. Que el error nunca deje la conversación muerta. Todo mensaje de error termina en una opción.

Una escalera de respuestas típica:

También hay errores propios: el servidor se cae, la base de datos no responde. Al cliente no le muestres jamás un error técnico; dile algo como «Tuve un problema para procesar tu mensaje. Inténtalo en unos minutos o escribe persona para que te atienda alguien». Esto se retoma en la lección 23.

8.El traspaso a una persona (handoff)

El handoff es el momento en que el bot deja de contestar y una persona del negocio toma la conversación. Es parte del diseño, no un parche. Diseña tres cosas:

• Cuándo se activa: el cliente lo pide («persona», «asesor», «reclamo»); el bot falla varias veces seguidas; el tema está en la lista de «el bot NO hace» (un reclamo, una devolución).
• Qué se le dice al cliente: que alguien lo atenderá, cuándo (dentro del horario o no) y que no necesita repetir todo.
• Qué recibe la persona: el historial resumido, el nombre y el motivo, para no empezar de cero.

Un detalle crítico: mientras el estado es humano, el bot no debe responder a los mensajes del cliente; de lo contrario el bot y la persona hablarían a la vez. Y fuera del horario de atención, el mensaje debe ser honesto: «Nuestro equipo atiende de 8:00 a 21:00. Te escribiremos mañana a primera hora». En la lección 25 lo construirás completo.

9.El mismo diseño sirve para cualquier negocio

Todo lo anterior aplica a cualquier negocio con clientes que preguntan lo mismo cien veces. Esta tabla muestra cómo se ve el diseño en otros rubros. Fíjate en que cambian los datos y los flujos, pero la estructura (menú, flujo principal, información fija, handoff) es la misma:

Cuando un cliente te pida un bot, esta tabla es el comienzo de la conversación: «¿cuáles son las 10 preguntas que más te hacen?». Ahí está el 80 % del diseño. La lección 26 retoma esto desde el lado comercial.

10.Errores frecuentes

• Empezar a programar sin saber qué NO hará el bot. Sin esa lista, el alcance crece sin control y el bot promete lo que no puede cumplir.
• Menús demasiado largos. Diez opciones en un solo mensaje abruman; filtra por pasos.
• Superar los límites de botones o listas. La API rechaza el mensaje completo; valida antes de enviar.
• Un «no entendí» idéntico, una y otra vez. Varía el mensaje y ofrece una persona al tercer fallo.
• Flujos sin salida. El cliente debe poder volver al menú, cancelar o pedir ayuda en cualquier punto.
• Que el bot siga hablando cuando ya atiende una persona. El estado humano debe silenciar al bot.
• Pedir datos sensibles en el chat. Nunca contraseñas ni tarjetas completas.

11.Apuntes para llevar

• Diseña antes de programar: casos de uso, qué sí y qué no hace el bot, tono y flujos.
• Automatiza lo repetitivo; entrega a una persona lo delicado y lo excepcional.
• Un mapa de estados en tabla (estado, mensaje, entradas, siguiente estado) es el plano del bot.
• Botones: máximo 3 y 20 caracteres por título. Listas: máximo 10 filas y 24 caracteres por título (verifica en la documentación de Meta).
• Todo mensaje de error debe terminar con una opción; tras 2 o 3 fallos, ofrece una persona.
• El handoff se diseña: cuándo, qué se dice y qué información recibe la persona.
• El diseño es el mismo para cualquier negocio; cambian los datos.

12.Glosario