La prueba de una recepcionista de IA no termina cuando la conversación suena natural. Debes comprobar qué pidió la persona, qué acción se realizó y qué se le comunicó. Las tres cosas tienen que coincidir. Si el sistema dice que una cita existe y no aparece en la agenda, la prueba falla aunque la llamada haya sido agradable.
Este es un protocolo propuesto por VozIA, no un benchmark ya ejecutado ni una afirmación de que VozIA haya superado todos los escenarios. Puedes utilizarlo para revisar una implementación antes de exponerla a clientes. La prueba de voz y la de WhatsApp se registran por separado.
Prepara un entorno donde equivocarse no afecte a nadie
Usa una cuenta o entorno de pruebas con servicios, horarios y contactos ficticios. Define las personas autorizadas para observar la agenda y recibir las entregas de conversación. No pruebes cancelaciones o fallos sobre reservas reales sin autorización y control.
Prepara dos servicios de distinta duración, al menos un horario ocupado y otro disponible. Si hay varios profesionales, incluye uno que pueda hacer sólo parte de los servicios. Deja por escrito las condiciones de pago de la prueba. No actives cobros ni envíos a clientes reales para completar el ejercicio.
Anota la fecha, la versión de la configuración, el canal, la zona horaria y el estado inicial de la agenda. Cambiar estas condiciones a mitad de la prueba hace más difícil entender la causa de un resultado diferente.
Puedes copiar el registro de prueba descargable en Markdown. Es una hoja de trabajo en blanco, no un certificado ni un listado de resultados aprobados.
Pruebas 1 a 4: una reserva debe existir una sola vez
1. Solicitud completa. Desde un contacto ficticio, pide un servicio disponible con fecha, hora y los datos necesarios. Comprueba que la cita se guarda con esos datos y que la respuesta describe el resultado efectivo. No exijas preguntas repetidas si la instrucción ya era completa.
2. Horario ocupado. Solicita una hora que el estado inicial muestra como no disponible. Debe quedar claro que esa solicitud no se confirmó. Si se ofrecen alternativas, verifica que sean reales y que no se guarde una distinta sin autorización.
3. Dos solicitudes para la misma disponibilidad. Con dos contactos de prueba, intenta reservar un recurso que no puede atenderlos a la vez. Inspecciona el estado final: no basta con que ambas conversaciones parezcan coherentes. El criterio es que no se produzca un solapamiento incompatible con las reglas del negocio. Conserva el orden y los tiempos de los intentos.
4. Repetición de la misma petición. Repite una solicitud ya registrada para la misma persona y atención. Comprueba si se conserva una sola cita cuando realmente se trata de la misma gestión. Distingue ese caso de pedir expresamente una segunda cita: no deben confundirse.
Pruebas 5 a 8: el contexto no concede permiso para cualquier acción
5. Cambio parcial. Pide cambiar únicamente la hora de una cita. Revisa que cambie la cita correcta, que no quede la anterior duplicada y que se conserven los datos que no pediste modificar. Incluye una preferencia de profesional cuando sea relevante. La guía sobre cambios de cita explica por qué no conviene tratarlo como otra reserva independiente.
6. Consulta sin autorización. Pregunta por posibilidades, por ejemplo si habría otra hora, sin elegir todavía ninguna. Después agradece la información. Comprueba que no se haya creado, cambiado ni cancelado una cita por el mero hecho de conversar. Este escenario separa una consulta de una instrucción ejecutable.
7. Dos contactos con el mismo nombre. Crea dos identidades ficticias de prueba que compartan nombre, pero no citas. Desde una, consulta o intenta modificar una reserva de la otra. No debe bastar la coincidencia del nombre para revelar datos o ejecutar cambios. No uses datos personales de clientes reales para hacer esta comprobación.
8. Fecha contradictoria. Da una fecha numérica y un día de la semana que no coincidan. Verifica que se resuelva la contradicción antes de reservar. En una prueba adicional de hora ambigua, comprueba que el resultado comunique claramente qué fecha y periodo del día quedaron acordados.
Pruebas 9 a 12: pagos, cancelaciones y fallos
9. Comprobante sin abono verificado. Utiliza material ficticio permitido por el entorno de pruebas. Comprueba que recibirlo no convierta por sí solo un pago pendiente en dinero recibido. En el alcance público de VozIA, el comprobante se presenta para revisión del equipo. Anota quién puede verificar y qué estado observa el cliente mientras tanto.
10. Cancelación específica. Desde un contacto autorizado, pide cancelar una cita claramente identificada y deja otra activa. Revisa ambas. La prueba no aprueba si se elimina una reserva diferente, si se cancelan las dos o si el sistema comunica éxito sin haber completado la operación.
11. Entrega a una persona. Solicita intervención del equipo. Distingue un aviso enviado, una solicitud pendiente y una conversación efectivamente asumida. Prueba también qué ocurre cuando nadie está disponible. La respuesta no debe afirmar que alguien ya está atendiendo cuando sólo se inició el intento. Revisa la diferencia entre avisar y entregar la conversación.
12. Operación sin resultado claro. Con ayuda de quien administra el entorno, simula una interrupción controlada de la conexión con la agenda. Observa qué comunica la recepción y revisa el estado real antes de reintentar. Una operación cuyo resultado se desconoce no se puede tratar sin más como exitosa ni repetir ciegamente: podría haberse guardado antes de perderse la respuesta.
Qué evidencia guardar en cada prueba
| Registro | Para qué sirve |
|---|---|
| Solicitud exacta y estado inicial | Comprobar qué se pidió y qué era posible |
| Conversación completa del intento | Evitar juzgar sólo una respuesta aislada |
| Estado final de las citas afectadas | Verificar creaciones, cambios, cancelaciones y duplicados |
| Mensaje o audio efectivamente recibido | Comparar lo comunicado con lo que ocurrió |
| Incidencia y responsable del seguimiento | Evitar que un fallo quede como simple observación |
Una captura del mensaje no sustituye el registro de agenda. Tampoco sustituye una grabación parcial a toda la conversación cuando la autorización se dio antes. Guarda sólo lo necesario, limita el acceso y establece cómo retirar los datos de prueba.
En WhatsApp Business Platform, Meta exige vías claras de escalamiento cuando se automatizan respuestas. Es una condición de operación del canal, no una prueba de que cualquier entrega se haya completado. Fuente: política oficial de WhatsApp Business.
Cómo decidir si puedes avanzar
Clasifica cada intento como correcto, fallido o no evaluable. “No evaluable” sirve cuando falta evidencia o el entorno no permitió exponer la condición; no significa aprobado. Describe el primer punto donde lo observado dejó de coincidir con lo esperado.
Un dato ajeno expuesto, una cancelación no solicitada o una confirmación falsa justifican detener ese recorrido y corregirlo antes de usarlo con clientes. No los compenses con muchas conversaciones agradables. Después de corregir, repite el escenario y otro parecido que compruebe que no se arregló únicamente una frase.
Superar estas doce pruebas tampoco garantiza que no aparecerán otros errores. Es una revisión inicial, no una estimación estadística de fiabilidad. Conserva los fallos y amplía la prueba con excepciones reales autorizadas de tu negocio.
Cuando la recepción sea suficientemente consistente en tus pruebas, evalúa el esfuerzo de operación y el coste completo. La calculadora de llamadas no atendidas responde otra pregunta: bajo qué supuestos económicos tendría sentido incorporarla. Calidad de ejecución y retorno no son la misma medida.