Si voy a lanzar un bot en WhatsApp, lo pruebo antes como si ya estuviera hablando con clientes. Mi foco está en 6 frentes: intención, datos en tiempo real, templates, pase a humano, respuesta en menos de 2 segundos y localización es-AR.
En corto: no me alcanza con que el bot pase un guion. También lo testeo con mensajes confusos, audios, emojis, falta de stock, pedidos en distintas etapas y cortes en integraciones. Y si no llega al 90% de acierto en intención o supera 15% de fallback, lo vuelvo a revisar.
Antes de salir a producción, yo hago esto:
La idea es simple: probar en un entorno seguro, cubrir los casos que más pegan en ventas y soporte, y usar datos reales del uso diario para ir ajustando el bot versión tras versión.
Ciclo de Pruebas para Bots de WhatsApp en Argentina
Separá por completo el entorno de pruebas del de producción antes de validar cualquier flujo. Recién cuando esa base esté aislada, configurá el número, los webhooks y los datos de prueba.
Usá un número de WhatsApp exclusivo para testing, que nunca haya sido registrado en la app estándar ni en WhatsApp Business. También conviene tener un webhook aparte del de producción y guardar las claves en variables de entorno. Así evitás mezclar tráfico real con pruebas.
Durante el desarrollo, simulá respuestas de la API sin hacer llamadas reales. Eso te ayuda a evitar rate limits y costos al pepe. Y antes de procesar cada request entrante, validá la firma X-Hub-Signature-256.
No pruebes solo desde emuladores. Hacelo en dispositivos reales con iOS y Android, porque botones, audios e imágenes pueden verse o comportarse distinto según el sistema y la versión.
Después, cargá datos que se parezcan a los casos que vas a ver en Argentina. Si los datos no se parecen a producción, el test sirve a medias.
Incluí, por ejemplo:
Usá direcciones con formato local de Argentina y montos en ARS, por ejemplo $ 24.999,00. También vale la pena probar ventanas de entrega de 2 a 3 días hábiles, un rango habitual para envíos dentro del país.
Sumá además inputs comunes del usuario argentino: notas de voz, imágenes, documentos y consultas de seguimiento. Probar estos formatos desde el arranque evita sorpresas cuando el bot ya esté en vivo.
Con el entorno listo y los datos cargados, toca definir qué vas a probar. No hace falta armar cientos de casos. La idea es cubrir los flujos clave y los fallos que más suelen aparecer. Como base, probá primero compra, soporte y derivación.
Cada flujo tiene tres partes que conviene dejar claras antes de correr la prueba: qué respuesta esperás del bot, qué acción tiene que disparar en el backend y cuál es el criterio de éxito. Si eso no está definido, después no hay forma de saber si el test salió bien o mal.
| Flujo | Respuesta esperada del bot | Acción de backend | Criterio de éxito |
|---|---|---|---|
| Saludo y menú | Bienvenida + opciones (botones) | Registrar sesión en CRM | El usuario elige una opción válida |
| Consulta de producto | Detalle con talle, color y precio en ARS | Consulta al catálogo vía API | El usuario agrega al carrito o sigue preguntando |
| Estado del pedido | Etapa actual + fecha estimada de entrega | Consulta al OMS/API de seguimiento | Datos correctos, sin necesidad de escalar |
| Recuperación de carrito | Recordatorio con número de pedido + urgencia de 48 hs | Trigger de campaña en CRM | El usuario retoma el flujo de compra |
| Derivación a agente | "Te estoy conectando con un asesor…" | Aviso al equipo | El agente recibe el historial completo del chat |
Poné el foco en el flujo de derivación. Cuando entra un agente, el bot tiene que pausar su turno para no pisar la conversación. Si no lo hace, el chat se vuelve un caos en segundos.
En el flujo de seguimiento pasa algo parecido. Si el OMS no responde, el bot no puede dejar al usuario esperando sin decir nada. Tiene que dar una salida: una respuesta de contingencia o un escalamiento inmediato.
Con esos flujos cubiertos, seguí con templates, bajas y casos límite.
Los templates también merecen pruebas aparte. Verificá que Meta no los rechace, que estén segmentados por país e idioma y que el contenido coincida con los datos reales del pedido.
El opt-out es un punto sensible. Probá que, al recibir "BAJA" o "STOP", el bot deje de enviar mensajes y actualice enseguida el campo que corresponde en el CRM. Un error acá puede bajar la calificación de calidad del número en WhatsApp.
Para los casos límite, incluí situaciones como estas:
En todos esos casos, el bot tiene que responder con un mensaje claro y útil. No alcanza con cortar el flujo o tirar una salida genérica.
Después de validar los flujos críticos, probá cómo se mueve el bot en el uso diario de WhatsApp.
Validá el voseo y el tono local, sobre todo en respuestas cortas y cuando cambia el contexto. También conviene probar mensajes breves en ráfaga, audios, imágenes, PDFs y cambios de tema a mitad de conversación.
Con los casos ya definidos, ejecutalos en dos capas: manual para ver la experiencia de punta a punta, y automatizada para vigilar los flujos que no pueden fallar. La idea es simple: primero mirás cómo se comporta el bot en una situación real; después, convertís esos chequeos en pruebas repetibles.
Probalo en distintos celulares y con cuentas de WhatsApp diferentes para revisar menús, transiciones y el comportamiento en iOS y Android. Arrancá por los flujos de compra, soporte y derivación que ya definiste.
Tocá botones, listas, imágenes y PDFs para confirmar que cada acción dispare lo que corresponde y que todo se vea bien en pantalla.
Anotá cualquier dato incorrecto, enlace roto, demora, derivación mal hecha o frase que suene rara en es-AR. Acá conviene ser estricto: si el bot habla de más, recortá. En WhatsApp, el texto largo suele jugar en contra.
Lo que falle en esta etapa después se automatiza, así no volvés a tropezar con la misma piedra.
Automatizá los flujos más repetidos o los que no podés permitirte que fallen. La prioridad está en estado de pedido, stock, plantillas, descuentos y respuestas de respaldo.
Para diálogos de varios turnos, Botium o Bespoken sirven para revisar que el contexto se mantenga durante toda la charla. Y para los endpoints del backend, Postman o Newman alcanzan para correr estos chequeos de forma repetida.
Tomá como piso 90% de precisión de intención y menos de 15% de fallback. Si un flujo queda por debajo de esos valores, mandalo al bloque de debugging. Y si un error aparece seguido en estos chequeos, que pase directo a logs y corrección.
En producción siempre aparecen fallos que no saltan en testing. Por eso conviene revisar el bot todas las semanas, sin falta.
El primer paso es ordenar el problema. Los errores más comunes suelen caer en tres grupos: diseño, integración y entrega.
Con esa base, aislá cada incidente en registros separados. Centralizá los logs con timestamps y clasificá cada caso según la causa más probable: diseño, webhook, inventario o entrega. Ese corte te ahorra tiempo, porque evita mezclar problemas distintos y te deja ver dónde se rompe el flujo.
Si falla la entrega, mirá primero la calificación del número y el estado de las plantillas. Si el problema viene por integración, validá el webhook y el inventario en tiempo real.
En Burbuxa, los logs y los dashboards de auditoría aceleran el diagnóstico cuando se cae ventas, soporte o campañas.
Después, medí si el problema fue aislado o si se repite. Revisá cada semana la tendencia de fallback, la resolución sin humano, el tiempo de respuesta y el CSAT.
Antes de publicar cambios, corré regresión sobre un golden dataset de frases reales por intención.
Si sube la derivación, andá primero a la intención que está fallando. Después revisá las reglas de escalado. Ese orden importa: si atacás el síntoma antes que la causa, perdés tiempo y el error vuelve.
Con diagnóstico y métricas en mano, el bot mejora versión tras versión. Un bot confiable sale de un ciclo que se repite: entorno seguro → casos de alto impacto → localización para Argentina → pruebas manuales y automatizadas → datos de producción para mejorar.
Cada semana cerrá ese ciclo con datos nuevos y una nueva regresión.
Conviene arrancar con uno o dos casos de uso bien puntuales, en lugar de querer automatizar todo de entrada. Lo más lógico suele ser poner el foco en atención al cliente, sobre todo en esas preguntas frecuentes que consumen tiempo todos los días: estado de pedidos, horarios, devoluciones o confirmación de reservas.
Con Burbuxa, esas consultas repetitivas se pueden resolver de forma automática, las 24 horas. Y cuando esos procesos ya estén probados y funcionando bien, podés escalar el uso de IA para consultas más complejas y para recuperar carritos abandonados.
Hacé pruebas de extremo a extremo (E2E) que imiten el recorrido de una persona usuaria de punta a punta. Mandá audios e imágenes desde distintas cuentas de WhatsApp para chequear que el bot los procese, responda o guarde como corresponde.
Si usás Burbuxa para manejar tus flujos, estas pruebas también te ayudan a confirmar que la integración con tu tienda sigue sincronizando los datos sin problemas y que las respuestas automáticas están a la altura de lo que esperás.
Si una integración falla, arrancá por lo básico: revisá la conexión con la API de WhatsApp Business. Asegurate de que los webhooks estén bien configurados, que los tokens sigan vigentes y que los logs te muestren con claridad dónde se corta el flujo. También conviene mirar la respuesta del servidor para detectar el error puntual.
Si usás Burbuxa, gran parte de la configuración técnica queda centralizada, y eso te simplifica bastante el control. En un desarrollo a medida, en cambio, hay que mirar más de cerca varios frentes: los rate limits, las pruebas en sandbox, la validación de plantillas y la confirmación de que la escalación a un agente humano esté activa.
