Varias personas examinan documentos sobre una mesa

Cómo comenzar a diseñar tu Omnichannel

Cómo comenzar a diseñar tu Omnichannel

El Omnichannel es una de las herramientas más poderosas que Salesforce pone a nuestra disposición, pero en mi experiencia como consultor he visto que normalmente muchos administradores tienen problemas cuando necesitan diseñar y configurar esta herramienta por la cantidad de conceptos nuevos que introduce.

Este documento no busca ser una guía técnica (para eso ya está la propia página que Salesforce pone a disposición de los usuarios) si no que busca ser un empujoncito a la hora de comenzar a diseñar Omnichannel. Su público objetivo debería ser gente que o bien se ha leído la guía técnica y está teniendo dificultades con el diseño, o gente que quiera una aproximación a esta herramienta previa a leerse la guía técnica en profundidad.

Definiciones importantes para configurar Omnichannel

A partir de aquí iremos repasando los conceptos más importantes para configurar un Omnichannel basado en colas y entrando en más o menos detalle según necesidad.

Service Channels

Empezaremos con los Service Channels, esta es la parte más sencilla ya que simplemente debes crear un Service Channel por cada canal (objeto) que vaya a ser enrutado por el Omnichannel, así que si por ejemplo tu omnichannel va a asignar Casos, Chats y registros de un objeto custom Object__c, necesitarás tres service channel, uno para Case, otro para el objeto Chat y otro para Object__c.

Estos Service Channels los usaremos después a la hora de configurar los Presence Status es de nuestro Omnichannel.

Presence Status

Un Presence Status es cualquiera de los estados en los que un agente puede estar cuando ha iniciado sesión en Omnichannel. Vamos a separarlos en dos tipos, estados Busy y Online.

Estados Online

  • Son aquellos estados en los que el agente se encuentra trabajando. Lo que hacemos al crear un Presence status es esencialmente definir qué objetos puede recibir un agente que esté conectado en este estado, y esto lo hacemos añadiendo uno o varios de los Service Channels. Vamos a poner un ejemplo para entenderlo mejor.

Supongamos que tengo un grupo de agentes que inicialmente su cometido es trabajar con casos y otro grupo de agentes cuya principal ocupación es responder a los chats. Puedo crear un estado que se llame “Disponible para casos”, añadir el Service Channel de Casos que he creado antes, y de manera análoga crear un estado que sea “Disponible para Chat” y le añado el Service Channel de Chat.

De igual manera, podría crear un tercer estado que fuese “Disponible Chat y Casos”, y añadir los dos canales a la vez, lo cual haría que pudiese recibir trabajo de ambos tipos.

Este tipo de configuración hace que el centro pueda asignar sus recursos de forma rápida y eficiente, ya que ante una avalancha de Chats, el supervisor podría cambiar el estado de uno de los agentes “Disponible Casos” a “Disponible chat” para ayudar a desahogar al otro equipo.

Estados Busy

  • Son aquellos estados en los que el agente está conectado al Omnichannel pero no está trabajando. Ejemplos de estos estados son: “No disponible: Comiendo” o “No disponible: en el descanso”. La única diferencia entre diferentes estados busy es su nombre, con el objetivo de dar información acerca de la situación del agente.

Presence Configuration

Ahora vamos a hablar de las Presence Configuration, entre otras cosas aquí definimos la Capacity (capacidad) del agente, y de momento vamos a quedarnos con que esta capacidad es la “cantidad de trabajo” que el agente puede realizar al mismo tiempo, cosa que se comprenderá mejor cuando expliquemos lo que viene a continuación.

Llegamos al punto donde creo que esta guía podrá ser más útil a los administradores, ya que procedemos a hablar de los Routing configuration y las Queues (o Colas), dos conceptos distintos pero que se relacionan de manera directa y que suele traer los mayores quebraderos de cabeza a la hora de diseñar la solución si no se terminan de comprender. También a partir de ahora nos referiremos con el termino “item de trabajo” a cada uno de los registros que van a ser asignados por el omnichannel (es decir, un caso es un item, dos chats son dos items…).

Routing configuration

Lo más importante que podemos configurar aquí es la Prioridad y el peso de cada item de trabajo. Si recordáis, un poco más arriba hemos decidido la capacidad de cada agente, pues el “peso” de cada item es la cantidad de unidades de capacidad que consume ese trabajo. Es decir, supongamos que un agente con capacidad 10 está en estado “Disponible para caso” y está recibiendo casos con peso 4. Como cada caso consume 4 unidades de capacidad, si está trabajando en dos casos de manera simultanea, su carga de trabajo será de 8 sobre 10 y aunque su estado sea “Disponible para caso”, el omnichannel no le asignará más casos porque sobrepasaría su capacidad. Si cerrase alguno de estos casos, su carga bajaría a 4 sobre 10 y por lo tanto tendría “capacidad” para asumir un nuevo caso de peso 4.

Queues: En las colas configuramos:

  • Los objetos que pueden asignarse a esa cola.
  • El routing configuration asociado a esa cola. Esto significa que los Items que se asignen a esta cola tienen el peso y prioridad que la routing configuration asociada indique. Varias colas pueden tener asociado el mismo Routing config.

? Como los Routing config se asignan a colas, es obvio que si definimos n Routing configuration, para usarlos todos vamos a necesitar al menos n colas.

  • Los agentes encargados de esa cola. Son los agentes que pueden recibir los Items asignados a esta cola.

El resumen de todo esto sería que los Presence Status controlan qué Service Channels (objetos) pueden llegarme, mientras que las colas determinan qué registros de esos objetos me llegan pero como hemos dicho, aquí normalmente empiezan los problemas, ¿Cuántas colas necesito? ¿Cuántos routing configuration me hacen falta?…

Aquí recomiendo que te preguntes “¿cómo se diferencia el trabajo del centro?”, es decir, analiza en qué y cómo deben diferenciarse todas las tareas del centro de trabajo y su respuesta te ayudará a diseñar la solución. Un ejemplo:

Si se trabaja con Casos y hay un tipo de Caso en particular (Incidencia) que debe tener prioridad sobre el resto, la conclusión obvia es que vas a necesitar crear dos routing config (uno con mayor prioridad que el otro). Y como tienes 2 routing config, entonces vas a necesitar crear dos colas para poder asociar cada routing config a uno de ellas. Luego simplemente tienes que encargarte de que cada caso llegue a la cola correspondiente, sencillo ¿verdad?

Tal y como has visto, mi recomendación es empezar definiendo cuántas configuraciones distintas peso+prioridad vas a tener, puesto que ese es el número de Routing Config que necesitas crear. Una vez tienes esto ya puedes crear tantas colas por cada Routing Config como necesites. Un ejemplo:

Tengo un routing config con peso 4 y prioridad 3. Esta misma configuración debería aplicar a los casos de tipo Consulta Hipotecas y de tipo Consulta Seguros de Vida, pero la gente encargada de responder a estos consultas no son el mismo equipo, la solución es crear dos colas que usen el mismo Routing Config, añadir las personas adecuadas a cada una de ellas, y luego asignar cada caso a su cola correspondiente.

Si seguimos sobre este ejemplo, también podríamos pensar que:

Si yo soy uno de los agentes encargados de responder a consultas sobre hipotecas, es factible que sea capaz de responder a las consultas independientemente de que me lleguen por correo o por chat, ¿verdad? Sin embargo no tengo por qué tener los conocimientos adecuados para responder a las preguntas sobre Seguros de Vida.

Como os estaréis dando cuenta, lo primero está controlado por el estado del Omnichannel del agente mientras que lo segundo está controlado por las colas en las que está, y por lo tanto es bastante común acabar haciendo una asociación directa de que Cola = Tecnología/conocimiento, y que las colas acaben representando cada una de las tecnologías/conocimientos distintos que hay en un centro, con independencia de que luego puedas necesitar varias colas por cada sección (por ejemplo, Cola Hipotecas y Cola Hipotecas – Urgente).

Con esto acabamos el documento, espero que haya cumplido su propósito de ayudaros a comprender como diseñar un Omnichannel, y aunque aún queda mucha configuración posible para este Omnichannel basado en colas, esta debería ser sencilla de realizar siguiendo la guía que proporciona Salesforce.

Visita nuestra página de Customer 360 y entérate de cómo en Clarcat, de la mano de Salesforce te ayudamos a mejorar la gestión de tus relaciones con los clientes gracias a la plataforma tecnológica CRM más avanzada del mercado.

Foto del avatar
clarcat

Si necesitas una consultora tecnológica de confianza para el desarrollo de tu negocio, Clarcat es para ti

Artículos: 67