Uno de los mayores retos a la hora de diseñar una aplicación IVR es la distribución de la información y de la funcionalidad a lo largo de todo el flujo. Lo que se viene a llamar “Arquitectura de la Información”. En relación directa con ella, estará el concepto de “encontrabilidad”, es decir, como la gente encontrará nuestras cosas.
De mi experiencia profesional puedo extraer que no todo el mundo le da importancia a esto, e incluso en ocasiones parece una cuestión ornamental. Otras veces, las compañías que se dedican a la IVR renuncian de manera clara al este tipo de análisis, dejando en manos de los clientes todo el peso de tal responsabilidad. Si quieres ver dónde estaría la arquitectura de la información en un modelo más global, te remito a una entrada anterior en el que propuse una tentativa de modelo holístico.
De hecho, la arquitectura de la información se ha configurado ya como una disciplina con entidad propia. En cualquier caso, me gustaría solamente reflexionar en alto sobre algunos conceptos en torno a los menús, pues es una cuestión importante. Ponte en guardia si quieres, puedes no estar de acuerdo.
Menú principal
Es el punto de entrada único a la aplicación y siendo rigurosos, condicionará todo lo demás. Cabe decir además que según su diseño será una fuente de pérdidas, según se puede estimar con los KPIs o índices de rendimiento (cuelgues, rellamadas, tiempos de estancia en la IVR, transferencias incorrectas, etc)
Como la presencia de los ítems en el menú principal (las cosas que se ofrecen) es limitada, tendremos que plantear una estrategia en la que la mayoría de las funcionalidades estén representadas (o implícitamente mencionadas) no sólo en las categorías de dicho menú, sino en las palabras que las describen, que es lo que se escuchará al fin de al cabo.
Puede también tomarse como criterio para estar en el menú principal el volumen de demanda que tiene cada cosa en el call center, pero debe tenerse en cuenta que esas cosas pueden a su vez englobarse en algún ítem, sin por ello perder significativamente esa demanda (depende de cómo se haga). Las categorías pueden tener un mayor o menor nivel de concreción, es decir, puede ser un concepto que extienda o defina a muchos componentes como “modificaciones”, o simplemente una categoría que casi es lo que se dice “saldo”.
Una vez hecho esto, decidiremos el orden en base a si la categoría es más o menos concreta. Los ítems como “saldo” estarán en los primeros puestos, y los ítems como “modificaciones” estarán en los últimos. La justificación es clara, los ítems que pueden de alguna manera considerarse dentro de otros (aunque levemente), tendrán que ser escuchados primero.
Quien lleve la idea concreta del saldo, será interferido con “información”, pues en rigor, es probable considerar el “saldo” como un tipo de información. Además, los que no encuentren lo que buscan en los primeros, podrán quizás ser “pescados” en los más abstractos y ambiguos.
Tengo pues ya algunos criterios encima de la tabla (a mi modo de ver):
1. En el menú tiene que estar más o menos resumida la funcionalidad del servicio entero. Esto es más bien una cuestión de “esquema en una servilleta”, (hacer un caso de uso previo quizás nos ayudaría a localizar la funcionalidad que pondremos).
2. Esas categorías pueden ser de mayor a menor concreción (o intensionalidad). Puede haber desde “hacer cambios” hasta “altas”.
3. Esas categorías tienen que traducirse a palabras, por lo tanto, habrá que hacer el esfuerzo de lexicalizar lo que previamente se ha hecho con categorías. Esto que parece trivial es si cabe lo más difícil. Si has decidido una categoría de “hacer cosas con las facturas”, ¿Cómo la llamas?. (intelijencia, dame el nombre exacto de las cosas! … Que mi palabra sea la cosa misma) ( con “j” intencionada )
4. El orden: Depende de cómo de concretas son las categorías (Recuérdese que el criterio de la demanda en el call-center se empleó ya para crear los candidatos a primer nivel)
¡Ah!, y una cosa, no es necesario que los menús ni la estructura coincidan ni con departamentos, ni con grupos de personas en el contact. Cada punto del diálogo ya se encargará de encaminar la llamada o a unos o a otros.
Menús secundarios
Los menús secundarios llevan la misma lógica que el menú principal, pero son más fáciles de rellenar, pues están mucho más acotados y suelen contener ítems de una mayor concreción. Aún así, merece la pena contemplar la posibilidad de que contenga marginalmente algún ítem que no pertenezca exclusivamente a la categoría de la que proviene (aunque tenga algo que ver).
Este tipo de licencias, da pie a que la estructura final esté más distribuida y sea menos sensible a los posibles errores en la apreciación de la categorías. Es decir, al hecho de que algunas personas elijan una categoría creyendo que puede encontrar lo que realmente está en otra. A esto lo vendré a llamar arquitectura multi-acceso.
Multi-acceso
Si es posible, merece la pena contemplar la posibilidad de una arquitectura multi-acceso. A mi modo de entender, es positivo que varios ítems pueden llevar a los mismos sitios, o visto de otro modo, se puede llegar a un mismo sitio entrando desde varios ítems de un menú. Si tomamos como buena esta forma, podemos atenuar los posibles efectos colaterales de nuestro menú principal y hacerlo mucho más absorbente. Por ejemplo, para cambiar los datos de la póliza se podría llegar desde “pólizas” o desde “realizar algún cambio”. Una arquitectura “multi-acceso” facilitará el diseño de los menús de una manera más segura.
Imaginemos las categorías de este menú principal ficticio (con él no pretendo dar con una solución):
-Dar un parte
-Reclamación
-Contratación
-Realizar Cambios
-Información
En este menú, sería coherente que dentro de cambios hubiese algún cambio referente a la póliza de cada uno (cambio de datos en la póliza, etc) e incluso a la contratación de otros extras. Además, en información podría incluirse lo referente a los partes, a las nuevas contrataciones, las modalidades, etc. De esta manera tendríamos amortiguado las posibles ambigüedades de las palabras del menú principal. Nótese también que lo más concreto queda arriba, y lo que más engloba, abajo. Este tipo de acciones están relacionadas con el siguiente apartado: los menús facetados.
Menús facetados
Además, para el diseño algunos menús, podemos echar mano de una filosofía muy interesante, el menú facetado. Se trata de que las funcionalidades, o simplemente las cosas que se ofrecen, estén definidas (y ofrecidas) en cuanto a sus funcionalidades. Esto es muy útil para las tarifas, por ejemplo. En vez de clasificar las tarifas en base a dos grupos, lo podemos hacer mediante facetas o dimensiones.
Aunque es una filosofía para la web (dado la posible presentación simultánea de varios combos, por ejemplo), podemos dar a elegir entre facetas de una manera secuencial. Por ejemplo, en vez de dividir las tarifas en Voz y Datos (cosa alejada del lenguaje coloquial), podemos hacer algo así como un asesor de tarifas que vaya proponiendo las cada una de las facetas (o criterio distinto) “para que la quieres, ¿para navegar por Internet, para hablar sólo o para las dos cosas?.
A continuación, la segunda faceta, ¿Cuánto estás dispuesto a gastar al mes, menos de 20, entre 20 y 40, más de 40?, y así … Qué ventaja tendremos, pues que al final, las tarifas que resultarán candidatas no estarán constreñidas por la elección del primer nivel de menú, “voz o datos”.
Nota final: Lo descrito aquí es sólo una descripción sucinta de una de las muchas estrategias para afrontar el diseño de menús. El funcionamiento o no de nuestra estrategia (o hipótesis) se corroborará con algún tipo de piloto monitorizado en cuanto a su rendimiento. Esto dará cuenta de la capacidad que tiene el menú de absorber diferentes perfiles de usuarios. En cualquier caso, es importante mantener plan director a la hora de diseñar. Esto nos llevará a tomar decisiones en base a criterios que regirán nuestra praxis.
