Ya está disponible la nueva versión 10 de Evolution.  Esta versión incorpora una serie de cambios y mejoras técnicas que seguro encontrarás muy útiles:

• Dynamic Business Router: Nueva inteligencia Evolution. Asigna estrategias de negocio a cada campaña para el encaminamiento, gestión y distribución a los agentes.

• Define diferentes políticas de reparto de llamadas entre los agentes del Call Center.

• Integra el Call Center con nuevos canales de comunicación a través de aplicaciones y conectores diseñados para cada medio, incorporándolos conforme van aumentando las interacciones con los clientes.

• Multimedia Blending, el agente puede tratar interacciones de diferente origen en la misma interfaz.

• El DBR aumenta la calidad del servicio y reduce el agent burn-out.

• Mejoras en scripting y desarrollo de aplicaciones.

• Obtén más informes en tiempo real y dinámicos: más información, más relevante, al momento.

• Nuevas herramientas para la productividad.

• Nuevas APIs y conectores.

• Compatible con CISCO UCM

Nota: Las funcionalidades activadas dependerán de la edición y licencia Evolution adquirida.

 

Principales mejoras

Nuevo módulo Dynamic Business Router (DBR)

En una configuración Evolution 9.x la distribución de las llamadas la realizaba obligatoriamente la centralita o switch telefónico mediante su propio esquema de colas ACD.

Con el nuevo módulo de “Dynamic Bussiness Router (DBR)” de Evolution ahora se pueden configurar las campañas para que el encaminamiento, gestión de las colas de llamadas y su distribución a los agentes lo realice Evolution, proporcionando una funcionalidad mucho más potente. Esta funcionalidad permite enrutar tanto llamadas de voz como otros tipos de interacciones multicanal basadas en mensajes o documentos, como por ejemplo: e-mail, mensajes twitter, de tareas back-office y documentos escaneados, faxes, grabaciones de audio/video, etc.

Cada diferente ruta de llamadas o interacciones de entrada se asocia a una “estrategia” en Evolution. En cada una de ellas se pueden asignar diferentes parámetros que permiten ajustar la distribución de las interacciones tratadas: campaña asociada, prioridad absoluta o relativa (hándicap), opcion de agente asignado obligatorio, o skills requeridos. Las interacciones serán tratadas por la cola de la campaña asociada.

Habitualmente un agente estará participando en un servicio con múltiples campañas, cada una de las cuales a su vez podrá tener asignadas una o más estrategias inbound. Así cuando un agente quede disponible, el servidor seleccionará la siguiente interacción a atender desde una cola de campaña en función de los atributos y prioridades especificados por la estrategia de entrada.

Inicialmente el módulo DBR es compatible con switch basados en asterisk, si bien se están desarrollando conectores para otras plataformas. Consultenos la disponibilidad de conectores para otros switch.

La funcionalidad core se complementa con conectores específicos para cada tipo de interacción, como por ejemplo un conector para email POP3 y una API web-service. ICR prevé desarrollar nuevos conectores estándar para nuevos tipos de interacción.

 

DBR - Parámetros de routing en campaña

Una campaña configurada con routing tipo = “Evolution DBR-Server” gestionará las colas de interacciones mediante el módulo DBR. 

Para cada campaña de este tipo se podrán administrar diferentes parámetros que afectan el comportamiento de la cola y de las mediciones: ¿Interacciones si cola cerrada?, Tamaño de cola, Timeout de la cola, Política de distribución, Objetivo de servicios, SLA.

 

DBR - Parámetros de estrategia

Administrando los parámetros de las diferentes estrategias se consigue que los agentes atiendan las interacciones según las reglas de negocio. Cada estrategia asocia las interacciones a la cola de una campaña con una prioridad y hándicap. Las interacciones de igual prioridad se esperan en cola de campaña ordenadas secuencialmente según el orden y tiempo de entrada.

El sistema entregará primero las interacciones con una prioridad mayor, siendo la prioridad máxima la asignada por el valor 0 (ordinal).

Ejemplo: Cuando un agente quede disponible se entregarán primero las interacciones de prioridad 0, después las de prioridad 1, y así sucesivamente.

A igual prioridad el sistema entregará primero aquellas interacciones cuyo tiempo de espera en cola sea mayor. Este tiempo de se puede modificar mediante el ‘handicap’.

Ejemplo: Una campaña tiene asignadas dos estrategias, ambas con igual prioridad. La estrategia A con un hándicap=0, y la estrategia B con un hándicap=60 seg. Con esta configuración las interacciones de la estrategia B quedarán ordenadas en la cola de campaña con una penalización de 60 segundos respecto las entregadas por la estrategia A.

Opcionalmente una estrategia puede asignar un agente obligatorio para el tratamiento de la interacción. Si el agente especificado no se encuentra conectado a la campaña se considerará que equivale a la situación de “cola cerrada”, caso en el cual la llamada se desviará según se haya configurado en el parámetro “desvio por cola cerrada”, por ejemplo a otro routepoint asociado a una estrategia menos exigente.

 

DBR - Skills Based Routing

Cada estrategia de encaminamiento DBR permite definir un conjunto mínimo de skills de agente requeridos para su tratamiento. Así las llamadas serán tratadas por los agentes más adecuados.

Esta política aumenta la calidad del servicio a la vez que reduce el agent “burn-out”.

Ejemplo: Defina el conjunto de skills posible mediante administración, usuarios, ver skills. Administre los niveles de skills de cada agente, mediante administración, usuarios, asignar skills. En administración de estrategias, defina el skill set minimo de una estrategia, p. ej: english=50 y tech=60.

Ello comportará que las interacciones entregadas desde dicha estrategia solo se ofrecerán a agentes cuyo skillset incluya skills de english>=50 y tech>=60.

 

DBR - Políticas de reparto de llamadas e interacciones

El administrador podrá configurar diferentes tipos de política de reparto de llamadas entre los agentes de una campaña:

• Agente más ocioso: Se asigna la nueva llamada al agente que lleva más tiempo libre
• Agente con mayor skill: Se asigna la nueva llamada al agente que esté libre y tenga un skill suficiente, y cuyo skill sea mas elevado (el mas experto posible)
• Agente con menor skill: Se asigna la nueva llamada al agente que esté libre y tenga un skill suficiente, y cuyo skill sea menor (el menos experto posible).

Ejemplo: Administrar campaña, router, política de distribución.

 

DBR - Posibilidad de encaminamiento basado en "Service Level Objectives"

Los servicios formados por múltiples campañas en “blending” se pueden administrar para que el reparto de llamadas a los agentes tenga en cuenta criterios de negocio, optimizando el cumplimiento del “objetivo de servicio” administrado en las campañas. Esta opción puede ayudar a mantener estándares de nivel de servicio muy elevados incluso en aquellos casos de servicios que realizan “blending” de campañas con “sevice level objectives” muy dispares.

En este modo de trabajo el servidor seleccionará en cada instante aquella interacción en cola de espera para la cual el cumplimiento del nivel de servicio esté en mayor riesgo.

Ejemplo: supongamos un servicio telefónico que trate llamadas de diferentes campañas, cuyos objetivos de servicio sean 20s, 1m y 10m respectivamente.

En Administración de campañas - Parámetros de configuración de Routing, establezca el valor del parámetro “Objetivo de servicio” (Tiempo máximo para atender una llamada) a 20s para la campaña “VIP”, 1m para la campaña “best customers”, y 10m para la campaña “generic info”. Establezca igual prioridad para las tres estrategias que entregan las llamadas a las respectivas campañas.

Establezca un servicio que englobe las tres campañas, y administre el parámetro de servicio “Política de selección” = “por objetivo de servicio”.

De esta manera cada vez que un agente quede disponible el servidor seleccionará una interacción de aquella campaña para la cual el cumplimiento del objetivo de servicio esté en mayor riesgo, y por tanto garantizando el mejor cumplimiento del objetivo de servicios de todas las campañas.

 

DBR - API Web-Services: Integración de estrategias DBR con CRM y datos de negocio

Se ha incorporado la posibilidad de que las estrategias DBR accedan a datos y bases de datos externas mediante Web-Services. Así por ejemplo se podría acceder a una base de datos de negocio para recuperar datos del cliente y, en consecuencia, encaminar la llamada con la prioridad y skills de agente adecuados.

Esta API web-service facilitará el diseño y construcción de soluciones a medida.

Si necesita encaminar las interacciones a partir de datos de negocio configure estrategias de tipo “dinámico”. Cuando una estrategia de este tipo recibe una interacción se realiza una llamada web-service al servidor externo configurado en la estrategia, de manera que el servidor externo puede devolver dinámicamente los parámetros de estrategia como campaña, prioridad, hándicap, skillset.

 

DBR - Conector para e-mail

Este conector de Evolution lee una cuenta de email de un servidor (POP3) y encamina los emails a la cola universal DBR, que los entregará a los agentes. El agente podrá leer/contestar los emails desde el argumentario desarrollado con Developer.NET. 

Ejemplo: Acceda a administración de campañas, ver conectores DBR, pulse nuevo. Defina los parámetros del nuevo conector: nombre, estado, estrategia asociada y URL de configuración (ej: “pop3://user: Esta dirección electrónica esta protegida contra spam bots. Necesita activar JavaScript para visualizarla :110”).

DBR - Supervisión de las llamadas en cola en tiempo real

Nuevas opciones en Manager desde las que el supervisor del call center podrá supervisar las colas de las campañas: Supervisión de servicios, pestaña DBR, y supervisión de campañas, pestaña DBR.

Desde estas opciones se pueden controlar datos como por ejemplo el número de llamadas en cola, las llamadas abandonadas y el nivel de servicio (SLA). Dispone de gráficos en tiempo real.

 

DBR - Nuevos informes para supervision de las llamadas en cola

Nuevos informes en Manager que permiten conocer datos históricos, como por ejemplo: llamadas abandonadas, SLA, tiempos de espera en cola, etc.

 

DBR - Tratamientos para las llamadas en cola (mensajes, MOH)

Mientras las llamadas se encuentren en cola de espera podrán escuchar música o mensajes en espera. Ello requiere configuración de dialplan en asterisk

 

DBR - API Web-Service (conector) genérico para interacciones multicanal

Esta nueva API basada en websevice permite desarrollar soluciones de encaminamiento que se integren con el módulo DBR.

Permite, tanto a partners como usuarios finales, desarrollar nuevos conectores multimedia de tipo documento/texto.

Un ejemplo pueden ser aplicaciones de backoffice que a través de esta API alimenten al DBR con documentos, formularios u otros tipos de interacciones.

 

DBR - API (conector) para integrar IVR como 'front-end'

Esta nueva API permite integrar IVRs externas para que actúen como frontales interactivos para la atención de llamadas.

Con ello se podrán diseñar soluciones en las que frontales IVR pre-cualifiquen las llamada y le den un tratamiento automático, y que en un momento dado puedan requerir su transferencia a un agente real, asignándola a una cola DBR con los skills y prioridades adecuadas. Las API permitirán asociar datos a las llamadas, para su posterior acceso desde los agentes de Evolution.

Nota: En v10 esta API soporta switch tipo asterisk.

 

DBR - Múltiples DNIS por campaña

Algunas configuraciones call center pueden beneficiarse de la posibilidad de definir múltiples DNIS por campaña.

V10 facilita esta configuración a través del concepto de estrategias. Para campañas tipo switch-based se podrán asignar múltiples estrategias de tipo DNIS. Para campañas de tipo DBR se podrán asignar múltiples estrategias de tipo DBR.

Las estrategias de tipo DNIS admiten el uso de caracteres comodín.

 

Developer.NET – Librería para interacciones genéricas

Gracias a las API ampliadas Developer.NET se abre la posibilidad de desarrollar argumentarios/scripts de agente para el tratamiento de interacciones no telefónicas, como por ejemplo pueden ser tareas “backoffice”, mensajes email o twitter, etc.

 

Developer.NET – Control visual genérico para documentos

Este control de Developer-NET permite abrir (o descargar) los documentos de las interacciones, como por ejemplo emails, imágenes, pdf, word, etc.

Cuando se abra una interacción tipo email ejecutará automáticamente el cliente de email Outlook Express y/o Outlook 2010 mediante el documento .EML.

 

Reorganización de algunos parámeros Manager a nivel de servicio

Algunos parámetros se han cambiado desde el formulario de administración de campaña al de administración de servicio, para mejorar su facilidad de uso:

• Modo siguiente gestión
• Tiempo de call blending (para servicios con campañas switch-based).

 

Mejoras en la gestión y almacenamiento de las contraseñas de los usuarios

Cambios en la gestión y almacenamiento de las contraseñas de los usuarios. Estos cambios facilitan la compatibilidad con leyes de protección de datos vigentes en algunos países.

 

Tiempo de pausa tras gestión

Un nuevo parámetro a nivel de servicio permite introducir una pausa obligatoria entre el final de una gestión y el inicio de la siguiente.

Este parámetro facilita el cumplimiento de legislación y convenios laborales exigible en determinados países.

 

Posibilidad de enviar mensajes a agentes desde rol de supervisor

Ahora los usuarios de tipo “supervisor” también tienen acceso a la opción de envío de “mensajes a agentes”, que anteriormente estaba accesible solo para el rol de usuario “administrador”.

 

Compatible con CISCO UCM

Evolution es compatible con CISCO UCM, ampliando la gama de posibilidades de crecimiento y flexibilidad que los Call Centers necesitan permitiendo la colaboración eficiente, reducción de costes, y una notable mejora en la atención al cliente.

 

Certificación W2008 Server R2

Certificación oficial Microsoft para la instalación de Evolution sobre Windows Server R2.

 

Lista de cambios v10.1

Evolution - Change Log

• 0003428: MEJORA: Ahora iAgent permite realizar transferencias one-step con Asterisk marcando #num-destino.
• 0003455: Cuando un agente selecciona canal presencial sin permisos para ello se mostraba un aviso con aspecto UI incorrecto.
• 0003500: En escenarios de abandonada se pueden registrar errores en la administración de eventos de Manager.
• 0003483: Mejora del cálculo de contactos necesarios en marcación automática.
• 0003477: Cuando se va a buscar trabajo pendiente WRE y no se puede pasar a Not Ready, se va a buscar trabajo igualmente.
• 0003422: MEJORA: Soporte para TAPI CISCO CM7.
• 0003429: En casos de problemas CTI el dialer puede finalizar sin exito múltitud de registros.
• 0003302: Secuencias de no-ring-back pueden provocar que se deshabiliten dispositivos del marcador.

Developer.NET - Change Log

• 0003474: Nuevas propiedades de EvolutionLibrary.
• 0003471: Posible error de servidor en paginas de busquedas de argumentarios en W2008R2: "No son válidos los comandos y tablas del...".

EvoServer - Change Log

• 0003505: En el proceso de finalizar gestión si se cambia el estado a vista previa, se inicia una gestión y acto seguido se borra.
• 0003493: Después de RONA DBR, si se hace una llamada privada al agente, al colgar iAgent sigue en llamada.
• 0003496: No se resetea el contador de cola para el día en curso.
• 0003488: En escenarios Switch Based + VP/A + DBR + CallBlending, al pasar de disponible a VP se puede entregar una entrante concurrenteme.
• 0003494: El tiempo de espera en cola en inbound DBR incluye el tiempo que la llamada está alertando en el puesto del agente.
• 0003502: En base de datos el tiempo de espera en cola sólo puede ser de poco menos de 28h.
• 0003486: Puede que se intente encolar 2 veces la misma interacción con mismo invokeId.
• 0003482: Usando marcación automática, en escenarios con llamadas excedentes insuficientes para todos los agentes el marcador no marca.
• 0003468: MEJORA: Que en progresivo se pueda generar mas de 1 llamada simultaneamente.
• 0003467: En algunos escenarios con marcador Dialogic TAPI Panasonic no se actualiza idtransaccion de la gestion.
• 0003476: Los automatismos de replanificación por final '17 - Fuera Intervalo Rellamada' no funcionan.
• 0003472: Cuando el agente pasa a disponible en marcación automática las marcaciones pueden demorarse.
• 0003451: Algoritmo marcacion redondea innecesariamente el numero de llamadas antes de aplicar el factor corrector.
• 0003461: EvoServer no informa del tiempo de espera en cola en las llamadas no entregadas a agente cuando el cliente está identificado.

iAgent - Change Log

• 0003506: iAgent no reconoce un paso a disponible con Causa: 'Se ha finalizado la gestión en curso'.
• 0003473: Hacer que el argumentario reciba en la QueryString de inicio los parámetros IdContacto y DNIS.
• 0003460: iAgent pasa automáticamente a no disponible tras un abandono de cliente, aunque puede que no sea inmediato.
• 0003452: Al colgar una llamada outbound en ALERTING generada desde extension de agente, automaticamente aplica final ABANDONADA.
• 0003459: iAgent no muestra la página de disponible cuando la causa es 'Esperamos llamada de DBR'.

Manager - Change Log

• 0003463: MEJORA: Nuevo informe que lista las transacciones de agente antes y después del objetivo de campaña.
• 0003462: Nuevo filtro 'Canal' para los informes de contactos.
• 0003466: En el listado de las campañas de la supervisión de servicios, las columnas de los totales están desplazadas.

Lista de cambios v10

Evolution - Change Log

• 0003290: Algunos parametros de campaña movidos a servicio.
• 0003431: MaintenaceDaemon.NET no elimina las tareas de carga de campañas no activas o con id. incorrecto, tras haberlas intentado.
• 0003430: MaintenanceDaemon.NET elimina las tareas erroneas obsoletas.
• 0003400: En Histórico de Sesiones de Agente, para una sesión abierta, se muestra una hora de fin=hora inicial.

EvoServer - Change Log

• 0003439: Conservar funcionalidad en que las llamadas a puestos de trabajo sin Agente se traten como Agente-Agente.
• 0003425: En las llamadas inbound, actualizar el tInicio de la transacción cuando se reciba el evento EstablecidaLLamada.
• 0003388: Alto consumo de recursos con número elevado de agentes y campanyas por el proceso de carga de caches.
• 0003419: Refactoring: Mover CCampManager al Coord.
• 0003383: Posible Access Violation cerrando el servicio EvoServer.

Developer.NET - Change Log

• 0003346: DatosCliente_DropDownList no publica métodos para acceder al valor seleccionado.
• 0003347: El dato que se guarda de un control DatosCliente_DropDownList es el Text, no el Value.
• 0003438: Al crear proyecto evoproj en VisualStudio junto con las plantillas aparecen otros ficheros.
• 0003364: Si se añade una referencia a un proyecto .evoproj, al reabrir el proyecto la referencia no se carga bien.

iAgent- Change Log

• 0003460: Cambio de comportamiento: Ahora iAgent no pasa automáticamente a no disponible tras un abandono de cliente
• 0003459: iAgent no muestra la página de disponible cuando la causa es 'Esperamos llamada de DBR'
• 0003452: Al colgar una llamada outbound en ALERTING generada desde extensión de agente, automáticamente aplicaba final ABANDONADA
• 0003443: AgentScript ObtenerValorClave_js puede provocar excepción en iAgent.
• 0003440: Tras llamada abandonada el agente queda en tiempo administrativo.
• 0003441: iAgent puede mostrar un tiempo en no disponible erroneo.
• 0003377: El histórico de gestiones de iAgent no muestra las gestiones del día.

Manager - Change Log

• 0003434: La página que permite seleccionar los registros que se exportarán a Excel no se visualiza correctamente en IE9.
• 0003285: Manager realiza un 'merge' de servicios si se informan con el mismo Nombre. 

Ver lista de cambios en 9.5.3 

Contacto/Soporte

Para preguntas y dudas técnicas respecto Evolution, puedes hacer uso de nuestro foro de soporte. 

Para mas información del producto y de los servicios que te podemos ofrecer, contacta a través de nuestro formulario de contacto.