Introducción: por qué un protocolo UAT dedicado a los avatars IA en tienda
Un piloto de avatar IA en un kiosco o pantalla debe demostrar en condiciones reales que la experiencia cumple los objetivos de negocio: bienvenida, información, orientación y guía. Un protocolo estructurado de pruebas de usuario y aceptación (UAT) evita las ilusiones generadas por pruebas técnicas aisladas y asegura que el avatar funciona con interacciones reales por voz y táctil, en varias lenguas y con la base documental de negocio.
Este documento propone un protocolo listo para usar: definición de objetivos, escenarios de prueba tipo, método de reclutamiento multilingüe, guiones observables, indicadores cualitativos y cuantitativos a monitorizar, listas de verificación técnicas y criterios operativos go/no‑go. Los elementos específicos de SANIA se indican claramente cuando deben verificarse durante el piloto.
Definir los objetivos de negocio y el alcance del piloto
Antes de cualquier prueba, formalice los objetivos concretos del piloto. Deben vincularse a usos precisos: obtención de información de producto, orientación en tienda, respuesta a preguntas frecuentes, acceso multilingüe o guía hacia un servicio. Cada objetivo se traduce en casos de uso priorizados que servirán de base para los escenarios de prueba.
Precise el alcance técnico y operativo: modos de interacción habilitados (voz, táctil o ambos), idiomas a cubrir, integraciones potencialmente disponibles (inventario, horarios, señalización dinámica) y restricciones de entorno (ruido, iluminación, circulación). Distinción importante: lo que recae en una capacidad nativa del avatar y lo que exigirá una integración específica.
Escenarios de usuario tipo: voz, táctil y multilingüe
Construya un conjunto de escenarios que cubran los recorridos más frecuentes y las situaciones de fallo. Cada escenario debe incluir el objetivo del usuario, el contexto, los prerequisitos (idioma, disponibilidad de una integración), el guion del usuario y los criterios de resultado. Varíe los escenarios según: interacciones exclusivamente vocales, interacción únicamente táctil, trayectos mixtos táctil luego voz, y cambio de idioma durante la sesión.
Ejemplos de casos de negocio a incluir: solicitud de información de producto, búsqueda de una sección o de un producto en stock, petición de horarios y servicios, pregunta reglamentaria o de seguridad simple, y solicitud que requiera derivación a personal humano. Para las pruebas multilingües, incluya hablantes nativos y no nativos para evaluar la robustez del ASR y la formulación de las respuestas.
Guiones de prueba observables y cuadrícula de observación
Cada sesión de prueba debe realizarse con un guion preciso y una cuadrícula de observación completada en tiempo real por el evaluador. La cuadrícula documenta los elementos objetivos siguientes: iniciación (tiempo para comenzar la interacción), comprensión ASR (¿el avatar transcribió correctamente la solicitud?), pertinencia de la respuesta, claridad vocal y volumen del TTS, ergonomía táctil (menús, etiquetas), latencia percibida, necesidad de escalado y satisfacción declarada del usuario.
Complete estas observaciones con notas cualitativas sobre entonación, confusiones recurrentes y expresiones de usuario no previstas. El objetivo es producir trazas explotables para corregir la base documental, ajustar prompts y microcopy, o mejorar parámetros de ASR/TTS.
Campos de la cuadrícula de observación: ID prueba, escenario, idioma, modo (voz/táctil), transcripción ASR observada, respuesta proporcionada, duración de la interacción, intervención humana necesaria, estado éxito/fracaso, comentarios.
Reclutamiento de participantes y tamaño de muestra
El reclutamiento debe buscar la representatividad de los visitantes reales: perfiles demográficos, niveles de familiaridad con la herramienta, idiomas hablados y comportamientos de uso (preferencia por táctil o por voz). Priorice la diversidad antes que el volumen bruto para detectar casos problemáticos y sesgos lingüísticos o culturales.
En lugar de imponer un número fijo, organice las pruebas por iteraciones hasta el punto de saturación cualitativa: cuando emergen los mismos problemas recurrentes y aparecen pocas observaciones nuevas, la fase inicial de pruebas puede considerarse suficiente. Este principio evita un umbral arbitrario y se adapta a la afluencia y a la complejidad del alcance probado.
Ejecución de las pruebas en tienda: logística y buenas prácticas
Planifique sesiones en franjas representativas de afluencia. Prepare el entorno: señalización clara indicando que se trata de una prueba, instrucciones de confidencialidad y autorizaciones si se realizan grabaciones. Recuerde que la recopilación de datos personales debe tratarse conforme a la normativa aplicable y que la configuración de SANIA dependerá de las opciones de retención elegidas por la organización.
Durante la sesión, limite las intervenciones del evaluador para no sesgar el comportamiento. Registre muestras anonimizadas de las interacciones si la configuración del piloto lo permite y se obtiene el consentimiento. Utilice la cuadrícula de observación para recoger medidas objetivas y comentarios cualitativos inmediatos.
KPIs y criterios go/no‑go: qué medir y cómo decidir
Seleccione un conjunto limitado de indicadores cuantitativos y cualitativos alineados con los objetivos de negocio. Dimensiones útiles: tasa de resolución percibida por los evaluadores, tasa de escalado a intervención humana identificada por observación, calidad de comprensión ASR en los idiomas probados, latencia media percibida y satisfacción del usuario declarada al caliente. Precise los métodos de recolección: cuadrícula de observación, encuesta posterior a la interacción o instrumentación externa según integraciones disponibles.
Para los criterios go/no‑go, prefiera criterios operativos legibles: si las principales solicitudes de negocio no se resuelven de forma fiable en los idiomas prioritarios, si el ASR falla sistemáticamente en contexto real, o si la interfaz táctil impide acceder a funciones esenciales, el piloto no puede validarse para pasar a la fase siguiente. Evite fijar umbrales numéricos universales sin contextualizarlos: son criterios que deben adaptarse según la ambición del proyecto y la criticidad del negocio.
Checklist técnica a validar durante el piloto
Durante el UAT, valide los elementos técnicos que impactan la experiencia. Controle especialmente la robustez del ASR en los idiomas activados, la calidad e inteligibilidad del TTS, la pertinencia de las respuestas procedentes de la base documental RAG, los comportamientos de fallback cuando la fuente documental no es suficiente, y la latencia percibida en llamadas LLM o integraciones en tiempo real.
Para SANIA, verifique los siguientes puntos en la configuración del piloto: capacidad para cambiar entre voz y texto según la configuración, mantenimiento del contexto conversacional durante una sesión, disponibilidad multilingüe configurada y adecuación de la base de conocimientos proporcionada por la organización. Las integraciones precisas con sistemas terceros deben probarse como desarrollos específicos.
Checklist técnica sintética: ASR (pruebas en condiciones reales por idioma), TTS (inteligibilidad, volumen), RAG (pertinencia y fuentes citadas), gestión de errores y fallback, latencia de llamadas LLM, integraciones críticas probadas, disponibilidad simulada 24/7.
Proceso de escalado y gestión de fallos en producción
Defina de antemano las situaciones en las que el avatar debe invitar al usuario a contactar con personal. El piloto debe documentar estos casos para evitar rupturas de experiencia: preguntas reglamentarias sensibles, problemas de seguridad, solicitudes que requieren acceso a sistemas protegidos, o incomprensión persistente tras varios intentos.
No presuma un mecanismo automático de transferencia: prepare mensajes tipo, la forma en que el avatar informa al usuario y la lógica de recomendación hacia un interlocutor humano. El playbook 'Pasar a un agente humano desde un avatar IA' puede servir de referencia para formalizar estas reglas operativas.
Plantillas exportables: escenarios, cuadrícula de observación y informe de aceptación
Para facilitar la ejecución, aquí tiene modelos que puede reproducir en una hoja de cálculo o en una herramienta de recolección:
Plantilla de escenario: ID | Nombre del escenario | Objetivo | Idioma | Modo (voz/táctil) | Precondición | Guion de usuario | Acciones esperadas del avatar | Criterio éxito/fracaso | Observaciones.
Plantilla cuadrícula de observación: ID prueba | Escenario | Participante (perfil) | Idioma | Inicio interacción | Transcripción ASR | Respuesta proporcionada | Duración | Intervención humana | Estado | Comentarios detallados.
Plantilla informe de aceptación: Contexto del piloto | Alcance probado | Síntesis de resultados cualitativos | Síntesis de resultados técnicos | Puntos bloqueantes | Mejoras requeridas | Lista de acciones prioritarias | Recomendación operativa (go / go con reservas / no‑go).
Puntos específicos SANIA a verificar en el piloto
Entre las capacidades confirmadas de SANIA, verifique durante el piloto: la comunicación multilingüe configurada para los idiomas pertinentes, la interacción vocal y táctil según la configuración elegida, la capacidad de mantener el contexto durante una sesión y la explotación de la base de conocimientos de negocio provista por su organización. Estos elementos son componentes nativos o configurables cuya calidad debe validarse en condiciones reales.
Si su proyecto incluye integraciones específicas (inventario, horarios, POS), trátelas como desarrollos distintos y pruébelas como tales. Del mismo modo, la gestión de voces personalizadas o clonación vocal solo es posible si se proporcionan los derechos y la configuración y deben validarse durante el piloto.
FAQ rápida
¿Cómo medir la satisfacción sin instrumentación nativa? Una organización puede recopilar la satisfacción en caliente mediante una breve encuesta separada tras la interacción, o mediante la cuadrícula de observación completada por un evaluador. Estos métodos deben decidirse antes del piloto.
¿Hay que traducir toda la base documental para cada idioma? No. SANIA puede comunicarse en más de 100 idiomas cuando está configurada. La prioridad debe darse a la información de negocio clave y a su calidad en los idiomas realmente relevantes para su público. La estrategia de localización dependerá de sus objetivos y recursos.