Prueba un asistente antes del lanzamiento con casos reales
Prepara preguntas comunes, ambiguas y de derivación, conserva resultados esperados y decide con el equipo si el asistente está listo para clientes.
Crea pruebas a partir de preguntas reales
Las pruebas previas al lanzamiento son más útiles cuando reflejan el trabajo que realmente llega al equipo. Empieza con un conjunto fijo de temas habituales y añade casos que revelen cuándo debe parar el asistente. Una muestra pequeña y deliberada se revisa mejor que una colección grande sin resultados esperados.
Incluye cuatro tipos de preguntas. Una habitual comprueba si la fuente aprobada permite responder normalmente. Una ambigua verifica si pide el detalle que falta en vez de adivinar. Una sin fuente comprueba si reconoce que el material no permite establecer la respuesta. Una de derivación verifica si reconoce decisiones humanas. Escribe el comportamiento esperado junto a cada formulación exacta antes de probar.
Una empresa de servicios podría probar un requisito de cita publicado, una pregunta incompleta sobre qué sede abre, un detalle de política ausente y una solicitud de excepción. Lo correcto no siempre es responder directamente. Aclarar o derivar puede ser el mejor resultado cuando faltan pruebas o autoridad.
Prepara fuentes y resultados esperados
Antes de abrir la página de pruebas, confirma que la fuente sea autorizada y actual. Alinea el alcance con el material facilitado. Si solo indica que se necesita cita, no esperes un horario preciso que no aparece. Registra la fuente y el hecho concreto que respalda cada respuesta esperada.
El editor de Resonoon incluye una página de pruebas y admite conocimiento en PDF y Markdown. La página sirve para comprobar respuestas; el equipo debe mantener su conjunto repetible y registro de puntuaciones. Guarda criterios y resultados en documentación compartida para que todos apliquen las mismas reglas en cada ejecución.
Acuerda una rúbrica breve. Puedes clasificar cada respuesta como correcta y completa, útil pero pendiente de una persona, incorrecta o sin respaldo, o poco clara. Añade una nota sobre pruebas y siguiente acción. Evita «buena» sin criterio. Los revisores deben explicar por qué aprobó y qué fuente o instrucción cambiarían si falla.
Ejecuta las pruebas de forma coherente
Usa la misma redacción al comparar revisiones. Registra en un documento la versión o cambios de configuración evaluados, pregunta, respuesta, resultado esperado y valoración. Mantén un formato constante para que otra persona repita la comparación e identifique la configuración probada. Excluye datos personales o sensibles salvo que sean necesarios y estén aprobados para esa prueba.
Prueba las paráfrasis por separado. El cliente puede describir productos con sus palabras u omitir una condición. Prueba también una petición segura de sí misma que solicite algo sin respaldo. No induzcas la respuesta esperada ni arregles la pregunta tras un resultado decepcionante: debilitaría la prueba.
Ante un fallo, clasifica la causa antes de editar. Un detalle de política erróneo puede señalar fuentes obsoletas o contradictorias. Un límite ausente puede exigir instrucciones más claras. Una derivación sin responsable señala una carencia operativa. Cambia una causa y repite el texto idéntico y casos relacionados para atribuir mejoras y detectar regresiones cercanas.
Decide el lanzamiento en equipo
Define el umbral antes de ver los resultados. Por ejemplo, exige que toda pregunta crítica de política sea correcta o se derive de forma segura y registra aparte problemas menores de claridad. El umbral depende del negocio y deben aprobarlo quienes responden del soporte y las políticas. Una media favorable no debe ocultar un error crítico.
Confirma relevo humano, canal y responsable de fuentes antes del lanzamiento. Si utilizas el widget web, revisa la página del cliente tras configurar y asegúrate de que el equipo sabe atender derivaciones. Una prueba exitosa no demuestra cobertura de personal ni plazos de respuesta.
Conserva las preguntas y repítelas tras cambios importantes de instrucciones o fuentes. El widget de chatbot con IA aporta contexto de la experiencia web. Las pruebas no demuestran que toda conversación futura saldrá bien, pero revelan debilidades conocidas antes de que lleguen al cliente y facilitan evaluar cambios.
Nombra un revisor que apruebe los casos críticos. Si no hay acuerdo sobre el resultado esperado, resuelve la cuestión de política antes de dar la prueba por superada.