Escalonamento com IA do Zendesk para o Jira: triagem de bugs, sem duplicatas e o ciclo fechado

O ciclo de escalonamento tem quatro tarefas

Eu construo integrações na eesel, e o padrão Zendesk mais Jira aparece o tempo todo em chamadas de vendas. Uma rede de mídia digital dos EUA que lida com cerca de 1.000 tickets do Zendesk por semana descreveu o workflow que queria quase palavra por palavra: o usuário contata o suporte, a IA soluciona o problema e tudo o que não for resolvido é escalonado para o Jira. Parece uma etapa só. Na prática são quatro, e cada ferramenta do mercado cobre um subconjunto diferente.

As tarefas 2 e 4 são onde a maioria das configurações vaza. Pule a eliminação de duplicatas e a engenharia recebe cinco cópias do mesmo bug, cada uma com um quinto do impacto nos clientes. Pule o acompanhamento e a correção é lançada enquanto o cliente ainda acha que ninguém o ouviu. Um desenvolvedor no Hacker News descreveu a peça que falta sem rodeios:

"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."

buro9, Hacker News

Se você está começando nesse assunto, meus guias sobre o processo de escalonamento de tickets e a triagem de tickets cobrem o básico, e as boas práticas de suporte para SaaS cobrem o workflow mais amplo. Este post é sobre quem, ou o quê, faz cada uma das quatro tarefas em uma stack de Zendesk mais Jira.

O que o app nativo do Jira para Zendesk faz

A integração nativa é a base, e ela é boa naquilo para que foi criada. Expliquei a configuração passo a passo no meu guia da integração do Zendesk com o Jira, então aqui vou me limitar a como ela se encaixa nas quatro tarefas.

Criar e vincular (tarefa 3). A partir do app da barra lateral do Jira em um ticket, um agente pode criar uma issue ou vincular uma existente. Meus guias sobre criar issues a partir de tickets e vincular tickets a issues mostram os dois fluxos. A vinculação aceita a chave da issue, um link colado ou uma pesquisa por palavra-chave ou JQL que sugere issues enquanto você digita. Uma única issue do Jira pode ser vinculada a até 200 tickets. Criar ou vincular adiciona uma tag jira_escalated ao ticket e um rótulo correspondente à issue, e qualquer tag de ticket que comece com jira_ é copiada como rótulo.

Eliminar duplicatas (tarefa 2). Essa pesquisa por palavra-chave é a ferramenta de eliminação de duplicatas, e ela é manual. O agente precisa se lembrar de pesquisar, escolher as palavras certas e julgar se um resultado é mesmo o mesmo bug. Em uma fila movimentada, essa é a etapa que as pessoas pulam.

Fechar o ciclo (tarefa 4). Esta parte é mais capaz do que a maioria imagina. O artigo sobre mudança de status do Zendesk explica que a integração adiciona uma post function "Notify Zendesk Support" aos workflows do Jira. Coloque-a em uma transição e ela pode mudar o status do ticket, adicionar um comentário interno ou público e adicionar tags, com placeholders como {{issue.key}}. O próprio exemplo do Zendesk é a versão 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."

Zendesk help center

Você pode tornar esse comentário público, mas é um modelo por transição. Todos os clientes vinculados recebem o mesmo texto, não importa o que perguntaram originalmente nem em que idioma escreveram. A documentação também observa que as post functions não conseguem resolver tickets com campos obrigatórios vazios, e que remover tags não é suportado. Configurar isso significa editar e republicar um workflow do Jira, o que normalmente exige um administrador do Jira.

Triagem (tarefa 1). Fora do escopo. O app não faz nada até que um agente decida que um ticket é um bug.

Ele funciona em todos os planos do Zendesk Suite e no Support Team ou superior, com Jira Cloud e Data Center, e você precisa de permissões de administrador nas duas ferramentas para instalá-lo.

A reviravolta do app em 2026

Uma coisa para saber antes de instalar: o app que você recebe é o original. Em 28 de abril de 2026, o Zendesk anunciou que estava retirando o app mais novo do Jira do marketplace e recolocando a versão original, depois que clientes acharam a migração "confusa" e ela "poderia causar problemas durante a configuração ou a transição". Os clientes que já estão na v2 continuam nela por enquanto. O Zendesk diz que vai trabalhar com a Atlassian para trazer os recursos mais novos para o app original "nos próximos meses". Então, se um post de blog mostrar uma tela da v2 que você não encontra, é por isso.

O que o Zendesk AI acrescenta

A stack de IA do Zendesk, da triagem inteligente aos agentes de IA, toca o ciclo em três pontos. Cada um é real, e cada um para antes da verificação de duplicatas.

A triagem inteligente rotula o ticket

A triagem inteligente classifica novos tickets por tópico, sentimento, idioma e entidades como nomes de produtos. A classificação se baseia no "assunto do ticket e no texto do primeiro comentário público", e cada campo vem com uma pontuação de confiança. Você pode adicionar tópicos personalizados, então um tópico "Bug report" é algo que você mesmo pode definir. O sentimento também pode sinalizar os relatórios de bugs mais irritados, como explico em análise de sentimento no Zendesk.

O porém está nos planos. As classificações aparecem no Suite e no Support Professional ou superior, mas "usá-las em workflows exige o complemento Copilot", que a página de preços do Zendesk lista a US$ 50 por agente por mês com cobrança anual. Triggers que roteiam com base no tópico são um recurso do Copilot. Comparo as opções no meu guia de triagem de tickets com Zendesk AI, e o post sobre o complemento Copilot detalha o que mais os US$ 50 compram.

O rótulo também vive só no Zendesk. A triagem pode dizer que um ticket parece um bug, mas não sabe se o Jira já tem esse bug.

Tickets semelhantes olham dentro do Zendesk

O Copilot também inclui "Similar tickets" (tickets semelhantes) e "Merging suggestions" (sugestões de mesclagem). Os dois olham para outros tickets do Zendesk, e as sugestões de mesclagem só cobrem o mesmo solicitante em um intervalo de duas semanas para cada lado, segundo a tabela de preços. Eles são úteis para mesclar conversas duplicadas, mas não pesquisam no Jira.

Os action flows podem criar a issue

Esta é a peça que a maioria das pessoas deixa passar. O action builder do Zendesk tem um conector nativo do Jira no Suite Growth ou superior e no Support Team ou superior, com quatro ações: criar issue, obter issue, editar issue e fazer a transição da issue. Os exemplos do próprio Zendesk incluem criar issues no Jira para bugs relatados em tickets e verificar o status de uma issue antes de fechar um ticket.

Dois detalhes importam para o escalonamento. Primeiro, não há ação de pesquisa, então um flow consegue ler uma issue cuja chave já conhece, mas não consegue procurar uma. Uma verificação de duplicatas significa construir você mesmo uma ação personalizada contra a API de pesquisa do Jira. Segundo, toda ação do Jira é atribuída a quem conectou a conta, então o Zendesk recomenda uma conta de serviço dedicada.

A Atlassian tem a própria IA no lado do Jira, que abordo em criação de tickets com IA no Jira, mas ela trabalha a partir do Jira, não da sua fila do Zendesk.

Há também uma receita de workflow do Copilot em que o auto assist guia um agente pela solução do problema e depois cria uma issue no Jira por meio de uma ação personalizada. Ela exige o complemento Copilot, um cliente OAuth do Jira e um procedimento escrito. Aprofundo esse lado em ações do auto assist do Zendesk.

Onde cada opção para

Aqui está de novo o ciclo das quatro tarefas, com o que cada opção cobre de fábrica segundo a própria documentação.

Em resumo, o app nativo tem a melhor vinculação, o Zendesk AI tem os melhores rótulos dentro do produto, e nenhum dos dois verifica o Jira por você. Essa verificação de duplicatas, mais um acompanhamento escrito para cada cliente, é a parte que eu entregaria a um colega de equipe de IA.

Como um colega de equipe de IA conduz o ciclo

Quando digo colega de equipe de IA, quero dizer um agente que trabalha nas duas ferramentas como um engenheiro de suporte faria. A eesel se conecta ao Zendesk e ao Jira com integrações separadas e segue instruções que você escreve em linguagem simples. Aqui está a configuração que eu montaria para uma equipe de SaaS, usando apenas ações listadas na documentação da eesel sobre o Jira e na documentação sobre o Zendesk.

Passo 1: conecte o Zendesk e o Jira

Conecte o Zendesk com uma conexão completa, para que o agente possa ler sua central de ajuda, suas macros e seus tickets anteriores e agir nos tickets. Depois conecte o Jira com seu subdomínio da Atlassian, um e-mail de conta e um token de API. Não há app do Marketplace para instalar no lado do Jira.

Duas observações práticas. O agente vê apenas os projetos do Jira que a conta do token consegue ver, então use uma conta com acesso aos seus projetos de bugs. E a Atlassian define uma data de expiração para os tokens de API, então coloque um lembrete na agenda para reconectar. Se a documentação do seu produto fica no Confluence, conecte-o também, já que o Confluence é onde o agente vai procurar problemas conhecidos e soluções alternativas.

Passo 2: faça a triagem na primeira mensagem

Crie uma automação no trigger do Zendesk "Only on the customer's first message" (somente na primeira mensagem do cliente). Se você já criou triggers do Zendesk, pense nele como um que entrega o ticket a um agente capaz de lê-lo. A documentação da eesel o descreve como o trigger para triagem e roteamento. Ele dispara uma vez por ticket, antes que alguém tenha respondido. No Zendesk, você também pode segurar cada evento por até 15 minutos para que seus próprios triggers do Zendesk rodem primeiro.

As instruções fazem a triagem. Algo como: "Se o ticket for uma dúvida de uso ou de cobrança, responda com base na central de ajuda como rascunho para revisão. Se ele descrever o produto fazendo algo errado, trate como um possível bug: peça os detalhes de reprodução que faltarem e depois execute as etapas do Jira abaixo." Como o agente lê seus tickets anteriores e sua documentação, ele consegue distinguir "a exportação está desativada no plano Free" (funcionando como previsto) de "a exportação expira em arquivos acima de 10 MB" (um bug). Esse é um julgamento com que regras de palavra-chave e um único rótulo de tópico têm dificuldade. Meu guia sobre automatizar a triagem de tickets mostra como escrever essas regras.

Um limite a considerar no desenho: a primeira verificação da eesel não enxerga campos personalizados de ticket do Zendesk nem o e-mail do solicitante. Se um campo como o nível do plano importa, adicione um trigger do Zendesk que o transforme em tag e escreva a instrução com base na tag.

Passo 3: pesquise no Jira antes de criar qualquer coisa

Esta é a etapa que impede as duplicatas. A integração da eesel com o Jira inclui Search Issues, que executa uma consulta JQL, e Get Issue, que lê uma issue pela chave. A instrução é simples: pesquise primeiro, crie depois.

project = BUG AND statusCategory != Done AND text ~ "export timeout"

O agente escreve a consulta a partir do ticket, então pode tentar as palavras do cliente e os nomes que o próprio produto dá ao recurso. A referência de JQL da Atlassian cobre o operador de texto ~. Então ele segue um de dois caminhos:

• Existe uma correspondência. O agente comenta na issue do Jira com o link do ticket e um resumo de uma linha do caso do cliente. Ele marca o ticket do Zendesk com a chave da issue, por exemplo jira-bug-1432, e deixa uma nota interna para o agente.
• Nenhuma correspondência. O agente cria a issue com projeto, resumo, descrição, rótulos e responsável, e depois marca o ticket da mesma forma. Diga a ele para adicionar um rótulo zendesk a toda issue que criar ou comentar, para que a etapa de fechar o ciclo abaixo consiga encontrá-las. Atribuir pelo nome funciona porque ele procura a pessoa primeiro.

Alguns detalhes da documentação da eesel moldam como eu escreveria essas instruções. Update Issue substitui a descrição de uma issue por inteiro, então diga ao agente para adicionar o impacto como comentário, nunca editando a descrição. Em projetos do Jira que não são do Jira Service Management, todo comentário fica visível para qualquer pessoa que consiga ver a issue, o que não é problema em um projeto interno de bugs, mas vale saber. E a eesel não consegue alterar os vínculos nem os observadores de issues do Jira, e é por isso que a tag do Zendesk é o vínculo.

Esse último ponto tem um lado prático positivo. Como o vínculo é uma tag simples, ele aparece nas visualizações e nos relatórios do Zendesk. Os engenheiros também conseguem ver quantos clientes estão esperando pelos comentários na issue, o que importa quando, como descreveu um engenheiro no Hacker News, eles não têm licenças do 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."

hiyer, Hacker News

Passo 4: feche o ciclo quando a issue avançar

Aqui vou ser preciso. Os triggers do Jira da eesel disparam quando uma issue do Jira Service Management é criada ou recebe um comentário. Uma mudança de status em um bug do Jira Software não desperta o agente por si só. Há duas formas de fechar essa lacuna.

Opção A: uma regra de automação do Jira mais um webhook da eesel. Se a automação do Jira é novidade para você, este é o uso mais comum dela. Crie uma automação por webhook na eesel, que lhe dá uma URL privada. No Jira, adicione uma regra de automação em "Issue transitioned" (issue com transição) com uma ação "Send web request" (enviar requisição web) que envia a chave da issue e o novo status para essa URL. As instruções da eesel: "Pesquise no Zendesk os tickets abertos marcados com a chave desta issue. Para cada um, redija uma resposta dizendo ao cliente o que mudou, no idioma dele, fazendo referência ao que ele relatou originalmente."

Opção B: um agendamento. Se você prefere não mexer na automação do Jira, um agendamento pode rodar a cada 10 minutos, no mínimo, e perguntar ao Jira o que mudou:

labels = zendesk AND status CHANGED AFTER -15m

Eu escolheria a opção A para a maioria das equipes. Ela reage na própria transição. Cada entrega que o seu agente processa conta como uma execução, mas uma entrega que suas instruções filtram não é cobrada. A automação do Jira não é gratuita, porém. A Atlassian agora mede as etapas de automação, e cada trigger, condição e ação conta. A página de preços do Jira lista 150 etapas por mês no Free, 400 por usuário no Standard e 750 por usuário no Premium. Uma regra de duas etapas em um projeto de bugs movimentado cabe com folga no Standard e pode esgotar no Free. Meu post sobre se a automação do Jira é gratuita tem os detalhes.

De qualquer forma, é na resposta que a IA se paga em relação a um modelo. Um cliente que relatou um timeout na exportação de CSV fica sabendo que a correção da exportação foi lançada, e um que perguntou sobre uma solução alternativa também recebe essa resposta. Comece com "Draft ticket reply" (rascunho de resposta ao ticket), que segura cada resposta até que uma pessoa a aprove, e passe para o envio quando você confiar nela.

Salvaguardas antes de deixá-la criar issues

Uma IA que consegue criar issues no Jira também consegue criar ruído no backlog de engenharia, e os engenheiros percebem rápido. Veja como eu faria a implantação.

1. Faça a criação de issues pedir aprovação primeiro. As ações e aprovações da eesel permitem configurar cada ação para rodar sozinha, pedir aprovação primeiro ou ficar desligada. Configure Create Issue para pedir aprovação primeiro e aprove pelo painel ou pelo Slack nas primeiras semanas.
2. Reproduza o histórico antes de entrar no ar. A skill de simulação do helpdesk reproduz tickets anteriores e pontua as respostas do agente em comparação com o que sua equipe de fato enviou. Rode-a em um mês de tickets que foram escalonados e confira o que ela teria criado.
3. Dê um modelo à engenharia. Coloque seu modelo de bug nas instruções: passos para reproduzir, resultado esperado versus real, plano, navegador, número de clientes afetados. Uma issue que chega completa é assumida mais rápido do que um ticket colado.
4. Leia o log de Activity. Cada execução mostra o que o agente pesquisou, quais ações tomou, quem as aprovou e por quê.

Para mais sobre o lado da transferência, meus posts sobre escalonamento com IA e regras de escalonamento do Zendesk AI vão mais a fundo. Se os escalonamentos também vão para pessoas em vez do Jira, veja escalonar para um especialista.

Quanto custa

As três opções cobram em unidades diferentes, então aqui vai um exemplo calculado. Pegue uma equipe de SaaS com 10 agentes no Zendesk Suite Professional, recebendo 1.500 novos tickets por mês, dos quais cerca de 100 acabam sendo bugs.

Algumas observações sobre esses números. Os preços do Zendesk vêm da página de preços dele: o Suite Professional custa US$ 115 por agente por mês com cobrança anual, e os créditos de ação estão incluídos em todos os planos, com mais a US$ 200 por 100 mil. Os preços da eesel são um lote mensal fixo de créditos, sem cobrança por licença. Um ticket é um crédito, não importa quantas etapas ele exija, as entregas de webhook contam como execuções e os créditos extras custam US$ 0,80 cada se você ativar o excedente. Neste exemplo, 1.600 execuções ficam um pouco acima do plano de 1.500, então o plano de US$ 999 ou US$ 80 de excedente cobrem.

O Copilot faz mais do que triagem, incluindo auto assist e ferramentas de escrita, então não é uma troca equivalente. A precificação baseada em resultados do Zendesk para agentes de IA é mais um medidor separado. Se você já paga por ele, o caminho mais barato costuma ser o Copilot para os rótulos mais um colega de equipe de IA para a ida e volta com o Jira. Minha calculadora de preços do Zendesk AI ajuda no lado do Zendesk, e o guia de preços do Jira cobre o da Atlassian.

Qual configuração eu escolheria

Veja onde o seu ciclo quebra hoje, e a configuração certa geralmente se escolhe sozinha.

Em resumo:

1. Poucos bugs, e os agentes já escalonam bem. Fique no app nativo e adicione a post function Notify Zendesk Support. É gratuito e é suficiente.
2. Você já paga pelo Copilot. Use a triagem inteligente para o rótulo de bug e um action flow para criar a issue. Aceite que a eliminação de duplicatas continua manual, ou construa uma ação de pesquisa personalizada.
3. Duplicatas e correções silenciosas são a dor real. Adicione um colega de equipe de IA para as tarefas 2 e 4. Você pode manter o app nativo para os agentes que gostam da barra lateral.
4. Você é uma pequena equipe de SaaS sem um administrador do Jira disponível. Um colega de equipe de IA com agendamento evita editar workflows do Jira por completo.

Para mais opções nesse espaço, veja minha seleção de IA para triagem de relatórios de bugs e a lista das melhores IAs para triagem de tickets. O guia de roteamento de tickets com IA para SaaS cobre o roteamento além dos bugs.

Se os seus bugs chegam por uma central de serviços do Jira, agentes de IA para Jira é o melhor ponto de partida.

A eesel para Zendesk e Jira

Se as tarefas 2 e 4 são onde a sua equipe perde tempo, esse é o trabalho para o qual a eesel foi feita. Ela é uma colega de equipe de IA para helpdesk que entra no Zendesk, aprende com sua central de ajuda, suas macros e seus tickets anteriores e redige ou envia respostas, aplica tags e roteia. Com o Jira conectado, ela procura uma issue existente antes de criar uma e redige a atualização de cada cliente quando a issue avança.

Você a configura conversando com ela, e cada ação pode esperar sua aprovação até que você confie nela. Experimente a eesel grátis com 100 créditos e sem cartão. Rode-a no seu último mês de tickets escalonados e veja o que ela teria criado. Se você ainda está comparando, a seleção de alternativas ao Zendesk AI e eesel vs Zendesk AI são boas próximas leituras.