Evitar conflictos entre los disparadores

Algo con lo que debe tener cuidado son los disparadores que deshacen o modifican una acción contenida en otro disparador. Imagínese, por ejemplo, que ha creado un disparador para asignar tickets en función de la compañía donde trabajan los solicitantes de los tickets. Crear ese disparador es algo muy sencillo. Se agregan etiquetas a las organizaciones y luego cuando los usuarios de esas organizaciones envían solicitudes de soporte, esas etiquetas se agregan a sus tickets.

Ejemplo: Organización Banco 1

Ejemplo: Organización Banco 2

Siempre que se recibe un ticket de un usuario de una de esas organizaciones, se agrega la etiqueta correspondiente al ticket.

Luego, se pueden usar las etiquetas 'cima' y 'oriental' en un disparador para asignar esos tickets al grupo correspondiente. Por ejemplo, queremos asignar tickets de esos dos bancos al grupo de soporte Nivel 2.

Al activarse el disparador, se hacen las asignaciones de grupo necesarias.

Imagínese ahora que tiene otro disparador que asigna tickets recibidos por correo electrónico al grupo de soporte Nivel 1, como en el siguiente ejemplo:

El problema es que se produce un conflicto accidental. El primer disparador asigna los tickets provenientes de esos bancos al grupo de soporte Nivel 2 porque esos tickets contienen la etiqueta 'cima' o la etiqueta 'oriental' y el segundo disparador cambia ese grupo al grupo de soporte Nivel 1 porque la solicitud se recibió por correo electrónico. La verdadera intención es que los tickets de esos dos bancos sean asignados automáticamente al grupo de soporte Nivel 2.

El conflicto se debe a que solo es posible asignar un ticket a un grupo a la vez y aquí tenemos dos disparadores activos que establecen dos asignaciones de grupo distintas en función de condiciones distintas.  

El orden en que figuran los disparadores en la lista de la página Disparadores es lo que marca la diferencia porque los disparadores se procesan en orden de arriba abajo. En nuestra lista de disparadores, el disparador de ejemplo Asignar tickets de clientes-banco a soporte Nivel 2 viene antes de Asignar tickets recibidos por correo electrónico a soporte Nivel 1 lo cual explica cómo se realizaron las asignaciones. En este ejemplo, si se invierte el orden de los dos disparadores el conflicto desaparece.

El objetivo de este ejemplo es demostrar lo importante que es tener cuidado con todos los disparadores en su cuenta de Zendesk para asegurarse de que no se vayan a crear conflictos y que su flujo de trabajo funcione como es debido. En algunos casos, el problema de la secuencia de los disparadores se resuelve cambiando el orden de los disparadores; sin embargo, en otros casos en lugar de eso tendrá que modificar o desactivar los disparadores.

Entonces, si desea conseguir lo que ambos disparadores están tratando de conseguir sin que surja un conflicto entre ellos, tendrá que seguir un método un poco distinto. El objetivo es asignar los tickets recibidos por correo electrónico al grupo de soporte Nivel 1 a menos que sean de alguno de sus clientes-banco, en cuyo caso esos tickets serían asignados al grupo de soporte Nivel 2. Para ello, de todas maneras necesita los dos disparadores, pero se debe agregar una condición al disparador Nivel 1 que verifique que las etiquetas de la organización del solicitante no sean de uno de esos bancos, ya que eso es lo que estamos usando en el disparador Nivel 2 (cima u oriental).

En el primer disparador, que tiene que venir antes del segundo, los tickets enviados por correo electrónico que no tengan una etiqueta del cliente-banco (es decir, cima u oriental) son asignados al grupo de soporte Nivel 1 como debe ser. El segundo disparador, que viene después del primero, asigna entonces los tickets de los clientes-banco al grupo Nivel 2, en función de las etiquetas de organización que fueron agregadas a los tickets automáticamente cuando se crearon.

El siguiente es un ejemplo del orden en la página de disparadores en Zendesk que muestra el orden correcto de los disparadores.

Esperamos que estos ejemplos puedan dar una buena idea de cómo los disparadores interactúan entre sí y lo importante que es asegurarse de que al crear un disparador hay que tomar en cuenta todos los demás disparadores; que hay que considerar el orden que siguen; y que siempre hay que tener condiciones específicas para actuar en tickets específicos.

Cuando el número de disparadores es considerable y el volumen de tickets es alto, las ineficiencias en la manera de crear los disparadores pueden repercutir en la velocidad de procesamiento de sus tickets y la eficacia de sus agentes.