zendesk-automation-reopen-ticket-conditions
Written by
eesel Team
Last edited 24 fevereiro 2026
{
"title": "Condições de automação do Zendesk para reabrir tickets: Um guia completo para 2026",
"slug": "zendesk-automation-reopen-ticket-conditions",
"locale": "pt",
"date": "2026-02-24",
"updated": "2026-02-24",
"template": "default",
"excerpt": "Domine as condições de automação do Zendesk para reabrir tickets com este guia abrangente. Aprenda quando usar triggers vs automações, configure fluxos de trabalho de reabertura e resolva o problema do \"obrigado\".",
"categories": [
"Blog Writer AI"
],
"tags": [
"Zendesk",
"Automation",
"Customer Support",
"Ticket Management",
"Help Desk"
],
"readTime": 16,
"author": 16,
"reviewer": 14,
"seo": {
"title": "Condições de automação do Zendesk para reabrir tickets: Um guia completo para 2026",
"description": "Domine as condições de automação do Zendesk para reabrir tickets com este guia abrangente. Aprenda quando usar triggers vs automações, configure fluxos de trabalho de reabertura e resolva o problema do \"obrigado\".",
"image": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-1a926c95-0d50-40c9-aa02-3a4a37caae17"
},
"coverImage": "https://wmeojibgfvjvinftolho.supabase.co/storage/v1/object/public/public_assets/blog-gen/banner-1a926c95-0d50-40c9-aa02-3a4a37caae17",
"coverImageAlt": "Imagem do banner para condições de automação do Zendesk para reabrir tickets: Um guia completo para 2026",
"coverImageWidth": 1920,
"coverImageHeight": 1080,
"faqs": {
"heading": "Perguntas Frequentes",
"type": "blog",
"answerType": "html",
"faqs": [
{
"question": "Como configuro as condições de automação do Zendesk para reabrir tickets para notificar minha equipe imediatamente?",
"answer": "Use um trigger (não uma automação) com a condição 'Categoria do status | Alterado para | Aberto'. Adicione 'Comentário | É | Público' para garantir que ele seja acionado apenas em respostas do cliente. Defina a ação para enviar um e-mail para o responsável ou para um grupo."
},
{
"question": "As condições de automação do Zendesk para reabrir tickets funcionam com status de ticket personalizados?",
"answer": "Sim, mas use 'Categoria do status' em vez de 'Status' em suas condições. Os status personalizados são agrupados em categorias (Novo, Aberto, Pendente, Resolvido, Fechado). A condição 'Categoria do status' captura todas as variações dentro de uma categoria."
},
{
"question": "Qual é a melhor maneira de impedir que as condições de automação do Zendesk para reabrir tickets sejam acionadas várias vezes?",
"answer": "Adicione uma condição de anulação usando tags. Inclua 'Tags | Não contém nenhum dos seguintes | [sua-tag]' nas condições e, em seguida, adicione essa tag como uma ação quando a automação for acionada. Isso garante que ela seja executada apenas uma vez por ticket."
},
{
"question": "Como posso usar as condições de automação do Zendesk para reabrir tickets para agendar acompanhamentos?",
"answer": "Use o fluxo de trabalho de status Em espera + Data de vencimento. Crie uma macro que defina o Tipo como Tarefa, o Status como Em espera e solicite uma data de vencimento. Em seguida, crie uma automação com 'Horas desde a data de vencimento | Maior que | 0' que altere o status de volta para Aberto."
},
{
"question": "Por que minhas condições de automação do Zendesk para reabrir tickets perdem alguns tickets?",
"answer": "Se estiver usando condições baseadas em tempo, evite 'É' e use 'Maior que' em vez disso. As automações são executadas a cada hora, portanto, 'É 24' pode perder tickets que atingem 24 horas entre as verificações. 'Maior que 24' captura todos os tickets que ultrapassaram o limite."
},
{
"question": "As condições de automação do Zendesk para reabrir tickets podem distinguir entre respostas do cliente e notas internas?",
"answer": "Sim. Adicione 'Comentário | É | Público' às suas condições para acionar apenas comentários visíveis ao cliente. Use 'Comentário | É | Privado' para fluxos de trabalho apenas internos. Isso é essencial para evitar falsos acionamentos da atividade do agente."
}
],
"supportLink": null
}
}
---
Gerenciar a reabertura de tickets é um daqueles fluxos de trabalho que parece simples até que deixe de ser. Você resolve um ticket, o cliente responde com um rápido "obrigado" e, de repente, esse ticket está de volta à sua fila aberta, bagunçando sua carga de trabalho. Ou pior, um ticket permanece resolvido por dias quando, na verdade, precisava de acompanhamento, e agora você perdeu a oportunidade de ajudar.
Configurar corretamente as condições de automação do Zendesk para reabrir tickets significa construir fluxos de trabalho que lidem com esses cenários de forma inteligente. Nem toda resposta do cliente exige reabertura. Nem todo ticket resolvido deve permanecer resolvido para sempre. O truque é saber qual ferramenta usar quando.
Este guia orienta você exatamente sobre como configurar automações e *triggers* para cenários de reabertura. Se você está tentando notificar os agentes sobre tickets reabertos, agendar acompanhamentos para mais tarde ou interromper o temido *loop* de reabertura de "obrigado", você encontrará as condições e etapas específicas de que precisa.
E se você se vir construindo cadeias de *triggers* cada vez mais complexas para lidar com cenários sutis, veremos como [abordamos esses desafios de forma diferente na eesel AI](https://www.eesel.ai/integration/zendesk-ai).
## Entendendo a mecânica de reabertura de tickets do Zendesk
Antes de mergulhar nas condições e configurações, vamos esclarecer como a reabertura de tickets realmente funciona no Zendesk. A plataforma segue um ciclo de vida estrito que determina o que pode e o que não pode acontecer em cada estágio.
O ciclo de vida padrão do ticket se parece com isto: **Novo → Aberto → Pendente → Resolvido → Fechado** ([Documentação do Zendesk](https://support.zendesk.com/hc/en-us/articles/4408885654298))
Aqui está o que cada status significa:
- **Novo**: O ticket foi criado agora e ainda não foi atribuído
- **Aberto**: Um agente está trabalhando ativamente no ticket
- **Pendente**: O agente está aguardando informações do cliente
- **Resolvido**: O agente acredita que o problema foi resolvido
- **Fechado**: O ticket está bloqueado e não pode ser modificado
A regra crítica para reabertura: **Os tickets só podem ser reabertos a partir do status Resolvido.** Depois que um ticket chega ao status Fechado, é permanente. Isso é por *design*. Os tickets fechados se tornam registros históricos que preservam a integridade dos dados para relatórios e conformidade.
Quando um cliente responde a um ticket Resolvido, o Zendesk altera automaticamente o status de volta para Aberto. Este é o cenário de reabertura mais comum. Mas também causa mais dores de cabeça. Aquele e-mail de "muito obrigado!" de um cliente satisfeito? Ele reabre o ticket da mesma forma que um acompanhamento de "isso não funcionou".
Entender este ciclo de vida é importante porque suas condições de automação devem levá-lo em consideração. Você não pode criar uma automação que reabra um ticket Fechado (o Zendesk não permitirá). Você pode, no entanto, criar fluxos de trabalho sofisticados que lidem com a transição de Resolvido para Aberto de forma inteligente.
Para as equipes que consideram essas limitações nativas restritivas, [nossa integração com o Zendesk](https://www.eesel.ai/integration/zendesk-ai) oferece uma abordagem alternativa que lê a intenção em vez de apenas verificar os campos de status.
## *Triggers* vs. automações: Quando usar cada um para cenários de reabertura
O Zendesk oferece duas ferramentas para automação: *triggers* e automações. Eles parecem semelhantes, mas funcionam de forma muito diferente. Usar o errado para seu fluxo de trabalho de reabertura é uma receita para frustração.
### *Triggers*: Baseados em eventos e imediatos
Os *triggers* são acionados no instante em que um ticket atende às suas condições. Eles são perfeitos para respostas em tempo real a mudanças de status. Saiba mais na [documentação de *triggers* do Zendesk](https://support.zendesk.com/hc/en-us/articles/4408893545882).
**Use *triggers* quando:**
- Você deseja notificação imediata quando um ticket é reaberto
- Você precisa tomar medidas com base em quem atualizou o ticket
- Você está respondendo a transições de status (Resolvido → Aberto)
**A condição principal para *triggers* de reabertura:**
Ticket: Categoria do status | Alterado para | Aberto
Esta condição só é acionada quando o status de um ticket realmente muda para Aberto, não quando ele simplesmente "está" Aberto. Essa é a distinção que faz com que os *triggers* funcionem para cenários de reabertura.
### Automações: Baseadas em tempo e agendadas
As automações são executadas em uma programação (aproximadamente uma vez por hora). Elas são projetadas para ações que devem acontecer depois que um período de tempo passou. Consulte o [guia de automação do Zendesk](https://support.zendesk.com/hc/en-us/articles/4408883801626) para obter detalhes.
**Use automações quando:**
- Você deseja acompanhar os tickets que foram resolvidos por X horas
- Você está agendando tickets para reabrir em horários específicos
- Você precisa de escalonamento baseado em tempo (ticket aberto por mais de 24 horas)
**Condições comuns baseadas em tempo:**
Ticket: Horas desde resolvido | Maior que | 24 Ticket: Horas desde pendente | Maior que | 48 Ticket: Horas desde a data de vencimento | Maior que | 0
### A estrutura de decisão
Veja como escolher:
| Cenário | Use | Por quê |
|----------|-----|-----|
| Notificar o responsável quando o cliente reabre | *Trigger* | Precisa acontecer imediatamente |
| Escalonar se o ticket permanecer aberto por 24 horas | Automação | Condição baseada em tempo |
| Agendar o ticket para reabrir na próxima semana | Automação | Condição de tempo futuro |
| Marcar tickets reabertos para relatórios | *Trigger* | Capturar o evento quando ele acontece |
| Fechar tickets resolvidos por 96 horas | Automação | Ação baseada em tempo |
A principal coisa a lembrar: os *triggers* reagem a eventos, as automações reagem ao tempo. A maioria dos fluxos de trabalho de reabertura realmente precisa de ambos. Você pode usar um *trigger* para notificar o responsável imediatamente e, em seguida, uma automação para escalar se o ticket permanecer aberto por muito tempo.
Para obter mais informações sobre automação baseada em tempo, consulte nosso [guia sobre condições de automação do Zendesk](https://www.eesel.ai/blog/zendesk-automation-conditions-to-act-after-hours-since-status-change).
## Condições essenciais para automações de tickets de reabertura
Construir fluxos de trabalho de reabertura eficazes requer a compreensão de toda a gama de condições disponíveis. Aqui está a referência completa para as condições que você realmente usará.
### Condições baseadas em status
Estas são o seu pão com manteiga para cenários de reabertura:
**Categoria do status | Alterado para | Aberto**
- É acionado quando um ticket faz a transição PARA o status Aberto
- Use em *triggers* para notificação imediata
- Condição de detecção de reabertura mais comum
**Status | Alterado de | Resolvido**
- É acionado quando um ticket sai do status Resolvido
- Mais específico do que "Alterado para Aberto" (captura Resolvido → qualquer status)
- Útil quando você deseja rastrear qualquer movimento para longe de Resolvido
**Categoria do status | É | Aberto**
- Verifica o estado atual, não as transições
- Use em automações para monitoramento contínuo
- Exemplo: "Status é Aberto E Horas desde aberto > 24"
### Condições baseadas em tempo
As automações dependem fortemente destas:
**Horas desde resolvido | Maior que | [número]**
- Mais comum para acompanhamento pós-resolução
- Use "Maior que" não "É" (mais confiável)
- Lembre-se: as automações são executadas a cada hora, então o tempo não é exato
**Horas desde pendente | Maior que | [número]**
- Para escalar tickets obsoletos
- Valor comum: 48 horas (2 dias úteis)
**Horas desde a data de vencimento | Maior que | 0**
- Para fluxos de trabalho de reabertura agendados
- Só funciona com tickets do tipo Tarefa que têm datas de vencimento
**Horas desde aberto | Maior que | [número]**
- Para escalar tickets que permanecem abertos por muito tempo
- Útil para SLAs e aumentos de prioridade
### Condições de participante
Elas ajudam você a distinguir QUEM causou a reabertura:
**Usuário atual | É | (usuário final)**
- Garante que o *trigger* seja acionado apenas nas ações do cliente
- Crítico para evitar *loops* de reabertura acionados pelo agente
**Usuário atual | É | (agente)**
- Para fluxos de trabalho onde as ações do agente importam
- Menos comum para cenários de reabertura
**Comentário | É | Público**
- Distingue comentários de clientes de notas internas
- Essencial para fluxos de trabalho de "cliente respondeu"
**Comentário | É | Privado**
- Para fluxos de trabalho apenas internos
- Raramente usado para cenários de reabertura
### Condições de anulação (prevenção de *loops*)
O erro de automação mais comum: esquecer de impedir que a automação seja executada repetidamente. Sempre inclua uma condição de anulação.
**Tags | Não contém nenhum dos seguintes | [sua-tag]**
- Adicione a tag como uma ação quando a automação for acionada
- Impede a reexecução no mesmo ticket
- Exemplo: Tag "reopen_notified" após a primeira notificação
**Por que "Maior que" vence "É" para condições de tempo**
As automações do Zendesk são executadas em um ciclo horário. Se você usar "Horas desde resolvido | É | 24", a automação pode verificar em 23,5 horas (perde) e, em seguida, em 24,5 horas (perde novamente). Usar "Maior que" garante que você capture todos os tickets elegíveis.
## Passo a passo: Criando um *trigger* de notificação de reabertura
Vamos construir um *trigger* prático que notifica os responsáveis quando seus tickets resolvidos são reabertos. Este é um dos fluxos de trabalho de reabertura mais comuns.
### Passo 1: Navegue até a página de *triggers*
Vá para **Central de administração > Objetos e regras > Regras de negócios > *Triggers***. Você verá uma lista de *triggers* existentes. Não exclua os padrões, a menos que saiba exatamente o que eles fazem. Consulte a [referência de condições de *trigger* do Zendesk](https://support.zendesk.com/hc/en-us/articles/4408893545882) para obter opções de condição completas.
### Passo 2: Crie um novo *trigger*
Clique em **Adicionar *trigger***. Dê a ele um nome descritivo como:
- "Notificar o responsável quando o ticket for reaberto pelo cliente"
- "Notificação de ticket reaberto"
Evite nomes vagos como "*Trigger* 1". O você do futuro agradecerá o você do presente ao solucionar problemas.
### Passo 3: Defina as condições
Em "Atender a TODAS as seguintes condições", adicione:
Ticket: Categoria do status | Alterado para | Aberto
**Adições opcionais, mas recomendadas:**
Ticket: Comentário | É | Público
(Isso garante que ele seja acionado apenas em respostas do cliente, não em notas internas)
Ticket: Usuário atual | É | (usuário final)
(Isso confirma que o cliente causou a reabertura, não um agente)
Ticket: Tags | Não contém nenhum dos seguintes | reopen_notified
(Isso impede que o *trigger* seja acionado duas vezes no mesmo ticket)
### Passo 4: Configure as ações
Em "Executar estas ações", adicione:
**Notificar o responsável:**
Notificações: Enviar e-mail para o usuário | (responsável) Assunto: "Ticket reaberto pelo cliente: {{ticket.title}}" Corpo: Incluir detalhes do ticket e link
**Adicionar uma tag de rastreamento:**
Ticket: Adicionar tags | reopen_notified
**Opcional: Definir prioridade:**
Ticket: Prioridade | Alta
(Útil se os tickets reabertos precisarem de atenção imediata)
### Passo 5: Teste seu *trigger*
1. Salve o *trigger* (ele é ativado automaticamente)
2. Crie um ticket de teste ou use um existente
3. Resolva o ticket
4. Adicione um comentário público como um usuário final (use uma janela anônima ou uma conta diferente)
5. Verifique se o status muda para Aberto
6. Verifique se o responsável recebeu a notificação
Se não funcionar, verifique a posição do *trigger*. O Zendesk processa os *triggers* de cima para baixo. Se outro *trigger* modificar o ticket primeiro, o seu pode não ser acionado.
O construtor de automação usa uma interface semelhante, mas se concentra em condições baseadas em tempo em vez de eventos imediatos:
Para outra abordagem para *triggers* de mudança de status, confira nosso [guia para criar *triggers* do Zendesk quando o status muda para aberto](https://www.eesel.ai/en/blog/zendesk-trigger-when-status-changed-to-open).
## Receita: Agendando tickets para reabrir em horários específicos
Às vezes, você precisa "adiar" um ticket para acompanhamento posterior. Talvez um cliente tenha dito "entre em contato comigo na próxima semana" ou você precise verificar se uma correção funcionou antes de fechar totalmente. Veja como construir um fluxo de trabalho de reabertura agendado.
### Passo 1: Ativar o status Em espera
Por padrão, o status Em espera não está ativo. Vá para **Central de administração > Objetos e regras > Tickets > Status** e adicione o status Em espera se ainda não o fez. Consulte a [receita de reabertura agendada do Zendesk](https://support.zendesk.com/hc/en-us/articles/7509181267226) para obter mais detalhes.
### Passo 2: Criar uma macro para agentes
As macros garantem que os agentes sigam o fluxo de trabalho de forma consistente. Crie uma macro que:
1. Defina **Tipo** como **Tarefa**
2. Defina **Status** como **Em espera**
3. Adicione uma tag personalizada (como "schedule_reopen")
4. Solicite ao agente que defina o campo **Data de vencimento**
**Para criar a macro:**
- Central de administração > Espaços de trabalho > Ferramentas do agente > Macros
- Adicionar macro
- Ações: Tipo = Tarefa, Status = Em espera, Adicionar tags = schedule_reopen
### Passo 3: Criar a automação de reabertura
Agora crie uma automação que observe as datas de vencimento:
**Condições:**
Ticket: Categoria do status | É | Em espera Ticket: Tipo | É | Tarefa Ticket: Tags | Contém pelo menos um dos seguintes | schedule_reopen Ticket: Horas desde a data de vencimento | Maior que | 0
**Ações:**
Ticket: Categoria do status | Aberto Ticket: Adicionar tags | auto_reopened
A condição "Horas desde a data de vencimento > 0" significa "a data de vencimento já passou". Quando a automação é executada (a cada hora), qualquer ticket com data de vencimento vencida será reaberto.
### Como os agentes usam este fluxo de trabalho
1. O agente aplica a macro a um ticket
2. O agente seleciona a data de reabertura desejada no campo Data de vencimento
3. O ticket fica Em espera
4. Na data selecionada, a automação o reabre automaticamente
Este fluxo de trabalho é particularmente útil para:
- Lembretes de acompanhamento
- Esperando por dependências externas
- Problemas sazonais ou sensíveis ao tempo
- Retornos de chamada solicitados pelo cliente
## Resolvendo o problema de reabertura de "obrigado"
Aqui está uma estatística da comunidade Zendesk que pode ressoar: **60-70% das reaberturas de tickets são apenas clientes dizendo "obrigado".** Não perguntas de acompanhamento. Não reclamações. Apenas gratidão educada que cria trabalho desnecessário para os agentes.
O desafio é distinguir agradecimentos genuínos de "obrigado, mas ainda preciso de ajuda". Um simples *trigger* de palavra-chave que resolve automaticamente qualquer coisa que contenha "obrigado" acabará perdendo um problema real.
### Solução 1: O método da *hashtag*
Treine os clientes para usar uma *hashtag* específica quando realmente precisarem de reabertura. No e-mail do seu ticket resolvido, inclua uma linguagem como:
> "Se você precisar de mais assistência, responda com #reabrir e entraremos em contato. Caso contrário, não há necessidade de responder."
**Configuração do *trigger***:
Condições:
- Categoria do status | Alterado para | Aberto
- Texto do comentário | Não contém a seguinte string | #reabrir
Ações:
- Status | Resolvido
- Adicionar tags | false_reopen
- E-mail do solicitante | "Seu ticket permanece resolvido. Responda com #reabrir se precisar de ajuda."
Isso funciona, mas requer educação do cliente. Nem todos os clientes leem com atenção.
### Solução 2: O *trigger* de resolução automática (com salvaguardas)
Crie um *trigger* que resolva automaticamente os tickets que contenham "obrigado" ou "obrigada", mas SOMENTE quando nenhum ponto de interrogação estiver presente.
**Configuração do *trigger***:
Condições:
- Categoria do status | Alterado para | Aberto
- Texto do comentário | Contém pelo menos um dos seguintes | obrigado obrigada
- Texto do comentário | Não contém nenhum dos seguintes | ?
Ações:
- Status | Resolvido
- Adicionar tags | auto_solved_thanks
Isso captura "Obrigado pela sua ajuda!", mas perde "Obrigado, mas como faço...?"
### Solução 3: Aplicativos de terceiros
O [aplicativo Thank You GPT](https://www.zendesk.com/marketplace/apps/support/470124/thank-you-gpt) do [Zendesk Marketplace](https://www.zendesk.com/marketplace) usa IA para detectar agradecimentos genuínos versus perguntas de acompanhamento. Ele é construído especificamente para este problema.
### Solução 4: Detecção alimentada por IA (avançado)
Para equipes com acesso [Zapier](https://zapier.com) e [OpenAI](https://openai.com), você pode construir um fluxo de trabalho sofisticado:
1. O *trigger* detecta a reabertura e adiciona a tag
2. O Zapier observa uma visualização para tickets marcados
3. O OpenAI analisa o comentário: "Isso é apenas um agradecimento ou há uma pergunta real?"
4. Se for apenas um agradecimento, o Zapier resolve o ticket via API
Um chefe de CX de uma grande empresa compartilhou sua configuração:
<quote text="Criei uma automação via Zapier usando um prompt no OpenAI, que está funcionando maravilhosamente para nós. Eu o recomendaria fortemente." sourceIcon="https://www.iconpacks.net/icons/2/free-reddit-logo-icon-2436-thumb.png" sourceName="Comunidade Zendesk" sourceLink="https://support.zendesk.com/hc/de/community/posts/4409222754970-Stopping-the-reopening-tickets-by-a-Thank-you-response/">
</quote>
### Nossa recomendação
Comece com a Solução 2 (resolução automática com proteção de ponto de interrogação). É simples, gratuito e captura a maioria dos casos. Se você ainda está se afogando em reaberturas de agradecimento, atualize para o aplicativo Thank You GPT ou considere uma abordagem alimentada por IA.
Falando nisso, [nosso agente de IA](https://www.eesel.ai/product/ai-agent) lida com este cenário exato, entendendo a intenção em vez de apenas corresponder palavras-chave. Ele sabe a diferença entre "obrigado!" e "obrigado, mas..." sem cadeias de *triggers* complexas.
## Erros comuns e solução de problemas
Mesmo os administradores experientes do Zendesk encontram problemas com automações de reabertura. Aqui estão os problemas mais comuns e como corrigi-los.
### *Trigger* não sendo acionado
**Verifique a posição do *trigger***. O Zendesk processa os *triggers* de cima para baixo. Se outro *trigger* modificar o ticket primeiro (especialmente um que altera o status ou adiciona tags), o seu pode nunca ter a chance de ser executado. Mova seu *trigger* de reabertura para o topo.
**Verifique "Alterado para" vs "É."** Este é o erro nº 1. "Status é Aberto" corresponde a qualquer ticket aberto. "Status alterado para Aberto" corresponde apenas aos tickets que acabaram de se tornar abertos. Para detecção de reabertura, você precisa de "Alterado para".
**Verifique seu campo de status.** Se você tiver status personalizados ativados, use "Categoria do status" não "Status". Se você estiver em um plano Team sem status personalizados, use "Status".
### Automação sendo executada várias vezes
**Você esqueceu uma condição de anulação.** Toda automação precisa de uma maneira de impedir que ela seja executada repetidamente. Adicione uma tag quando a automação for acionada e, em seguida, inclua "Tags não contém nenhum dos seguintes" em suas condições.
**Exemplo de correção:**
Condições:
- Status | Resolvido
- Horas desde resolvido | Maior que | 24
- Tags | Não contém nenhum dos seguintes | solved_24h_notified
Ações:
- E-mail do responsável | "O ticket foi resolvido há 24 horas"
- Adicionar tags | solved_24h_notified
### Atualizações de API causando aberturas inesperadas
Ferramentas de terceiros que atualizam tickets via API podem acionar seus fluxos de trabalho de reabertura não intencionalmente. Um culpado comum: ferramentas de pesquisa que gravam classificações de volta em tickets resolvidos.
**Correção:** Adicione esta condição:
Ticket: Atualização via | Não é | Serviço da Web (API)
Isso impede que seu *trigger* seja acionado em atualizações baseadas em API, ao mesmo tempo em que captura alterações iniciadas pelo usuário.
### Confusão entre Status vs Categoria do status
Isso confunde quase todo mundo:
- **Status** (planos Team): O campo de status real (Novo, Aberto, Pendente, Resolvido, Fechado)
- **Categoria do status** (Growth+ com status personalizados): Grupos de status relacionados
Se você tiver status de ticket personalizados ativados, seus status padrão se tornarão categorias. Use as condições "Categoria do status" para capturar todas as variações. Se você estiver no plano Team, use "Status".
### Condição de tempo perdida
Usar "Horas desde resolvido | É | 24" é arriscado. Como as automações são executadas a cada hora, elas podem verificar em 23,5 horas (perder) e, em seguida, em 24,5 horas (perder novamente).
**Sempre use "Maior que" para condições de tempo.**
## Quando considerar a automação alimentada por IA em vez disso
Os *triggers* e automações do Zendesk são poderosos, mas são fundamentalmente baseados em regras. Eles fazem exatamente o que você diz a eles, nada mais e nada menos. Às vezes isso é limitante.
Considere estes cenários:
**Você tem mais de 20 *triggers* apenas para tratamento de reabertura.** Se sua lista de *triggers* está se tornando incontrolável, isso é um sinal de que a automação baseada em regras está atingindo seus limites.
**Você precisa entender a intenção, não apenas as palavras-chave.** "Obrigado" vs "obrigado, mas..." é surpreendentemente difícil de lidar com as condições de *trigger*. A IA lê o contexto.
**Você deseja automação progressiva.** Comece com a IA redigindo respostas para revisão do agente. À medida que se prova, deixe-a enviar respostas diretamente. Eventualmente, lide com o suporte de linha de frente completo. Você está no controle do ritmo.
**Sua equipe gasta mais tempo gerenciando a automação do que usando-a.** Cadeias de *triggers* complexas exigem manutenção contínua. As condições de linguagem natural são mais fáceis de gerenciar.
### Como abordamos isso na eesel AI
[Nós nos integramos ao Zendesk](https://www.eesel.ai/integration/zendesk-ai) para fornecer uma camada de IA que funciona em conjunto com sua configuração existente. Em vez de construir uma lógica de *trigger* rígida, você contrata um colega de equipe de IA que aprende seu negócio.
Principais diferenças:
- **Tratamento baseado em intenção:** Nossa IA entende a diferença entre agradecimentos genuínos e perguntas de acompanhamento sem regras de palavras-chave complexas
- **Condições de linguagem natural:** Diga "se o cliente parece frustrado com a cobrança" em vez de construir uma lógica baseada em tags
- **Autonomia progressiva:** Comece com a IA redigindo respostas. Suba de nível para respostas diretas à medida que a confiança aumenta
- **Configuração mais rápida:** Conecte-se ao Zendesk e nós aprendemos com seus tickets existentes e central de ajuda em minutos
Nosso produto [AI Triage](https://www.eesel.ai/product/ai-triage) lida especificamente com o roteamento e a marcação com base no conteúdo real do ticket, não apenas nos valores dos campos. E [nosso AI Agent](https://www.eesel.ai/product/ai-agent) pode resolver tickets de forma autônoma quando apropriado, não apenas notificar e marcar.
Se você está achando a automação nativa do Zendesk limitante para cenários de reabertura complexos, [veja como podemos ajudar](https://www.eesel.ai/integration/zendesk-ai).
Compartilhe esta postagem
Article by
