En este artículo me propongo hablar sobre Genesys Cloud (GC) y en particular sobre sus capacidades y limitaciones a la hora de gestionar una parte vital en la mayoría de los contact centers, las campañas salientes.
Desde hace unos años y de forma más intensa desde la pandemia, se viene produciendo en el ecosistema del contact center un inevitable desplazamiento a la nube. Los sistemas on-prem basados en hardware desplegado y administrado localmente ya no son capaces de ofrecer soluciones ágiles, ni escalables en un mundo en el que las redes sociales, los canales digitales y la IA dibujan un panorama en el que la única verdad inamovible es el cambio constante.
Ante esta realidad, tozuda, como es la realidad, los fabricantes ya hace un tiempo que decidieron apostar por soluciones en la nube para las plataformas de CC. No obstante, esto ocurrió con retraso en comparación con otros ámbitos empresariales, recordemos que Salesforce propició esto mismo en el sector CRM desde la primera década del siglo XXI. El contact center es un entorno más complejo, gestiona todo tipo de interacciones con los clientes, pero en aquella época y aún hoy en día, la mayoría de ellas son llamadas telefónicas. Este tipo de interacciones, con sus particulares exigencias de latencia, y calidad de servicio, necesitaba de tecnologías que no se extendieron en el mundo empresarial hasta una década más tarde. Para entonces, con el advenimiento y popularización de la voz ip (VoIP), los fabricantes de CC ya no tenían excusa y la propuesta de soluciones en la nube empezó a hacerse realidad. Al principio eran soluciones on-prem hosteadas y finalmente llegaron las plataformas cloud reales, multitenant y basadas en arquitecturas de microservicios, capaces de ofrecer escalabilidad y multitud de canales en un modelo de pago por uso.
Habrá quien se pregunte en este punto, ¿pero este artículo no iba sobre GC y campañas salientes? …claro que sí, de eso va, pero la perorata anterior me sirve, antes de entrar en materia, para lanzar el siguiente disclaimer. Las plataformas CCaaS ofrecen innumerables beneficios, flexibilidad, escalabilidad, pago por uso, un “time to market” reducido en comparación con las soluciones on-prem e innumerables posibilidades de innovación. Sin embargo, son productos jóvenes, con un tiempo de vida inferior a 10 años en la mayoría de los casos y, por tanto, para el administrador de una plataforma on-prem con un desarrollo de producto de 25 años o más a sus espaldas, la propuesta de GC le parecerá, quizás, “básica”. Sin embargo, en mi opinión, los beneficios superan con creces a las carencias y este tipo de productos mejoran cada día, en el caso de GC con decenas de nuevas features liberadas cada semana.
Y en este punto vamos al lío, que si no el post se me va a hacer largo y tampoco quiero aburrir contando batallitas.
Este es el “modelo de objetos” del módulo outbound en GC:
Hay dos entidades claves en este modelo… en el lado derecho del ring y vestido de naranja para esta ocasión, ¡el Agente! y ocupando el lado izquierdo y con calzón azul, tenemos ¡al Contacto!, entendido como el ente con el que queremos hablar y que podrá ser un lead (más o menos cualificado) o un cliente consolidado.
Entre ambos “contendientes”, encontramos el “ring outbound”, conformado por un montón de artilugios que tratarán de hacer el proceso de contactación lo más eficiente posible, automatizando reintentos, lanzando múltiples marcaciones en paralelo para tratar de maximizar la probabilidad de contactación y de minimizar el tiempo en que un agente debe esperar para tener la oportunidad de hablar con el próximo contacto.
Los agentes trabajan conectados a colas, una cola distribuye llamadas entre los agentes conectados a la misma. Con los permisos adecuados los propios agentes pueden decidir en qué colas participan, pero esto suele ser potestad de los supervisores. Por supuesto, es posible un modelo blend en el que los agentes trabajan atendiendo llamadas entrantes y salientes al mismo tiempo. En este caso, es posible (y común) priorizar las llamadas entrantes sobre las salientes.
La campaña es la entidad central del modelo. En ella se define un modo de funcionamiento (preview, progressive, power, predictive) y un conjunto de contactos con los que queremos hablar (Contact list). La campaña tiene una cola asociada, la cual determina, como ya hemos visto, un conjunto de agentes que atenderán las llamadas salientes contactadas. Un agente puede pertenecer a varias colas, y por tanto trabajar en varias campañas. En este caso, se pueden establecer prioridades de campaña para modelar la probabilidad de que un agente reciba llamadas de una campaña u otra según los valores de prioridad establecidos. Adicionalmente, una campaña tiene asociado un script que se mostrará al agente para guiarlo en la conversación con el contacto.
Podemos clasificar las campañas por el tipo de marcación (automático o preview), por el modo de marcación (preview, progressive, power, predictive) o por el tipo de atención (atendidas por agentes o agentless, es decir atendidas por un bot). Las campañas agentless no tienen script, pero tienen un outbound flow que determina cómo será la interacción con un contacto que descuelga nuestra llamada. Para el caso de campañas automáticas (progressive, power, predictive), Genesys Cloud proporciona una call response config que define qué hacer en caso de que nos conteste una locución predefinida / contestador automático o bien un humano.
Lo habitual será que si es una locución predefinida colguemos la llamada y si es un humano, lo encaminemos a un outbound flow que proporcione un tratamiento para la llamada saliente, por ejemplo, enrutarla a una cola o a un bot.
Una campaña tiene asociada una contact list, que es la base de datos que contiene los contactos a los que deberemos llamar y también una DNC (Do Not Call) list, que es justo lo contrario, una lista de contactos a los que no deberíamos llamar, bien porque nos lo han pedido explícitamente, bien porque han expresado su voluntad de no ser molestados al darse de alta en la lista Robinson.
Justo antes de hacer una llamada o justo después de que finalice, podremos utilizar reglas para decidir si la llamada debe ser realizada (precall rules) o bien para desencadenar algún tipo de acción tras la finalización de esta (wrapup rules). El conjunto de reglas (precall y wrapup) constituyen un call rule set que puede ser asociado con una determinada campaña.
En una lista de contactos podríamos tener contactos de diferentes lugares del mundo. En función de su ubicación podremos establecer en qué horario podrá ser contactado mediante los contactable time sets.
Además, para una campaña podremos definir un schedule o calendario, que nos permite configurar en qué días y a qué horas estará activa.
Una contact list se puede cargar mediante un fichero CSV o mediante API. A la hora de realizar el seguimiento de una campaña, contamos con un dashboard que nos proporciona métricas por campaña como el % de contactación, % de abandono, progreso de marcación, etc., pero si necesitamos entrar al detalle de cada contacto, número de intentos de marcación, y resultado en cada caso, la única alternativa disponible es exportar nuevamente la contact list a un fichero CSV. Esta es una de las limitaciones del producto y una posible área de mejora, que nos consta que está en roadmap.
En cuanto al orden de marcación, en una campaña podemos especificar uno o más campos de la contact list para definir el orden en que cargaremos los contactos. Por defecto la contact list se ordena al iniciar o resetear (reciclar) la campaña. Sin embargo, podemos establecer que una campaña tenga dynamic queueing sorting y en este caso, al insertar nuevos contactos en la contact list, estos se reordenaran en tiempo real sin necesidad de reiniciar la campaña. La mala noticia es que la cantidad de campañas que podemos definir con dynamic queueing sorting es limitada. La buena es que, mediante el uso del API, podemos conseguir que un contacto añadido o actualizado en cualquier campaña pueda ser reordenado en tiempo real.
Al asociar una contact list a una campaña, podemos definir un filtro que determine qué registros de la contact list serán llamados y cuales no. Una contact list puede ser compartida por varias campañas y para cada una de ellas podríamos establecer filtros diferentes. La limitación en este caso viene del hecho de que dos campañas que compartan una contact list no pueden estar activas simultáneamente.
Para finalizar, algunas limitaciones adicionales a las ya mencionadas.