Muy pocas veces la causa de rechazo de los usuarios finales hacia los sistemas IVR Asterisk son de orden tecnológico:

Un IVR basado en Asterisk permite la interacción con bases de datos internas del sistema (MySQL o PostgreSQL), externas como Oracle, DB2, Sybase, Informix, MS SQL Server o Web Services bajo SOAP. Acepta conexiones tanto de líneas analógicas (FXO) y digitales (ISDN Pri, E1 R2/MFC) o troncales VOIP. La plataforma de hardware y software libre, dimensionada específicamente para cubrir con holgura la necesidad del cliente, es robusta y adaptable.

Ahora bien, ¿Toda la aburrida jerga técnica anterior garantiza el éxito del proyecto?

La respuesta es no. Hace más de 10 años que existe la tecnología IVR y ha sido ejecutada con más o menos éxito sobre diversas plataformas, especialmente Windows. La elección de Asterisk + Linux es simplemente comercial. Hacer lo mismo a menor precio.

El 95% del éxito del diseño de los sistemas IVR Asterisk se basa en trabajar junto al cliente desarrollando casos de uso consistentes y probar (y rehacer) prototipos con usuarios finales "reales" (a los cuales, incluídos nosotros mismos, les fastidia "hablar" con una máquina). Si la transacción promedio es corta y amigable, la ventaja frente al acceso Web es que no todos tienen Internet en todo momento, aunque sí un teléfono.

El 5% restante es sólo programación

Principales errores de "ergonomía":

• Menúes demasiado largos
• Los usuarios se pierden o no encuentran lo que necesitan
• No comprenden cómo usar el sistema
• Lógica confusa y "callejones sin salida"
• Suponer que el usuario conoce la "jerga" del negocio

Principales errores de diseño:

• Ineficiente recuperación ante fallos
• Falta de canales de atención suficientes
• Carencia de una salida hacia un operador humano

Veamos algunas posibles soluciones

Dimensionamiento adecuado de líneas entrantes

En el año 1909, A.K. Erlang escribió un trabajo titulado "La teoría de las probabilidades y las conversaciones telefónicas". A partir de entonces se desarrolló una rama de la Ingeniería que estudia los problemas relacionados con todo tipo de tráfico y toma en cuenta 3 factores:

• Tráfico ofrecido (cuánto tráfico de llamadas quiere acceder sistema)
• Recursos de red (a cuánto del mismo podemos satisfacer en un momento dado)
• Calidad o grado de servicio (que porcentaje no podrá hacerlo)

Nuestro trabajo como consultores consiste en medir o determinar junto a su personal de Marketing:

• El número de llamadas en hora pico
• La duración promedio de las llamadas
• El nivel de tolerancia al bloqueo (que porcentaje de gente que llame obtendrá tono de ocupado)
• La utilización del modelo matemático adecuado
• El número de líneas (o puertos) necesarios que satisfaga lo anterior

Como siempre lo más difícil de determinar (el primer punto) no tiene que ver con la tecnología. Pero lo más importante es que no hablamos de "por las dudas pongamos más", ya que estos modelos nos predicen con exactitud lo mínimo seguro que necesitamos a fin de ahorrar dinero. ¿Si la campaña se amplía? Expandimos el equipamiento, conservando toda la inversión de hardware inicial y software

Cantidad óptima de menúes

Un estudio realizado por George Miller en el año 1956 , "El número mágico siete, más o menos dos: Algunos límites sobre nuestra capacidad de procesar información", documenta el hecho que la mayoría de las personas sólo pueden "procesar" alrededor de siete ítems de información en forma simultánea. Dependiendo del tipo de información y de características del propio individuo, a veces esta habilidad se reduce a cinco y en algunos pocos casos se eleva hasta nueve. De cualquier modo, la mayoría de los estudios realizados en esta dirección se enfocaban en responder o recordar estímulos visuales. Las limitaciones de la memoria a corto plazo son más evidentes ante estímulos auditivos y presentados en forma secuencial. Aunque generalmente se adoptan menúes de cinco ítems, nuestra experiencia dicta una media óptima de tres alternativas por cada menú. Siempre recordemos que este tipo de interfaz es lenta por naturaleza y la información "desaparece" una vez expuesta, lo que provoca cierto nivel de fatiga y ansiedad en el usuario final

Resumen de algunos principios generales:

• Los menús no tienen que reproducir la estructura organizativa o departamental de la empresa (eso es genérico para cualquier tipo de interfaz, sea de voz o no)
• Si el servicio tiene alguna restricción, es preciso avisar al usuario primero de todo. Por ejemplo, en un servicio de compra de tarjetas de llamadas prepagas, si se requiere que el usuario sea cliente, es preciso avisarle antes de nada
• Proporcionar sólo la información que se necesita y de la forma más simple posible
• Diseñar para la mayoría de los usuarios evitando que tengan que recorrer opciones que sólo interesan a unos pocos
• Hacer que el sistema trabaje por el usuario, por ejemplo, no pidiendo el mismo dato varias veces y evitando preguntar información que el sistema puede conocer
• Ser consistente y no cambiar a menudo las opciones de los menús.

Saludo inicial:

• Debe haber una bienvenida breve: buenos días, buenas tardes...
• No repetirlo si en algún momento el usuario vuelve al inicio.

Es preciso evitar:

• Mensajes promocionales: poner sólo si el usuario los puede encontrar justificados y, sobretodo, han que ser breves permitiendo acceder a la información en aquel mismo momento
• Tener que pulsar la tecla * para saber si el terminal es de tonos (DTMF) o no
• Remitir al usuario a otro servicio

Menú principal:

• El primer menú debe ser el principal a no ser que se tenga que pedirse identificación
• Máximo 20 segundos de duración total contando el saludo inicial y el menú principal

Identificación:

• Pedir identificación sólo cuando sea necesaria.
• Pedir el identificador más fácil de recordar: teléfono, DNI...
• Aceptar que el usuario dé cadenas variables de dígitos (ex.: el DNI puede tener 7 u 8 dígitos) sin causarle un error
• Gestionar el final de la entrada de datos por medio de timeout, no solicitar ningún tecleo adicional

Menús:

• Debe estar provistos de un breve recordatorio: título del menú que indica al usuario donde ha ido a parar y de qué tratan las opciones que escuchará
• Ejemplo: "Estado de su Cuenta"
• Máximo 4 opciones por menú, si se utiliza la respuesta por tonos.
• Máximo 3 pasos para hacer una tarea.
• Poner las opciones de navegación al final de todo.

Las opciones de navegación recomendables son:

• Volver atrás
• Menú principal
• Repetir
• Ayuda (sólo si lo necesita la aplicación)

• Si existe una opción de paso al operador, debe ser la última.
• No hay que cortar nunca la comunicación si el usuario se equivoca. Es preciso dar caminos alternativos
• Ordenar las opciones de las más específicas a las más generales

Preguntas Sí/No:

• Se usan para recuperar errores y para confirmar acciones
• Tienen que ser preguntas directas que induzcan a decir de forma natural sólo Sí o No:

Incorrecto:

Por favor, confirme si su DNI es: XXXXXXXX

Correcto:

DNI: XXXXXXXX. ¿Es correcto?

• Debe ser una única pregunta, no dos en una.
• Si además de la pregunta hay texto informativo, poner la pregunta al final de la frase
• Ejemplo: Para obtener más información sobre las condiciones del contrato, ¿desea que pase la llamada a un agente?

No abusar de este tipo de preguntas:

• Evitar concatenaciones de preguntas Si/No.
• Es mejor utilizar expresiones específicas en lugar de preguntas Sí/No.

Ejemplo: Si quiere cancelar la suscripción diga: dar de baja.