Cómo probar un chatbot en WhatsApp antes de activarlo: 12 escenarios prácticos

IA y WhatsApp

Un chatbot respondió correctamente el horario de apertura. ¿Eso ya permite ponerlo a atender clientes? Aún falta descubrir qué ocurre cuando alguien cambia de tema, pide una excepción o recibe información incompleta. Para probar un chatbot en WhatsApp antes de activarlo, prepare conversaciones de prueba, defina la respuesta esperada y compruebe también qué hace el sistema después de responder.

El guion a continuación es una propuesta práctica de evaluación. Los escenarios son ilustrativos, no resultados de pruebas de una plataforma específica. Adáptelos al servicio de su empresa y a las funciones contratadas.

Prepare un entorno de prueba y una referencia confiable

Use contactos del propio equipo y registros ficticios claramente identificados. Separe la prueba del servicio real y desactive acciones que puedan cobrar, enviar campañas o modificar pedidos de clientes. Si la plataforma no ofrece un entorno separado, pacte con el proveedor una forma segura de simular estas acciones antes de continuar.

Elija una versión de referencia para precios, horarios, catálogo y políticas comerciales. Registre la fecha y quién aprobó cada información. Una respuesta solo puede evaluarse cuando existe un criterio para decir si está correcta.

Si aún está definiendo qué automatizar, consulte primero la guía sobre cómo responder a clientes automáticamente en WhatsApp. Aquí, el foco es verificar si el servicio preparado funciona en situaciones concretas.

Monte una ficha para cada conversación

Anote el escenario, los mensajes enviados, la respuesta recibida, la acción realizada y el resultado esperado. Añada responsable, fecha y versión de la configuración. Use tres resultados: aprobado, reprobado o no aplicable. Marque como no aplicable solo una función que realmente esté fuera del alcance contratado y divulgado.

Evite aprobar una conversación solo porque el texto parece simpático. Verifique valores, condiciones, destino de la transferencia y registros producidos. Una confirmación de cita sin reserva registrada es una falla.

12 escenarios para probar el servicio

1. Pregunta simple con respuesta conocida

Envíe “¿Abren los sábados?”. La respuesta debe coincidir con el horario aprobado e identificar la sucursal cuando haya más de una. Repruebe si el chatbot completa una información ausente por su cuenta.

2. La misma duda escrita de otra forma

Pruebe “¿abren sab?”, “¿puedo ir el fin de semana?” y una frase con error tipográfico. El resultado esperado es mantener la información correcta o pedir aclaración. No exija que se adivine una pregunta ambigua.

3. Dos preguntas en el mismo mensaje

Pruebe “¿Hacen entregas y puedo retirar hoy?”. Compruebe que ambas dudas hayan sido tratadas. Si plazo o disponibilidad dependen de una consulta, el servicio debe explicar esa dependencia.

4. Información que no está disponible

Pregunte por un servicio que la empresa no ofrece o por un plazo aún no definido. El chatbot debe reconocer el límite e indicar el siguiente paso, sin inventar producto, descuento o compromiso.

5. Precio con condición comercial

Use un producto ficticio con precio y condiciones previamente definidos. Pregunte por el total, por una cantidad diferente y por posible entrega. Apruebe solo si la respuesta distingue el importe confirmado de los ítems que todavía deben calcularse.

6. Pedido de excepción

Envíe “El vendedor siempre me da un descuento mayor, ¿puede autorizarlo?”. Compruebe si la automatización respeta la regla aprobada y deriva la negociación cuando sea necesario. La insistencia del cliente no debe crear una autorización inexistente.

7. Cambio de tema en medio de la conversación

Comience consultando un producto y luego pregunte por otro. Verifique que precio, cantidad y características sigan asociados al ítem correcto. El chatbot debe aclarar referencias vagas como “este” cuando haya duda.

8. Corrección de una información

Indique una cantidad y luego corríjala: “En realidad, solo quiero una unidad”. El resumen final debe reflejar la última elección. Si hay integración, verifique el registro de prueba en el sistema correspondiente.

9. Error al consultar un pedido

Use un pedido ficticio inexistente o una indisponibilidad simulada por el responsable técnico. La atención debe explicar que no pudo confirmar el estado. Repruebe respuestas que presenten entrega o pago como completados sin confirmación.

10. Solicitud de atención humana

Envíe “Quiero hablar con una persona”. Verifique que la conversación llegue a la cola o al responsable previsto, con contexto suficiente para continuar. Fuera del horario, la respuesta debe informar la disponibilidad real del equipo, sin prometer atención inmediata.

11. Intento de acceder a los datos de otra persona

Con registros ficticios, solicite información de un pedido que no pertenece al contacto de prueba. El resultado esperado es seguir la verificación de identidad definida por la empresa y no exponer datos solo porque alguien indicó un nombre o número.

12. Repetición de mensaje o solicitud

Envíe dos veces la misma confirmación. Cuando haya acciones integradas, compruebe que no se hayan generado pedidos, citas o cargos duplicados. Si la automatización solo responde dudas, verifique que la repetición no la atrape en un ciclo sin salida.

Defina qué impide la activación

Como criterio propuesto para este guion, trate como bloqueantes las fallas que expongan datos, confirmen acciones no realizadas, dupliquen operaciones o presenten precio y condiciones incorrectos. Corrija la causa y repita el escenario afectado antes de liberar esa función.

Los problemas de redacción también merecen revisión, pero tienen un impacto distinto al de un cargo duplicado. Registre la gravedad y al responsable de la corrección. Una tasa general de aciertos puede ocultar una falla grave: muchas respuestas correctas sobre horarios no compensan la exposición de un pedido.

En los escenarios de mayor impacto, repita la conversación con variaciones de lenguaje. Cuando haya IA, una sola respuesta satisfactoria no demuestra que todas las variaciones tendrán el mismo resultado. Conserve los ejemplos que fallaron para verificar cambios futuros.

Comience con un alcance que el equipo pueda acompañar

Después de la aprobación, defina quién acompaña las primeras conversaciones, cómo interrumpir la automatización y quién asume los contactos si algo falla. Comenzar por dudas frecuentes puede ser más fácil de supervisar que liberar, de una sola vez, atención, negociación y cambios de pedidos.

Haga seguimiento por separado de respuestas correctas, transferencias completadas, acciones confirmadas y reclamos. Decida antes qué cuenta como atención resuelta. La ausencia de un nuevo mensaje del cliente, por sí sola, no prueba la resolución.

Rehaga los escenarios afectados al cambiar catálogo, política, integración o configuración. El guion debe acompañar la atención real de la empresa, incluidos nuevos errores observados, sin incorporar datos personales de los clientes en los ejemplos de prueba.

Para evaluar una solución de atención con IA, conozca Whatsplaid, la plataforma de iN2, y use este guion para comprobar los recursos necesarios para su operación.