Aventuras y desventuras tras un año diseñando asistentes de voz.

Necesitas hablar con tu seguro o tu compañía telefónica, llamas por teléfono y te atiende una máquina. Seguro que a ti también te ha pasado. La experiencia puede ser maravillosa si esa máquina ha contestado lo que necesitabas en ese mismo momento, o si tu problema queda resuelto a las 2 de la mañana. Por el contrario, puede ser un infierno, ¿y si no te entiende?, ¿y si no responde a tu pregunta?... Ser atendido por una inteligencia artificial, ya sea por voz o chat es algo cada vez más común, pero, ¿te has parado a pensar alguna vez qué hay detrás de todo eso?, ¿quién diseña y desarrolla esas máquinas?

Entiendo perfectamente estas sensaciones y la frustración que provocan ciertas situaciones. Por suerte, existen personas cuyo rol de diseñador conversacional, entre los que me incluyo, nos permite ponernos en la piel del cliente y diseñar estas conversaciones para que sean más amigables, para que entiendan lo que pides, para que no te diga cosas incoherentes y evitar tenerte un largo rato al teléfono o esa larga espera en una fila virtual. Por supuesto, lo hacemos apoyados por todo un equipo de personas encargadas del desarrollo, infraestructura, gestión, y un largo etcétera.

Tras tres grandes proyectos para importantes compañías del sector seguros y telecomunicaciones, además de la implementación de un juego, y más de año y medio dedicado a diseñar este tipo de experiencias, ya sea a través del teléfono, de altavoces inteligentes con asistentes virtuales como Alexa o Google Assistant, chatbots, o asistentes de voz integrados en aplicaciones móviles, os voy a resumir algunos de los problemas comunes que nos hemos encontrado, así como lecciones aprendidas. ¡Vamos allá!

Maneja las expectativas

Algunos problemas suelen surgir en las primeras fases del proyecto o incluso en la preventa, ya que muchos clientes saben que esto son tecnologías a la vanguardia, se quieren subir al carro de la innovación y no quedarse atrás, pero por esa misma razón, al ser algo tan novedoso, suelen desconocer cómo funcionan estas tecnologías o cuáles son las limitaciones que tienen.

Nunca está de más hacer una demostración de qué se puede hacer con estas tecnologías, pero también hay que dejar claros algunos puntos y explicar las limitaciones, como, por ejemplo, que muchas de estas tecnologías no “aprenden solas”, como muchos clientes suelen esperar.

Por ejemplo, ¿Dialogflow como motor de este tipo de proyectos tiene Machine Learning y aprende solo? La respuesta es sí, pero para nosotros no es más que una “caja negra” en la parte de Google que ayuda con el reconocimiento de voz, entendimiento y todo el manejo de la respuesta de lo que solicita el usuario. Y, por suerte, nos podemos aprovechar de ello. Pero cuidado, porque el cliente suele interpretar que el proyecto va a aprender solo a medida que entren llamadas o peticiones, lo cual es incorrecto. El desarrollo que se haga no aprende solo.

Deja claro que este tipo de proyectos no sustituyen al 100% a las personas. Has leído bien, no es posible eliminar el call center de un plumazo, la realidad es que la tecnología aún está lejos de esto. Pero sí podemos reducir la carga de trabajo del mismo, enrutar llamadas o actuar cuando hay mucha lista de espera, atender las peticiones 24x7... o incluso hacer algunos trámites o acciones de forma automática.

Otra cosa que el cliente debe entender es que la web o contenidos existentes en texto deben ser adaptados para voz, al igual que hay que encontrar las palabras correctas para transmitir la esencia de la compañía. ¿Te imaginas que tuviésemos que locutar 20 platos con sus ingredientes y sus precios tal y como aparece en una web de recetas?

Los tiempos del proyecto

Hay que entender que un proyecto de innovación tiene una alta incertidumbre y es posible encontrarse en situaciones de mucha complejidad, sobre todo porque muchas veces nos solicitan integrar Dialogflow (o similar) con los sistemas y tecnologías ya existentes en el cliente.

Para este tipo de proyectos podemos cometer el error de querer llegar a la perfección y juguemos cerca de los límites de la tecnología. Se debe asumir que estamos en una fase relativamente temprana de las tecnologías implicadas como para llegar a sustituir la capacidad de entendimiento y actuación de una persona. Una conversación es un proceso realmente complejo.

Adicionalmente, aquí no son distintos los problemas a la hora de estimar esfuerzo: cuántos servicios se van a integrar, qué número de casos de uso vamos a hacer, qué complejidad van a tener, número de interacciones que se van a dar...

Las pruebas

Es probable que en las pruebas de aceptación se pida ayuda para realizar un buen plan de pruebas, ya que como cliente que se enfrenta a una nueva tecnología es posible que no sepa qué hay que probar o cómo ha de probar. Lo ideal es dar algunas directrices sencillas al cliente o a los usuarios que vayan a probar para que comprendan el flujo a seguir, pero no proponer en ningún caso qué tienen que probar literalmente. En estos proyectos es muy importante la forma de hablar y expresarse que tiene cada usuario, por lo que cuanto más variedad haya, mejor depurado estará.

Muchos clientes que se suman a este tipo de proyectos vienen de tener una IVR en su call center y utilizan gramáticas ABNF. Aprovéchalo para dejar claras las similitudes y las diferencias entre lo que ya conocen y este nuevo mundo y puedan prepararse mejor de cara a las pruebas.

Mantenimiento vs Evolutivo

En cualquier proyecto digital, cuando se termina la puesta en producción y pasado un tiempo de depuración, es habitual que el cliente asuma la responsabilidad del producto y el mantenimiento del mismo.

Sin embargo, es muy probable que el cliente no tenga el conocimiento en casa como para mantener un producto como este. Ten presente que siempre será necesario dar formaciones y hacer un traspaso algo más detallado que con proyectos tradicionales.

Tras la puesta en producción hay una delgada línea en la que se confunden y se mezcla aquello que es mantenimiento con lo que es evolutivo. Por ejemplo, si un entrenamiento está mal y debería haber hecho “X” acción pero la inteligencia ha interpretado o entendido que había que hacer “Y”, ¿esto es mantenimiento o es evolutivo?, ¿se arregla porque no funciona o se mejora porque se prefiere otra cosa?

“Entonces, ¿necesito un diseñador conversacional?”

Una pregunta común es: “¿para qué quiero yo un diseñador?”. O, peor aún, “¿para qué quiero un diseñador pudiendo invertir ese coste en más desarrolladores que terminen antes?”. Aunque esto ya está más que explicado con la Ley de Brooks que se suele resumir en la afirmación de que '9 mujeres no hacen un bebé en 1 mes', déjame explicar un poco más qué función tiene este rol tan novedoso.

La figura del diseñador conversacional no deja de ser un diseñador de experiencia de usuario (Diseñador UX) especializado que nos va a ayudar en la elección y definición de los casos de uso. Hay que tener en cuenta que este tipo de interfaces son muy diferentes a lo que estamos acostumbrados, sobre todo en casos donde prima el voice first y el usuario no tiene una interfaz gráfica en la que apoyarse, pero aunque cambia el medio sigue existiendo una interacción persona-máquina que idealmente ha de ser diseñada por un especialista. Aquí puedes ver en más detalle el camino que seguimos en Paradigma para ello.

El especialista definirá unos flujos de conversación y los diálogos (copywriting) sobre los que irá iterando y depurando con pruebas de usuario, con los stakeholders del proyecto, etc. Esto ayudará a empezar a visualizar la solución en una fase temprana e ir descubriendo posibles necesidades, problemas e imprevistos que puedan surgir posteriormente y poder proponer soluciones.

Va a ayudar a los desarrolladores a definir (e incluso, ejecutar) cómo se va a entrenar. Tras validar y probar el desarrollo, estará inmerso en la fase de pruebas y podrá proponer cambios y mejoras en los entrenamientos. Por supuesto, también puede estar inmerso junto con el cliente en las escuchas y depuración de estos flujos en fases posteriores como en la puesta en producción.

Al final, como en otros proyectos, se puede ir trabajando en modo dual track donde se paraleliza el desarrollo y nuevos descubrimientos. Una diferencia es que aquí el diseñador tendrá un rol en la fase de pruebas como Tester, aunque ayudará mucho más en las tareas relacionadas con los diálogos, copywriting y la experiencia de usuario en general.

Conclusiones

• Anticípate y maneja las expectativas. Cuenta lo que es y lo que no.
• Ayuda y colabora con tu cliente. Forma y traspasa los conocimientos.
• Haz que durante las pruebas cada tester pruebe de forma natural y no leyendo un texto literal y cerrado.
• Al finalizar el proyecto, la continuidad debe diferenciarse bien entre mantenimiento puro y mantenimiento-evolutivo.
• Ten un diseñador conversacional que te asegure el retorno de la inversión al hacer que el equipo trabaje como una máquina engrasada y que esta no tenga que pararse para enfrentar problemas que no se han tenido en cuenta en fases previas.

Si tienes ganas de más, te animo a ver cómo gracias a la tecnología de Goodly hemos hecho realidad el proyecto de Santalucía centrado en la voz y, además, en nuestro canal podcast, ‘Apasionados por la tecnología’, te damos las claves para diseñar asistentes de voz.