Escalado con IA de Zendesk a Jira: clasifica bugs, evita duplicados y cierra el ciclo
Rama Adi
Katelin Teen
Última edición September 30, 2026
El ciclo de escalado tiene cuatro tareas
Construyo integraciones en eesel, y el patrón Zendesk más Jira sale constantemente en las llamadas de ventas. Una red de medios digitales de EE. UU. que gestiona unos 1.000 tickets de Zendesk a la semana describió el flujo que quería casi palabra por palabra: el usuario contacta con soporte, la IA intenta resolver el problema y todo lo que queda sin resolver se escala a Jira. Parece un solo paso. En la práctica son cuatro, y cada herramienta del mercado cubre un subconjunto distinto.
| Tarea | Qué significa | Quién suele hacerla hoy |
|---|---|---|
| 1. Clasificar | ¿Es una pregunta de uso, un problema de cuenta o un bug real del producto? | Un agente que lee el ticket |
| 2. Evitar duplicados | ¿Ya existe una incidencia de Jira para este bug? | Un agente que busca en Jira, o nadie |
| 3. Crear o vincular | Crear la incidencia con los pasos para reproducirla, o adjuntar este ticket a la existente | Un agente en la app lateral de Jira |
| 4. Cerrar el ciclo | Avisar al cliente cuando la incidencia se arregla o cambia de estado | Quien se acuerde |
Las tareas 2 y 4 son donde falla la mayoría de las configuraciones. Si te saltas la comprobación de duplicados, ingeniería recibe cinco copias del mismo bug, cada una con una quinta parte del impacto en clientes. Si te saltas el seguimiento, el arreglo se publica mientras el cliente sigue pensando que nadie le escuchó. Un desarrollador en Hacker News describió la pieza que falta sin rodeos:
"A bug tracker by itself... doesn't feel as valuable as the integration that enables the smooth management of a bug for all those who interact with it."
Si esto es nuevo para ti, mis guías sobre el proceso de escalado de tickets y la clasificación de tickets cubren lo básico, y buenas prácticas de soporte SaaS cubre el flujo de trabajo más amplio. Este artículo trata de quién, o qué, hace cada una de las cuatro tareas en un stack de Zendesk más Jira.
Qué hace la app nativa de Jira para Zendesk
La integración nativa es el punto de partida, y hace bien aquello para lo que se creó. Expliqué la configuración paso a paso en mi guía sobre la integración de Zendesk con Jira, así que aquí me centraré en cómo encaja con las cuatro tareas.
Crear y vincular (tarea 3). Desde la app lateral de Jira en un ticket, un agente puede crear una incidencia o vincular una existente. Mis guías sobre crear incidencias desde tickets y vincular tickets a incidencias muestran ambos flujos. Para vincular se usa una clave de incidencia, un enlace pegado o una búsqueda por palabra clave o JQL que sugiere incidencias mientras escribes. Una sola incidencia de Jira puede vincularse a hasta 200 tickets. Crear o vincular añade una etiqueta jira_escalated al ticket y una etiqueta equivalente a la incidencia, y cualquier etiqueta del ticket que empiece por jira_ se copia como etiqueta en Jira.
Evitar duplicados (tarea 2). Esa búsqueda por palabra clave es la herramienta para evitar duplicados, y es manual. El agente tiene que acordarse de buscar, elegir las palabras correctas y juzgar si un resultado es de verdad el mismo bug. En una cola con mucho volumen, ese es el paso que la gente se salta.
Cerrar el ciclo (tarea 4). Esta parte es más capaz de lo que la mayoría cree. El artículo de Zendesk sobre cambios de estado explica que la integración añade una post function "Notify Zendesk Support" a los flujos de trabajo de Jira. Si la pones en una transición, puede cambiar el estado del ticket, añadir un comentario interno o público y añadir etiquetas, con marcadores como {{issue.key}}. El ejemplo de la propia Zendesk es la versión conservadora:
"For example, after an engineer changes the Jira workflow status of an issue from "In progress" to "Done," Jira can automatically add an internal note to the linked Zendesk ticket notifying the agent. The agent can then notify the customer."
Puedes hacer público ese comentario, pero es una plantilla por transición. Todos los clientes vinculados reciben el mismo texto, sea lo que sea lo que preguntaron y en el idioma en que escribieran. La documentación también indica que las post functions no pueden resolver tickets con campos obligatorios vacíos, y que eliminar etiquetas no está soportado. Configurarlo implica editar y volver a publicar un flujo de trabajo de Jira, lo que normalmente requiere un administrador de Jira.
Clasificar (tarea 1). Queda fuera de su alcance. La app no hace nada hasta que un agente decide que un ticket es un bug.
Funciona en todos los planes de Zendesk Suite y en Support Team y superiores, con Jira Cloud y Data Center, y necesitas permisos de administrador en ambas herramientas para instalarla.
El cambio de rumbo de la app en 2026
Una cosa que conviene saber antes de instalar: la app que obtienes es la original. El 28 de abril de 2026, Zendesk anunció que retiraba la app de Jira más nueva y volvía a publicar la versión original, después de que los clientes encontraran la migración "confusa" y de que "podría provocar problemas durante la configuración o la transición". Los clientes que ya usan la v2 se quedan en ella por ahora. Zendesk dice que trabajará con Atlassian para incorporar las funciones nuevas a la app original "en los próximos meses". Así que si un artículo te muestra una pantalla de la v2 que no encuentras, ese es el motivo.
Qué añade Zendesk AI por encima
El stack de IA de Zendesk, desde el intelligent triage hasta los agentes de IA, toca el ciclo en tres puntos. Cada uno es real, y cada uno se queda corto antes de la comprobación de duplicados.
Intelligent triage etiqueta el ticket
Intelligent triage clasifica los tickets nuevos por tema, sentimiento, idioma y entidades como nombres de producto. La clasificación se basa en "el asunto del ticket y el texto del primer comentario público", y cada campo viene con una puntuación de confianza. Puedes añadir temas personalizados, así que un tema "Bug report" es algo que puedes definir tú mismo. El sentimiento también puede marcar los informes de bugs más enfadados, como explico en análisis de sentimiento en Zendesk.
La pega está en el plan. Las clasificaciones aparecen en Suite y en Support Professional y superiores, pero "usarlas en flujos de trabajo requiere el complemento Copilot", que la página de precios de Zendesk sitúa en 50 $ por agente al mes con facturación anual. Los disparadores que enrutan según el tema son una función de Copilot. Comparo las opciones en mi guía de clasificación de tickets con Zendesk AI, y el artículo sobre el complemento Copilot desglosa qué más compran esos 50 $.
Además, la etiqueta solo vive en Zendesk. El triage puede decirte que un ticket parece un bug, pero no sabe si Jira ya tiene ese bug.
Similar tickets busca dentro de Zendesk
Copilot también incluye "Similar tickets" (tickets similares) y "Merging suggestions" (sugerencias de fusión). Ambas miran otros tickets de Zendesk, y las sugerencias de fusión solo cubren al mismo solicitante dentro de un margen de dos semanas antes o después, según la tabla de precios. Son útiles para fusionar conversaciones duplicadas, pero no buscan en Jira.
Los action flows pueden crear la incidencia
Esta es la pieza que la mayoría pasa por alto. El action builder de Zendesk tiene un conector de Jira integrado en Suite Growth y superiores y en Support Team y superiores, con cuatro acciones: crear incidencia, obtener incidencia, editar incidencia y transicionar incidencia. Los ejemplos de la propia Zendesk incluyen crear incidencias de Jira para bugs notificados en tickets y comprobar el estado de una incidencia antes de cerrar un ticket.
Dos detalles importan para el escalado. Primero, no hay acción de búsqueda, así que un flujo puede leer una incidencia cuya clave ya conoce, pero no puede buscar una. Comprobar duplicados implica construir tú mismo una acción personalizada contra la API de búsqueda de Jira. Segundo, cada acción de Jira se atribuye a quien conectó la cuenta, así que Zendesk recomienda una cuenta de servicio dedicada.
Atlassian tiene su propia IA en el lado de Jira, que explico en creación de tickets con IA en Jira, pero trabaja desde Jira, no desde tu cola de Zendesk.
También hay una receta de flujo de trabajo de Copilot en la que auto assist guía a un agente en la resolución de problemas y luego crea una incidencia de Jira mediante una acción personalizada. Requiere el complemento Copilot, un cliente OAuth de Jira y un procedimiento escrito. Profundizo en esa parte en acciones de auto assist en Zendesk.
Dónde se detiene cada opción
Este es de nuevo el ciclo de cuatro tareas, con lo que cubre cada opción de serie según su propia documentación.
| App nativa de Jira | Zendesk AI (Copilot + action flows) | Compañero de IA eesel | |
|---|---|---|---|
| 1. Clasificar bug o pregunta | Decide el agente | Tema de intelligent triage, usado en flujos de trabajo con Copilot | Lee cada ticket nuevo según tus instrucciones y tu conocimiento |
| 2. Buscar en Jira una incidencia existente | El agente hace una búsqueda por palabra clave o JQL | Sin acción de búsqueda; hace falta una acción personalizada | Búsqueda JQL antes de crear |
| 3. Crear o vincular | Crear o vincular desde la app lateral, hasta 200 tickets por incidencia | Paso de crear incidencia en un action flow | Crea la incidencia o comenta en la existente; la clave se guarda como etiqueta de Zendesk |
| 4. Avisar al cliente | Comentario con plantilla desde una post function de Jira | Pasos de transicionar y obtener; sin detector de cambios de estado integrado | Una regla de Jira o una programación lo activa para redactar o enviar cada actualización |
| Aparece en la app lateral de Jira | Sí, vínculo nativo | Solo si también usas la app | No, registra los vínculos como etiquetas y comentarios |
| Coste adicional | Ninguno aparte del plan de Zendesk | 50 $/agente/mes por Copilot; action flows en Suite Growth+ | Desde 299 $/mes por 500 créditos |
En resumen, la app nativa tiene la mejor vinculación, Zendesk AI tiene las mejores etiquetas dentro del producto, y ninguna de las dos busca en Jira por ti. Esa comprobación de duplicados, más un seguimiento redactado para cada cliente, es la parte que yo le daría a un compañero de IA.
Cómo gestiona el ciclo un compañero de IA
Cuando digo compañero de IA, me refiero a un agente que trabaja en ambas herramientas como lo haría un ingeniero de soporte. eesel se conecta a Zendesk y a Jira con integraciones separadas y sigue instrucciones que escribes en lenguaje natural. Esta es la configuración que montaría para un equipo SaaS, usando solo acciones que aparecen en la documentación de Jira de eesel y en la documentación de Zendesk.
Paso 1: conecta Zendesk y Jira
Conecta Zendesk con una conexión completa, para que el agente pueda leer tu centro de ayuda, tus macros y tus tickets anteriores, y actuar sobre los tickets. Después conecta Jira con tu subdominio de Atlassian, un email de cuenta y un token de API. No hay ninguna app del Marketplace que instalar en el lado de Jira.

Dos notas prácticas. El agente solo ve los proyectos de Jira que puede ver la cuenta del token, así que usa una cuenta con acceso a tus proyectos de bugs. Y Atlassian pone fecha de caducidad a los tokens de API, así que apúntate un recordatorio en el calendario para volver a conectar. Si la documentación de tu producto vive en Confluence, conéctalo también, porque Confluence es donde el agente buscará problemas conocidos y soluciones temporales.
Paso 2: clasifica en el primer mensaje
Crea una automatización con el disparador de Zendesk "Only on the customer's first message" (solo en el primer mensaje del cliente). Si ya has creado disparadores de Zendesk, piensa en él como uno que pasa el ticket a un agente capaz de leerlo. La documentación de eesel lo describe como el disparador para clasificar y enrutar. Se dispara una vez por ticket, antes de que nadie haya respondido. En Zendesk también puedes retener cada evento hasta 15 minutos para que tus propios disparadores de Zendesk se ejecuten primero.

Las instrucciones hacen la clasificación. Algo como: "Si el ticket es una pregunta de uso o de facturación, respóndela desde el centro de ayuda como borrador para revisión. Si describe que el producto hace algo mal, trátalo como un posible bug: pide los detalles que falten para reproducirlo y luego ejecuta los pasos de Jira de abajo." Como el agente lee tus tickets anteriores y tu documentación, puede distinguir "la exportación aparece en gris en el plan Free" (funciona como está previsto) de "la exportación se agota por tiempo con archivos de más de 10 MB" (un bug). Ese es un juicio que a las reglas por palabra clave y a una sola etiqueta de tema les cuesta hacer. Mi guía sobre cómo automatizar la clasificación de tickets explica cómo escribir esas reglas.
Un límite a tener en cuenta en el diseño: la primera comprobación de eesel no puede ver los campos personalizados de los tickets de Zendesk ni el email del solicitante. Si un campo como el nivel de plan importa, añade un disparador de Zendesk que lo convierta en una etiqueta y escribe la instrucción en función de la etiqueta.
Paso 3: busca en Jira antes de crear nada
Este es el paso que frena los duplicados. La integración de Jira de eesel incluye Search Issues, que ejecuta una consulta JQL, y Get Issue, que lee una incidencia por su clave. La instrucción es sencilla: primero buscar, después crear.
project = BUG AND statusCategory != Done AND text ~ "export timeout"
El agente escribe la consulta a partir del ticket, así que puede probar con las palabras del cliente y con los nombres que el propio producto da a la función. La referencia de JQL de Atlassian cubre el operador de texto ~. Después se bifurca:
- Existe una coincidencia. El agente comenta en la incidencia de Jira con el enlace al ticket y un resumen de una línea del caso del cliente. Etiqueta el ticket de Zendesk con la clave de la incidencia, por ejemplo
jira-bug-1432, y deja una nota interna para el agente. - No hay coincidencia. El agente crea la incidencia con proyecto, resumen, descripción, etiquetas y persona asignada, y luego etiqueta el ticket de la misma forma. Pídele que añada una etiqueta
zendeska cada incidencia que cree o en la que comente, para que el paso de cerrar el ciclo de más abajo pueda encontrarlas. Asignar por nombre funciona porque primero busca a la persona.
Algunos detalles de la documentación de eesel condicionan cómo escribiría esas instrucciones. Update Issue sustituye por completo la descripción de una incidencia, así que dile al agente que añada el impacto como comentario, nunca editando la descripción. En proyectos de Jira que no son de Jira Service Management, cada comentario es visible para cualquiera que pueda ver la incidencia, lo que está bien para un proyecto interno de bugs, pero conviene saberlo. Y eesel no puede cambiar los vínculos ni los observadores de las incidencias de Jira, por eso la etiqueta de Zendesk hace de vínculo.
Eso último tiene una ventaja práctica. Como el vínculo es una simple etiqueta, aparece en las vistas y los informes de Zendesk. Los ingenieros también pueden ver cuántos clientes están esperando a partir de los comentarios de la incidencia, lo que importa cuando, como describió un ingeniero en Hacker News, no tienen licencias de Zendesk:
"However pricing is definitely an issue - at both these companies us engineers did not have individual zendesk accounts as it was deemed too expensive. So we couldn't check the ticket ourselves for details. Jira-zendesk integration mitigated this to some extent though."
Paso 4: cierra el ciclo cuando la incidencia avance
Aquí voy a ser preciso. Los disparadores de Jira de eesel se activan cuando se crea o se comenta una incidencia de Jira Service Management. Un cambio de estado en un bug de Jira Software no activa al agente por sí solo. Hay dos formas de cubrir ese hueco.
Opción A: una regla de automatización de Jira más un webhook de eesel. Si la automatización de Jira es nueva para ti, este es su uso más habitual. Crea una automatización por webhook en eesel, que te da una URL privada. En Jira, añade una regla de automatización con "Issue transitioned" y una acción "Send web request" que envíe la clave de la incidencia y el nuevo estado a esa URL. Las instrucciones de eesel: "Busca en Zendesk los tickets abiertos etiquetados con esta clave de incidencia. Para cada uno, redacta una respuesta que cuente al cliente qué ha cambiado, en su idioma, haciendo referencia a lo que notificó originalmente."
Opción B: una programación. Si prefieres no tocar la automatización de Jira, una programación puede ejecutarse cada 10 minutos como máximo y preguntar a Jira qué ha cambiado:
labels = zendesk AND status CHANGED AFTER -15m

Para la mayoría de los equipos elegiría la opción A. Reacciona en la propia transición. Cada entrega que procesa tu agente cuenta como una ejecución, pero una entrega que tus instrucciones filtran no se factura. Eso sí, la automatización de Jira no es gratuita. Atlassian ahora mide los pasos de automatización, y cuentan cada disparador, condición y acción. La página de precios de Jira indica 150 pasos al mes en Free, 400 por usuario en Standard y 750 por usuario en Premium. Una regla de dos pasos en un proyecto de bugs con mucho movimiento cabe de sobra en Standard y puede agotarse en Free. Mi artículo sobre si la automatización de Jira es gratuita tiene los detalles.
En cualquier caso, la respuesta es donde la IA justifica su valor frente a una plantilla. A un cliente que notificó que la exportación a CSV se agotaba por tiempo se le dice que el arreglo de la exportación ya está publicado, y al que preguntó por una solución temporal también se le responde a eso. Empieza con "Draft ticket reply" (redactar respuesta al ticket), que retiene cada respuesta hasta que una persona la aprueba, y pasa a enviar cuando confíes en él.
Salvaguardas antes de dejarle crear incidencias
Una IA que puede crear incidencias de Jira también puede llenar de ruido el backlog de ingeniería, y los ingenieros lo notan enseguida. Así lo desplegaría yo.
- Haz que crear incidencias pida permiso primero. Las acciones y aprobaciones de eesel te permiten configurar cada acción para que se ejecute sola, pregunte primero o esté desactivada. Configura Create Issue para que pregunte primero, y aprueba desde el panel o desde Slack durante las primeras semanas.
- Reproduce el historial antes de ponerlo en marcha. La skill de simulación del helpdesk reproduce tickets pasados y puntúa las respuestas del agente frente a lo que tu equipo envió de verdad. Ejecútala sobre un mes de tickets escalados y revisa qué habría creado.
- Dale a ingeniería una plantilla. Pon tu plantilla de bugs en las instrucciones: pasos para reproducirlo, resultado esperado frente a real, plan, navegador y número de clientes afectados. Una incidencia que llega completa se atiende antes que un ticket pegado.
- Lee el registro de Activity. Cada ejecución muestra qué buscó el agente, qué acciones realizó, quién las aprobó y por qué.

Para saber más sobre el traspaso, mis artículos sobre escalado con IA y reglas de escalado de Zendesk AI profundizan más. Si los escalados también van a personas en lugar de a Jira, consulta escalar a un especialista.
Cuánto cuesta
Las tres opciones facturan en unidades distintas, así que aquí va un ejemplo práctico. Pongamos un equipo SaaS con 10 agentes en Zendesk Suite Professional, que recibe 1.500 tickets nuevos al mes, de los que unos 100 resultan ser bugs.
| App nativa de Jira | Zendesk Copilot + action flows | eesel | |
|---|---|---|---|
| Unidad de facturación | Incluida en el plan | Por agente al mes | Por ticket o ejecución (1 crédito) |
| Coste mensual adicional | 0 $ | 500 $ por Copilot (10 × 50 $, facturación anual) | 699 $ por 1.500 créditos, o 999 $ por 2.500 |
| Cómo se ve el volumen | Tiempo del agente en cada escalado | Clasifica cada ticket; los pasos de Jira consumen action credits | 1.500 ejecuciones de clasificación más unas 100 de actualización de estado |
| Lado de Jira | Instalación de la app | Conexión de Jira en el action builder | Token de API; pasos de automatización si usas la opción A |
Unas notas sobre esas cifras. Los precios de Zendesk salen de su página de precios: Suite Professional cuesta 115 $ por agente al mes con facturación anual, y los action credits están incluidos en todos los planes, con más a 200 $ por cada 100.000. Los precios de eesel son un lote mensual fijo de créditos sin cuotas por licencia. Un ticket es un crédito sin importar cuántos pasos requiera, las entregas de webhook cuentan como ejecuciones y los créditos extra cuestan 0,80 $ cada uno si activas el exceso de uso. En este ejemplo, 1.600 ejecuciones quedan justo por encima del plan de 1.500, así que lo cubre el plan de 999 $ o 80 $ de exceso.
Copilot hace más que clasificar, incluidos auto assist y herramientas de redacción, así que no es un cambio equivalente. El precio basado en resultados de Zendesk para agentes de IA es otro contador aparte. Si ya pagas Copilot, el camino más barato suele ser Copilot para las etiquetas más un compañero de IA para el viaje de ida y vuelta a Jira. Mi calculadora de precios de Zendesk AI ayuda con la parte de Zendesk, y la guía de precios de Jira cubre la de Atlassian.
Qué configuración elegiría yo
Repasa dónde se rompe hoy tu ciclo, y la configuración adecuada suele elegirse sola.
En resumen:
- Pocos bugs, y los agentes ya escalan bien. Quédate con la app nativa y añade la post function Notify Zendesk Support. Es gratis y es suficiente.
- Ya pagas Copilot. Usa intelligent triage para la etiqueta de bug y un action flow para crear la incidencia. Asume que evitar duplicados seguirá siendo manual, o construye una acción de búsqueda personalizada.
- Los duplicados y los arreglos silenciosos son el verdadero problema. Añade un compañero de IA para las tareas 2 y 4. Puedes mantener la app nativa para los agentes a los que les gusta la barra lateral.
- Eres un equipo SaaS pequeño sin un administrador de Jira disponible. Un compañero de IA con una programación evita tener que editar flujos de trabajo de Jira.
Para ver más opciones en este ámbito, consulta mi recopilación de IA para clasificar informes de bugs y la lista de la mejor IA para clasificar tickets. La guía de enrutamiento de tickets con IA para SaaS cubre el enrutamiento más allá de los bugs.
Si tus bugs llegan a través de un service desk de Jira, agentes de IA para Jira es mejor punto de partida.
eesel para Zendesk y Jira
Si las tareas 2 y 4 son donde tu equipo pierde tiempo, ese es el trabajo para el que está pensado eesel. Es un compañero de IA para el helpdesk que se une a Zendesk, aprende de tu centro de ayuda, tus macros y tus tickets anteriores, y redacta o envía respuestas, etiqueta y enruta. Con Jira conectado, busca una incidencia existente antes de crear una, y redacta la actualización de cada cliente cuando la incidencia avanza.
Lo configuras chateando con él, y cada acción puede esperar tu aprobación hasta que confíes en él. Prueba eesel gratis con 100 créditos y sin tarjeta. Ejecútalo sobre tu último mes de tickets escalados y mira qué habría creado. Si todavía estás comparando, la recopilación de alternativas a Zendesk AI y eesel vs Zendesk AI son buenas lecturas para continuar.
Preguntas frecuentes
¿Puedo escalar tickets de Zendesk a Jira automáticamente?
¿Comprueba Zendesk AI si hay incidencias duplicadas en Jira?
¿Cómo aviso a un cliente de Zendesk cuando se arregla un bug de Jira?
¿Cuánto cuesta la clasificación con IA para Zendesk y Jira?
¿Es gratuita la integración de Zendesk con Jira?
¿Qué pasó con la nueva app de Jira para Zendesk en 2026?
¿Puede un agente de IA clasificar también tickets de Jira Service Management?
¿Creará un agente de IA incidencias de Jira malas si automatizo el escalado?

Article by
Rama Adi
Rama is a software engineer at eesel AI with two years of experience writing about B2B SaaS, AI tools, and customer support technology. Based in Bali, Indonesia, he brings a developer's perspective to product comparisons — cutting through marketing copy to what the integrations and APIs actually do.







