Automatización de Zendesk: triggers, automatizaciones, macros y enrutamiento

Las tres herramientas modifican tickets, pero se ponen en marcha de forma distinta. Según el propio Zendesk, la diferencia entre triggers y automatizaciones no está en qué acciones pueden realizar, sino en qué condiciones los activan. Las macros no tienen ninguna condición, porque nada evalúa el ticket automáticamente: es un agente quien decide cuándo aplicar una.

Las tres se combinan bien. Un patrón habitual es una macro que añade una etiqueta, lo que activa de inmediato un trigger que busca esa etiqueta. Ten en cuenta que una macro solo puede hacer lo que el usuario actual tiene permiso para hacer, así que un agente con permisos limitados puede no ser capaz de aplicar todos los cambios que contiene una macro.

Cada vez que se crea o actualiza un ticket, todos los triggers de tickets se ejecutan sobre él en un ciclo, en el orden de la lista. Si un trigger actualiza el ticket, el ciclo vuelve a empezar y todos los triggers se ejecutan de nuevo, salvo los que ya se han activado y han actualizado el ticket. Así, el cambio de un trigger puede hacer que se cumplan las condiciones de otro, aunque no se cumplieran un momento antes.

El orden que recomienda Zendesk para los triggers de tickets:

1. Triggers que cambian valores del ticket, como el estado, la prioridad u otros campos.
2. Triggers que asignan el ticket.
3. Triggers de notificación, al final, para que los correos y mensajes reflejen el estado final del ticket.

Si usas categorías de triggers, el orden de las categorías debe coincidir con el orden en que quieres que se ejecuten los triggers; se cambia con 'Edit order' en la lista de triggers. Usa la condición 'Ticket | Is | Created' para reglas que solo deben actuar sobre tickets nuevos (el enrutamiento es el caso clásico), y 'Ticket | Is | Updated' para cosas como las notificaciones de actualización. Los triggers de tickets no se ejecutan sobre tickets cerrados.

Las automatizaciones se ejecutan una vez cada hora sobre todos los tickets no cerrados. El momento es aproximado: una automatización empieza en algún punto dentro de la hora, no en un minuto fijo. Cada automatización puede actuar sobre un máximo de 1.000 tickets por hora, y el excedente espera a ejecuciones posteriores.

Como las automatizaciones vuelven a comprobar los mismos tickets cada hora, Zendesk exige que cada una incluya una condición que solo se cumpla una vez o una acción que anule al menos una condición. Sin ella, las condiciones siguen coincidiendo y la automatización se activa en un bucle infinito. La automatización estándar 'close ticket after solved' lo resuelve de forma natural: al cerrar el ticket, este deja de cumplir la condición 'Status is Solved'. En automatizaciones personalizadas, la solución habitual es añadir una etiqueta y excluir esa etiqueta en las condiciones.

Los triggers pueden enrutar tickets asignando un grupo, un agente o habilidades, pero Zendesk también tiene funciones de enrutamiento específicas:

• El enrutamiento omnicanal envía a los agentes tickets de correo electrónico, llamadas y mensajería según su disponibilidad y capacidad, y también puede tener en cuenta la prioridad y las habilidades.
• Los triggers pueden añadir habilidades a los tickets y marcarlas como obligatorias u opcionales. Las habilidades obligatorias limitan qué agentes son elegibles; las opcionales pueden caducar para que el ticket vuelva al modelo de enrutamiento normal.
• El enrutamiento basado en habilidades independiente es un modelo pull: los tickets se ordenan por habilidad y los agentes eligen el trabajo desde vistas basadas en habilidades. No se puede usar con tickets de voz ni de mensajería.

En las llamadas, el enrutamiento omnicanal es la única forma de que los triggers influyan en el enrutamiento, porque el ticket se crea en cuanto la llamada entra en la cola. Las funciones de enrutamiento varían según el plan, así que confirma qué incluye el tuyo antes de diseñar en torno a las habilidades.

Cuando una regla tiene que avisar a otro sistema, usa un webhook. Se crea en Admin Center y se elige su tipo de conexión: eventos de Zendesk, o trigger o automatización. Un webhook puede usar uno de los dos, no ambos, y el método de conexión no se puede cambiar después. En un trigger o una automatización, añade la acción 'Notify webhook', selecciona el webhook e introduce el payload. El cuerpo de la solicitud puede ser JSON, XML o form-encoded, y el payload no puede superar los 16.000 caracteres. Cada webhook tiene la opción 'Test webhook' para comprobar la solicitud antes de ponerlo en producción.

Cuando la lógica necesita leer datos, tomar decisiones en código o escribir de vuelta en los tickets, usa la Ticketing API. Los tickets se crean con un POST al endpoint de tickets y se actualizan con un PUT a la URL del propio ticket, con variantes masivas para muchos tickets a la vez. Las solicitudes pueden autenticarse con un token de acceso OAuth enviado en una cabecera Bearer.

Buenos candidatos para empezar a automatizar Zendesk:

• Enrutar tickets nuevos al grupo correcto según canal, formulario, idioma o palabras clave.
• Recordatorios y escalados para tickets que llevan demasiado tiempo esperando respuesta.
• Publicar tickets de alta prioridad o VIP en un canal de Slack mediante un webhook.
• Traer datos de pedidos o de la cuenta a un ticket a través de la API antes de que un agente lo abra.

TascaLab trabaja sobre tu cuenta de Zendesk actual, sin cambiar de plataforma, usando la API de Zendesk, webhooks y Make o n8n donde encajan. Ticket Routing & Categorization es un proyecto puntual de 690 €; Custom Automation, para flujos que abarcan varios sistemas, cuesta desde 1070 €. Todos los proyectos incluyen 30 días de soporte tras el lanzamiento, documentación básica y ningún coste oculto, y la mayoría de las implementaciones llevan 1–3 semanas. Puedes empezar con una llamada de Health Check gratuita de 30 minutos.