Mundo-ContactLas diez cosas que NO debe hacer al implantar una solución de reconocimiento de voz
Annie Clark Ferreira*
1. Empezar a elaborar las especificaciones de diálogo antes de dar el visto bueno a los requerimientos
Para poder garantizar que su proyecto se ejecute con éxito y conforme a programa, es necesario que se siente a dialogar con su cliente para aclarar perfectamente todas las cosas que necesita que haga la aplicación antes de empezar a elaborar las especificaciones de los diálogos. En esta etapa es muy útil analizar los flujos aproximados de las llamadas y unos cuantos ejemplos de diálogo. A partir de aquí, las personas y los mensajes pueden cambiar, al igual que el orden de las tareas, pero las tareas que necesita realizar el llamante deben quedar concretadas en esta etapa del proyecto.
2. Omitir los ejemplos de diálogo
Si no los presenta en un principio, lo más probable es que su cliente se confunda al revisar sus especificaciones, y podría empezar a rebatirle palabras y frases al no entender cómo suenan en contexto.
Es fundamental tener muchos ejemplos que conduzcan al llamante a través de diversas interaciones de errores, confirmaciones y ejecución completa de tareas. Este deberá ser uno de sus primeros pasos, tan pronto como comience a elaborar las especificaciones. También podría resultar útil grabar mensajes temporales de voz de modo que el cliente pueda “oír” el diseño.
3. No escalar los mensajes de error
El 80% de los llamantes abandonarán el sistema después de dos errores consecutivos, y usted definitivamente tendrá algunos errores, de modo que resulta crucial recuperarse de los errores con la debida prestancia. A menudo una solicitud de confirmación muy sucinta después de un error, como por ejemplo “Disculpe, ¿qué dijo?”, será suficiente tratándose del primer error. Sin embargo, si el llamante comete un segundo error, necesitará ayuda para continuar y se le deberá decir de manera más explícita qué debe hacer. En algunos casos en que las tareas son especialmente difíciles, el llamante podría necesitar instrucciones más detalladas desde el primer error.
4. Desarrollar otro idioma simultáneamente
Si está desarrollando una aplicación idéntica en un segundo idioma, no tiene sentido tratar de desarrollar en esa lengua sin haber terminado por completo la primera versión. Idealmente, habría que concluir la prueba piloto en el primer idioma, que es en donde muchos de sus supuestos de diseño serán puestos a prueba por usuarios en vivo por primera vez. Esperar a superar este paso antes de empezar a desarrollar el segundo idioma le permitirá acortar significativamente el tiempo de desarrollo de los mensajes y los detalles gramaticales, y también el tiempo de pruebas de uso e implementación. Aunque no lo parezca, de hecho es más rápido esperar a que esté terminado el primer idioma que empezar a trabajar en el segundo antes de tiempo.
5. No usar referencias
Referencias (landmarks) son palabras y frases que le indican al llamante dónde se encuentra, y son sumamente útiles para guiar a la persona a través de aplicaciones complejas en las que se utilizan varios niveles de tareas. He aquí algunos ejemplos: “Siguiente mensaje, ¿desea escucharlo?” o “¿Y cuál es el apellido?” o “Intentémoslo por última vez”.
6. No usar marcadores de discurso
Los marcadores de discurso son palabras y frases que el ser humano utiliza en el habla natural. Estos elementos son críticos para ayudar al llamante a navegar por la aplicación, ya que pueden confirmarle que ha concluido una tarea previa. Por ejemplo, “Muy bien, lo tengo. Ahora continuemos con su número de cuenta” o “¡Perdón!, ¿cuál es el apellido correcto?”
7. Ordenar sus mensajes demasiado pronto
Evite mandar grabar sus mensajes demasiado pronto, pues tendrá que hacerles muchas modificaciones. Asegúrese de que las especificaciones de diálogo hayan sido aprobadas y que haya pasado al menos por una interación de pruebas de uso antes de mandar grabar los mensajes. Sin embargo, no descarte la posibilidad de tener que hacer un par de pedidos más antes de la implementación final. Y probablemente una o dos después de la implementación.
8. Grabar los mensajes en diferentes momentos
Trate de grabar lo más posible de una sola vez. Sin embargo, en caso de que llegara a necesitar hacer más grabaciones, hay que asegurarse de que estén disponibles las mismas voces, usando el mismo estudio y el mismo micrófono, y que se graben a la misma hora del día. De esta manera sus mensajes tendrán una mayor consistencia tanto en sonido como en calidad.
9. Omitir la “prueba del Mago de Oz”
La prueba del “Mago de Oz” es la primera fase de pruebas de uso que debe realizar. La idea es duplicar la aplicación a un subconjunto de llamantes de prueba. La aplicación puede no estar desarrollada, las bases de datos pueden estar incompletas y los mensajes pueden no haber sido grabados aún, pero usted puede usar mensajes temporales y datos ficticios (“dummy”) para permitir a los llamantes recorrer diferentes situaciones de prueba, con una persona que esté “tras bambalinas” seleccionando qué mensajes presentar en respuesta a lo que diga el llamante. Esta ronda de pruebas le permitirá identificar muchas fallas y detectar qué partes del diálogo resultan confusas para el llamante. Así, usted podrá rediseñar estas áreas sin tener que perder valioso tiempo de desarrollo.
10. No usar diseñadores experimentados y certificados
Sus diseñadores y desarrolladores de diálogos deben contar con experiencia y estar certificados. Usted debe poder confiar en que saben lo que están haciendo y que le van a entregar un producto de éxito. Ellos, por su parte, necesitan entender las sutilezas y matices del reconocimiento de voz y entender perfectamente el impacto de cambios en la base de datos, errores en los mensajes y otros problemas que se presentarán durante la vida del proyecto. Los desarrolladores y diseñadores de sistemas de tonos (“touchtone”) no necesariamente tienen este nivel de experiencia y conocimiento. Exija siempre la más alta calidad.
*Annie Clark Ferreira, ContactCenterWorld.com
