Como usar as condições de automação do Zendesk quando o responsável muda

Se você já tentou configurar um fluxo de trabalho que responda quando o responsável de um ticket muda, provavelmente encontrou um obstáculo confuso. Você cria uma automação, define o que parece ser as condições certas e nada acontece. O ticket é reatribuído, mas sua notificação nunca é enviada, seu webhook nunca é acionado e seu fluxo de trabalho permanece em silêncio.

Aqui está o problema: as automações no Zendesk não podem detectar mudanças imediatas de responsável. Elas são executadas em uma programação, verificando os tickets a cada hora para condições baseadas em tempo, como "horas desde a atribuição". Se você deseja reações instantâneas quando alguém recebe um ticket, você precisa de gatilhos, não de automações.

Este guia orienta você pelas duas ferramentas, quando usar cada uma e como construir fluxos de trabalho que realmente funcionem. Abordaremos as condições específicas de que você precisa, instruções de configuração passo a passo, casos de uso comuns e dicas de solução de problemas para quando as coisas dão errado.

Como detectar mudanças de responsável usando gatilhos do Zendesk

Agora que entendemos que os gatilhos são a ferramenta certa para a detecção imediata de responsáveis, vamos percorrer exatamente como configurá-los.

A condição "Responsável Mudou"

A condição que você precisa é direta: Ticket > Responsável > Mudou. Esta condição está documentada na referência de condições de gatilho do Zendesk.

Você encontrará isso na interface de criação de gatilhos em Admin Center > Objetos e regras > Regras de negócios > Gatilhos. Para obter mais detalhes sobre como navegar no Admin Center, consulte o guia do Zendesk para criar e gerenciar gatilhos. Ao construir sua declaração de condição, selecione "Ticket" como a categoria, "Responsável" como o campo e "Mudou" como o operador.

Esta condição detecta qualquer modificação no campo responsável. Ela é acionada quando:

• Um ticket não atribuído recebe um responsável
• Um ticket se move de um agente para outro
• Um ticket atribuído se torna não atribuído

Importante, "Mudou" detecta qualquer atualização no valor do campo, mesmo que o campo estivesse vazio anteriormente. Se um ticket é criado e atribuído imediatamente, a condição "Responsável Mudou" será acionada porque a atribuição aconteceu durante esse evento de criação.

Passo a passo: Criando um gatilho de mudança de responsável

Aqui está exatamente como construir um gatilho que responde a mudanças de responsável.

Passo 1: Acesse a página de gatilhos

Navegue até Admin Center > Objetos e regras > Regras de negócios > Gatilhos. É aqui que toda a sua automação de tickets reside.

Passo 2: Crie um novo gatilho

Clique em "Adicionar gatilho" na parte superior da página. Dê a ele um nome claro e descritivo, como "Notificar agente quando atribuído" ou "Notificação de atribuição ao responsável". Adicione uma descrição explicando o que este gatilho faz. Isso ajuda outros administradores a entender sua configuração mais tarde.

Selecione uma categoria apropriada para organização. A maioria das equipes usa "Notificações" ou cria uma categoria personalizada como "Alertas de Agente".

Passo 3: Defina as condições

Em "Atender a TODAS as seguintes condições", adicione:

1. Ticket > Responsável > Mudou
2. Ticket > Responsável > Não é > (usuário atual) (opcional, mas recomendado)

A primeira condição garante que o gatilho seja acionado sempre que a atribuição mudar. A segunda condição impede que o gatilho seja acionado quando um agente atribui um ticket a si mesmo. Quando Mike clica em "Pegar" para pegar um ticket não atribuído, ele já sabe que o tem. Ele não precisa de um e-mail dizendo a ele o que ele acabou de fazer.

Se você quiser notificações mesmo na autoatribuição, basta omitir a segunda condição.

Passo 4: Configure a ação

Em "Ações", selecione:

Notificações > Enviar e-mail para o usuário > (responsável)

Isso diz ao Zendesk para enviar um e-mail para quem aparece no campo responsável depois que as condições são atendidas.

Agora personalize o assunto e o corpo do e-mail. Aqui estão os placeholders mais úteis para notificações de atribuição:

Um bom assunto de e-mail pode ser: "Ticket #{{ticket.id}} atribuído a você: {{ticket.title}}"

Para o corpo, inclua contexto suficiente para que o agente possa entender o problema sem abrir o ticket:

Olá {{ticket.assignee.first_name}},

Você foi atribuído ao ticket #{{ticket.id}}.

Cliente: {{ticket.requester.name}}
Prioridade: {{ticket.priority}}
Assunto: {{ticket.title}}

{{ticket.description}}

Visualizar ticket: {{ticket.url}}

Passo 5: Salve e teste

Clique em "Criar" para salvar seu gatilho. Agora teste-o:

1. Crie um ticket de teste ou use um existente
2. Peça a outro agente (não você mesmo) para atribuí-lo a você
3. Verifique seu e-mail para a notificação
4. Verifique se o e-mail contém todas as informações que você configurou

Se você não receber o e-mail em alguns minutos, verifique sua pasta de spam e verifique se seu perfil de agente tem notificações por e-mail ativadas.

Casos de uso comuns para gatilhos de mudança de responsável

Depois de entender a configuração básica, você pode adaptá-la para vários fluxos de trabalho. Aqui estão os cenários mais comuns em que os gatilhos de mudança de responsável agregam valor.

Notificações de atribuição

O caso de uso mais direto é notificar os agentes quando o trabalho chega em sua fila. Sem esta notificação, os agentes têm que verificar constantemente suas visualizações ou painéis. Os tickets ficam despercebidos, os clientes esperam e os SLAs são violados.

Este gatilho se torna especialmente valioso para equipes que usam roteamento baseado em habilidades ou atribuição automática. Quando os tickets fluem para os agentes sem intervenção manual, as notificações se tornam o único sinal de que um novo trabalho chegou. Saiba mais sobre roteamento automatizado de tickets no Zendesk.

Fluxos de trabalho de escalonamento

Os gatilhos de mudança de responsável podem impulsionar padrões de escalonamento sofisticados. Você pode criar gatilhos que:

• Roteiam tickets urgentes para agentes seniores com base em mudanças de prioridade
• Movem tickets para equipes especializadas quando reatribuídos a grupos específicos
• Atualizam campos personalizados rastreando o histórico de atribuições
• Adicionam tags marcando tickets que foram reatribuídos várias vezes

Por exemplo, você pode criar um gatilho que é acionado quando um ticket é atribuído ao seu grupo de "Escalonamentos", adicionando automaticamente uma tag, definindo a prioridade como Alta e notificando o gerente do grupo.

Sincronização de integração

Quando o Zendesk faz parte de um ecossistema de ferramentas maior, as mudanças de responsável geralmente precisam ser sincronizadas com outras plataformas. Os gatilhos podem notificar sistemas externos via webhooks quando as atribuições mudam.

Padrões de integração comuns incluem:

• Sincronizar mudanças de responsável para canais do Slack para visibilidade
• Atualizar registros de CRM quando a propriedade muda
• Acionar fluxos de trabalho em ferramentas de gerenciamento de projetos
• Notificar sistemas de monitoramento externos

A ação de webhook em gatilhos permite que você envie solicitações HTTP para qualquer endpoint, tornando possível manter os sistemas externos sincronizados com as atribuições do Zendesk em tempo real.

Rastreamento e relatórios

Às vezes, você precisa rastrear padrões de atribuição para análise. Os gatilhos de mudança de responsável podem:

• Adicionar tags quando o responsável muda, criando uma trilha para relatórios
• Atualizar campos personalizados armazenando o responsável anterior ou a contagem de atribuições
• Registrar transferências entre equipes para análise de SLA
• Acionar notificações para gerentes quando os tickets saltam entre os agentes

Esses dados ajudam a identificar problemas de roteamento, medir a distribuição da carga de trabalho da equipe e entender como os tickets fluem pela sua organização.

Usando automações com condições relacionadas ao responsável

Embora os gatilhos lidem com mudanças imediatas de responsável, as automações têm seu lugar nos fluxos de trabalho de atribuição. Elas são úteis para acompanhamentos baseados em tempo após a atribuição.

Quando usar automações em vez de gatilhos

As automações fazem sentido quando você precisa verificar os tickets depois que eles foram atribuídos por um determinado período. Cenários comuns incluem:

• Acompanhar tickets que foram atribuídos, mas não atualizados em 24 horas
• Escalonar tickets que ficam com um agente por muito tempo
• Fechar tickets que foram resolvidos e atribuídos, mas nunca confirmados
• Enviar lembretes sobre prazos de SLA com base no tempo de atribuição

A principal distinção: os gatilhos reagem ao evento de atribuição em si. As automações reagem à passagem do tempo desde que esse evento ocorreu.

Condições de automação disponíveis para responsáveis

As automações oferecem várias condições baseadas em tempo relacionadas à atribuição:

• Horas desde a atribuição - Tempo decorrido desde que o ticket foi atribuído pela primeira vez a um agente
• Horas desde a atualização do responsável - Tempo desde que o campo responsável foi modificado pela última vez
• Horas desde a atualização - Tempo desde qualquer atualização no ticket
• Combinações de status + responsável - Verifique o status e o estado de atribuição juntos

Observe que "Horas desde a atribuição" só funciona para tickets que foram realmente atribuídos. Os tickets não atribuídos não atenderão a esta condição.

Exemplo: Acompanhamento de tickets atribuídos

Aqui está uma automação prática que lembra os agentes sobre os tickets que eles não tocaram:

Atender a TODAS as condições:

• Horas desde a atribuição > Maior que > 24
• Status > Não é > Resolvido
• Status > Não é > Fechado
• Responsável > Não é > ( )

Ações:

• Notificações > Enviar e-mail para o usuário > (responsável)
• Assunto: "Lembrete: O ticket #{{ticket.id}} foi atribuído por 24 horas"

Esta automação é executada a cada hora, verifica todos os tickets atribuídos por mais de 24 horas que não estão resolvidos ou fechados e envia um lembrete suave ao responsável.

Solução de problemas de gatilhos de mudança de responsável

Mesmo com as condições certas, os gatilhos às vezes não são acionados. Veja como diagnosticar e corrigir problemas comuns.

Gatilho não sendo acionado quando o responsável muda

Se o seu gatilho não estiver funcionando, verifique estas causas comuns:

A posição do gatilho é importante. O Zendesk avalia os gatilhos de cima para baixo. Se outro gatilho acima do seu modificar o ticket de uma forma que impeça que suas condições correspondam, seu gatilho não será acionado. Coloque os gatilhos de notificação no final da sua lista de gatilhos, após todos os gatilhos de categorização e roteamento.

As condições podem ser muito restritivas. Se você tiver condições adicionais além de "Responsável Mudou", verifique se elas estão realmente sendo atendidas quando as atribuições acontecem. Por exemplo, se você adicionar "Prioridade é Alta", mas o ticket que está sendo atribuído é prioridade Normal, o gatilho não será acionado.

A condição "Ticket foi atualizado". Algumas configurações de gatilho funcionam melhor com "Ticket > É > Atualizado" como uma condição adicional. Isso garante que o gatilho seja acionado apenas em atualizações, não na criação do ticket.

Notificações duplicadas

Receber vários e-mails para a mesma atribuição geralmente significa que você tem vários gatilhos com condições sobrepostas. Verifique se há:

• Vários gatilhos de notificação que são todos acionados em mudanças de responsável
• Gatilhos que são acionados em "Responsável Mudou" e também em "Ticket foi atualizado" quando uma atribuição acontece
• Ordem do gatilho fazendo com que um gatilho modifique o ticket de uma forma que faz com que outro seja acionado

A correção geralmente é consolidar gatilhos semelhantes ou ajustar sua ordem para que eles não interfiram uns nos outros.

Notificações de autoatribuição

Se os agentes reclamarem de receber e-mails quando atribuem tickets a si mesmos, verifique sua condição "Responsável não é (usuário atual)". Esta condição existe especificamente para evitar este cenário. Se você quiser notificações de autoatribuição, remova esta condição. Se você não as quiser, certifique-se de que ela esteja presente e configurada corretamente.

Mudanças de responsável não detectadas em automações

Se você está tentando usar uma automação para detectar mudanças imediatas de responsável, não vai funcionar. As automações não podem fazer isso. Mova esse fluxo de trabalho para um gatilho. Use automações apenas para acompanhamentos baseados em tempo após a atribuição.

Padrões avançados e práticas recomendadas

Depois de dominar o básico, esses padrões podem ajudá-lo a construir fluxos de trabalho de atribuição mais sofisticados.

O padrão "Devolver ao remetente"

Às vezes, os tickets precisam saltar entre as equipes. Um agente de suporte de primeira linha atribui a um especialista, que faz seu trabalho e, em seguida, precisa retornar o ticket ao agente original. O Zendesk não rastreia o "responsável original" nativamente, mas você pode construir isso com campos personalizados e webhooks.

O padrão funciona assim:

1. Crie campos personalizados para armazenar o responsável e o grupo originais
2. Use um gatilho para preencher esses campos quando um ticket é atribuído pela primeira vez para longe do grupo inicial
3. Crie uma macro que os agentes usam quando estão prontos para retornar o ticket
4. Use um gatilho de webhook para ler o responsável original armazenado e reatribuir o ticket de volta

Esta é uma configuração avançada que requer configuração de webhook, mas resolve um problema comum de fluxo de trabalho.

Dicas de organização de gatilhos

À medida que sua lista de gatilhos cresce, a organização se torna crítica.

• Agrupe gatilhos relacionados usando categorias. Tenha uma categoria "Notificações", uma categoria "Roteamento", etc.
• Use nomes descritivos que expliquem o que o gatilho faz. "Notificar o responsável na atribuição" é melhor do que "Gatilho de atribuição".
• Documente as dependências nas descrições dos gatilhos. Se o Gatilho B depende do Gatilho A ter sido executado primeiro, observe isso em ambas as descrições.
• Revise a ordem dos gatilhos trimestralmente. À medida que você adiciona gatilhos, a ordem ideal muda. Audite periodicamente para garantir que o roteamento aconteça antes das notificações, a categorização antes do escalonamento e assim por diante.

Testando gatilhos com segurança

Antes de ativar um novo gatilho:

• Use o recurso "Visualizar correspondência" para testar as condições em relação aos tickets existentes
• Teste com um ticket não produtivo primeiro
• Peça a um colega para fazer a atribuição de teste para que você possa verificar se a lógica do "usuário atual" funciona corretamente
• Verifique os logs do gatilho se algo não estiver funcionando como esperado

Indo além da automação básica de responsáveis

Os gatilhos do Zendesk lidam com a tarefa fundamental de detectar e responder a mudanças de responsável. Mas as equipes de suporte modernas estão indo além de simples notificações em direção à automação inteligente do fluxo de trabalho.

Aqui está a diferença: um gatilho diz a um agente "Você tem um ticket". Um colega de equipe de IA diz a um agente "Você tem um ticket, é sobre um problema de faturamento, o cliente está frustrado, aqui está uma resposta rascunhada e tickets semelhantes foram resolvidos desta forma".

Na eesel AI, abordamos isso como um colega de equipe que você contrata, não uma ferramenta que você configura. Nosso Agente de IA para help desks pode resolver até 81% dos tickets de forma autônoma em implantações maduras. Em vez de apenas rotear e notificar, nossa IA pode:

• Triagem inteligente antes da atribuição: A IA lê os tickets recebidos, categoriza-os por tópico e urgência e os encaminha para o especialista certo com base no conteúdo, não apenas na disponibilidade. Isso significa que seu especialista em faturamento recebe perguntas sobre faturamento e sua equipe técnica recebe relatórios de bugs.

• Notificações ricas em contexto: Em vez de apenas enviar o assunto do ticket, nosso Copiloto de IA gera um resumo do que o cliente está perguntando, identifica o sentimento e sinaliza quaisquer indicadores de urgência.

• Respostas com rascunho automático: Os agentes recebem uma resposta rascunhada junto com a notificação de atribuição. O rascunho é baseado em sua base de conhecimento e tickets anteriores, então soa como se sua equipe o tivesse escrito.

• Escalonamento inteligente: A IA identifica quais tickets realmente precisam de atenção humana versus quais ela pode resolver de forma autônoma. Isso significa que os agentes só são notificados sobre tickets que realmente exigem sua experiência.

O resultado é que, quando seus agentes recebem uma notificação, eles não estão começando do zero. Eles têm contexto, uma resposta rascunhada e confiança de que este ticket realmente precisa de sua atenção.

Se você está gastando um tempo significativo configurando gatilhos do Zendesk para obter notificações básicas funcionando, pode valer a pena explorar se um colega de equipe de IA poderia lidar com o fluxo de trabalho de notificação de forma mais inteligente, ao mesmo tempo em que reduz seu volume geral de tickets por meio da resolução autônoma. Veja como a eesel AI se integra ao Zendesk para aprimorar seus fluxos de trabalho de suporte.