Las reglas de capacidad forman parte del desvío omnicanal y designan las capacidades del trabajo asignado automáticamente para ayudarle a equilibrar la carga de trabajo de todo el equipo. La configuración estándar del desvío omnicanal asigna el trabajo al agente que tiene la máxima capacidad disponible para el canal y un estado idóneo. Por ejemplo, puede especificar que solo se pueden asignar a un agente diez tickets por correo electrónico a la vez. Este puede ser un método excelente para asegurarse de no asignar demasiado trabajo a los agentes que aún no tienen mucha experiencia.
Sin embargo, también se puede configurar el desvío omnicanal para que use una asignación por distribución equitativa. Cuando se usa la asignación por distribución equitativa, el desvío omnicanal verifica que los agentes tengan algo de capacidad disponible, pero asigna el trabajo en función del tiempo transcurrido desde la última asignación para ese canal en lugar de cuánta capacidad disponible tienen los agentes.
El desvío omnicanal viene con una regla de capacidad predeterminada que se puede usar tal como está, o también se puede editar. Los administradores también pueden crear sus propias reglas de capacidad para que se ajusten mejor a sus necesidades. Los agentes siempre son asignados a la regla de capacidad configurada inicialmente como predeterminada, pero esa asignación se puede cambiar de ser necesario. Un agente solo puede tener asignada una regla de capacidad, de modo que si se asigna una regla nueva a un agente, se elimina automáticamente la que tiene asignada en ese momento.
Agregar reglas de capacidad
El desvío omnicanal viene con una regla de capacidad incorporada para ayudarle a dar los primeros pasos, pero se pueden agregar reglas adicionales, si es necesario. Es necesario ser administrador para crear y administrar reglas de capacidad.
Para agregar una regla de capacidad
-
En el Centro de administración, haga clic en
Objetos y reglas en la barra lateral y luego seleccione Desvío omnicanal > Reglas de capacidad.
- En la página Reglas de capacidad, haga clic en Agregar regla de capacidad.
- En la página Agregar regla de capacidad, proporcione la siguiente información:
- Nombre: ingrese un nombre descriptivo para la regla de capacidad.
- Descripción: si lo desea, ingrese una descripción que le ayude a identificar la regla de capacidad.
-
Definir como predeterminado: los nuevos integrantes del equipo son asignados automáticamente a la regla de capacidad predeterminada. Los integrantes del equipo que ya tienen asignada una regla de capacidad no cambiarán.Nota: Si se crea una nueva regla de capacidad y se asigna a un integrante del equipo, se le elimina de la regla de capacidad predeterminada. Si se borra una regla de capacidad, todos los integrantes del equipo que están asignados a ella, son asignados de nuevo a la regla predeterminada.
- Agentes asignados: haga clic en Agregar agente asignado para especificar a los agentes a quienes se aplica esta regla.
- Capacidades > Correo electrónico: ingrese el número de tickets de correo electrónico (incluidos el formulario web, las conversaciones secundarias y la API) abiertos que pueden asignarse a un agente a la vez. Esto incluye todos los tickets de correo electrónico abiertos, sin importar cómo fueron asignados al agente. Los tickets que están pendientes o en espera no se cuentan para la capacidad. (Máximo 500).
- Capacidades > Mensajería: ingrese el número de tickets por mensajería que pueden asignarse a un agente a la vez. Los tickets de mensajería inactivos se cuentan si se ha seleccionado el enrutamiento de la actividad de mensajería. De lo contrario, se toman en cuenta solo los tickets de mensajería activos. Esta capacidad también se aplica a los chats en algunas circunstancias. Cuando se aplica a los chats en vivo, se puede asignar hasta dicha cantidad de chats en vivo y dicha cantidad de conversaciones de mensajería a un agente a la vez. (Máximo 500).
- Capacidades > Talk: ingrese el número de tickets de llamadas que pueden asignarse a un agente a la vez. Las opciones son 0 y 1. Si elige 0, los agentes no podrán recibir llamadas. Las llamadas ya no se toman en cuentan para la capacidad de un agente una vez que finaliza el tiempo de conclusión (si se ha configurado) o después de que el agente cuelga.
- Cuando termine, haga clic en Agregar regla de capacidad.
Su nueva regla de capacidad se muestra en la página Reglas de capacidad y entra en funcionamiento de inmediato.
Comprender cómo funcionan las reglas de capacidad para las conversaciones de mensajería y los chats en vivo
- El valor que se especifica para la capacidad de Mensajería se aplica tanto a las conversaciones de mensajería como a los chats en vivo por separado. Si se especifica una capacidad de mensajería de 3, a los agentes se les puede asignar hasta 3 tickets de conversaciones de mensajería y 3 chats en vivo a la vez.
- En las conversaciones, existe el concepto de tickets activos e inactivos. Zendesk define una conversación de mensajería como inactiva cuando un usuario final no ha enviado una respuesta en los últimos 10 minutos. Sin embargo, los administradores pueden usar la opción de liberación de capacidad para modificar este valor y cambiar el estado de los tickets de mensajería inactivos.
- La configuración del desvío omnicanal contiene una opción de enrutamiento de la actividad de mensajería.
El enrutamiento de la actividad de mensajería está desactivado de manera predeterminada. Cuando está desactivado, el desvío omnicanal solo cuenta los tickets de mensajería activos para la capacidad de un agente. Esto quiere decir que los agentes pueden tener cualquier cantidad de conversaciones de mensajería inactivas y chats en vivo inactivos asignados, además de la capacidad especificada de conversaciones activas. Si personaliza la opción de liberación de capacidad, podrá ajustar en detalle la capacidad de los agentes en este caso. Cuando una conversación inactiva se vuelve activa otra vez, los agentes pueden exceder la capacidad especificada. El desvío omnicanal no les asignará ningún ticket nuevo en ese canal hasta que vuelvan a tener capacidad disponible.
Cuando está activado el enrutamiento de la actividad de mensajería, el desvío omnicanal cuenta todos los tickets de mensajería abiertos activos e inactivos para la capacidad de un agente. El desvío omnicanal asigna los nuevos tickets de conversación a los agentes solo cuando el número total de sus tickets de mensajería y de chat en vivo asignados, respectivamente, se encuentra por debajo de su capacidad especificada.
56 comentarios
Barry Neary
cc: 1263082297649
0
Jesus Gonzalez
Hi everyone!
I have a question regarding Messaging. Does anyone know if it's possible to enable the Accept button when a messaging chat transitions from an Inactive session state back to Active?
Currently, we have a trigger that unassigns the messaging ticket and reassigns it to a group. However, when the session becomes Active again, we'd like to notify messaging agents—preferably via the Accept button, Conversation button, or an alert—so that any available agent can accept and continue the chat.
Has anyone found a way to accomplish this? Appreciate any insights! TIA.
0
Jimmy Rufo
Hi 1263082080589 , thanks for the update today. If you or 1263082108669 could refer to me to the post discussing the feature to “stagger” OCR related ticket assignments over time, that would be great!
0
Gabriela Manarim
We need more roles to have permissions to edit settings. This is a feature for team leaders, and not everyone needs to be an administrator.
1
Jimmy Rufo
Hi 1263082080589 ,
My recent concern was specific to agent status toggling, of which there is no documentation regarding if they will default to “Online”, “Offline”, if a default can be set for agents in a particular capacity rule, etc. I know we are meeting on Monday, so may be best to clear this all up early next week. Thanks.
0
Barry Neary
Hi 1263169422950
Sorry for the confusion: the agents with zero capacity can still be assigned support tickets manually either self assiginging from views or being manually assigned tickets from supervisors. Its the routing engine that will not assign them tickets
0
Jimmy Rufo
Hi 1263082080589 ,
I think there is a misunderstanding here. The ~200 agents not using OCR will still NEED to be assigned tickets, just not in an OCR capacity, if that makes sense. The tickets would get assigned manually to them or via transfer of ticket to their ticket group. In that respect, I'd want them to not have to worry about agent status and receive tickets manually as they always had. I have only 8 agents or so that I want to test OCR with, and dealing with the other 200 agents is proving problematic. I'd love to speak with someone close to this feature to find a way to get this implemented, as I've had so many stops and starts.
0
Barry Neary
HI 1263169422950
Those agents with zero max capacity will not be assigned tickets, independent of what their agent status is set to. So those agents can just ignore their agent status
Barry
0
Jimmy Rufo
Hi 1263082080589 , for the rule with the 300+ agents with 0 capacity, would those agents have to adjust to having to set an agent status when navigating to the agent interface? Since they are not going to be active for OCR at this time, I would want to ensure they don't have to adhere to a workflow that is irrelevant to them, and could prevent them from receiving tickets.
0
Tina
Hi 1263082080589, regarding your comment reply to D. Fitz on Nov 5. Are there any plans in the future to implement some improvements to cater for this scenario? It would be nice to have some configuration on these tickets that were already replied to that were there before agent signed in (to automatically move to On-Hold so they can receive the more time pressing tickets) or another method.
Currently we are experiencing a similar problem and we've set up some automations to unassign tickets after being held for some time and changing priorities when the SLA is about to breached, though it is more of a workaround for now. Increasing the capacity isn't really the best solution since:
- If people sign on too early, they get all the nearly SLA breached tickets. Even though who sign on a few minutes afterwards may not get some of that workload and they would need to wait for a team leader to sign on to reassign tickets manually.
- Or people who sign on a little later may not receive any tickets since everyone has higher capacity. They need a team leader to reassign tickets to them manually.
Thanks.
1
Iniciar sesión para dejar un comentario.