
O que "regras de automação" realmente significa no Freshdesk
Se você já vasculhou o painel de administração do Freshdesk procurando por "automations", provavelmente notou que os nomes não batem com metade dos tutoriais disponíveis online. Isso porque o Freshdesk renomeou discretamente seus três tipos clássicos de regra. Os antigos Dispatch'r, Observer e Supervisor (ou Time Triggers) sumiram da interface. O que você vê hoje é Ticket Creation, Ticket Updates e Hourly Triggers, todos em Admin > Workflows > Automations, cada um em sua própria aba.
A mecânica por baixo continua a mesma. Toda regra é construída a partir de condições (quando X é verdadeiro) e ações (faça Y), e a própria visão geral das regras de automação do Freshdesk confirma que existem exatamente três tipos. O que muda entre elas é quando a regra tem a chance de rodar.

Essa é a camada que a maioria das pessoas tem em mente ao dizer "regras de automação do Freshdesk", e ela é separada de duas vizinhas que veremos mais adiante: as automações de cenário (macros manuais) e a atribuição automática de tickets. Se você quiser o passeio completo por tudo relacionado a automação na plataforma, nosso guia completo de automação do Freshdesk amplia a visão; este artigo permanece focado no próprio motor de regras.
Os três tipos de regras de automação do Freshdesk
Todo o modelo se encaixa assim que você para de pensar no que cada regra faz e passa a pensar em quando ela roda. Aqui está o timing em resumo.

1. Regras de Ticket Creation (antigamente Dispatch'r)
Elas rodam no momento em que um ticket é criado, o que as torna a sua porta de entrada para a triagem. Segundo a documentação de criação de tickets do Freshdesk, uma regra de criação pode atribuir o ticket a um grupo ou agente, definir propriedades como status, prioridade e tipo, disparar notificações por e-mail, ou excluir e marcar tickets como spam. As condições podem ser construídas com base em campos do ticket, propriedades de contato ou propriedades da empresa, com operadores E/OU e blocos aninhados.
Há uma configuração aqui que pega quase todo mundo. Por padrão, só a primeira regra correspondente roda. A própria documentação do Freshdesk avisa que "a ordem das regras é muito importante porque apenas a primeira regra correspondente será executada". Então, se uma regra deveria disparar e não dispara, o culpado de sempre é uma regra mais acima que já correspondeu e interrompeu a cadeia. Para mudar isso, clique na engrenagem acima da lista de regras e escolha "Execute all matching rules".

Esse é o tipo de regra a usar quando você quer que os tickets novos já cheguem classificados antes de um agente sequer vê-los: rotear perguntas de faturamento para o grupo financeiro, subir para prioridade alta qualquer coisa de uma empresa VIP, ou enviar uma resposta automática confirmando o recebimento. É o mais perto que o motor clássico chega da triagem, mas ele só consegue classificar pelos campos que você indicar, não pelo que o ticket realmente trata.
2. Regras de Ticket Updates (antigamente Observer)
Enquanto as regras de criação disparam uma vez no início, as regras de atualização de tickets "ficam ouvindo constantemente os eventos que você especificou", comparam com as condições e então agem. Elas são a camada reativa: reabrir um ticket resolvido quando um cliente responde, atribuir um agente quando um terceiro adiciona uma nota, enviar uma pesquisa de CSAT quando um ticket é resolvido, ou enviar um e-mail a um supervisor após uma avaliação ruim de um cliente VIP.
O que torna as regras de atualização diferentes é o bloco de evento no topo, algo que os outros dois tipos de regra não têm. Ele tem duas partes: "quando uma ação é realizada por" (agente, solicitante, qualquer um, um colaborador ou o sistema) e "envolve qualquer um destes eventos" (uma propriedade alterada, uma nota adicionada, uma resposta enviada, feedback recebido, além de eventos do sistema como tickets vencidos). As condições e ações funcionam depois normalmente, abaixo disso.

Diferente das regras de criação, aqui não existe um botão de "só a primeira correspondência": "todas as regras correspondentes são executadas de cima para baixo". As regras de atualização também trazem uma ação Trigger webhook, que é a forma de estender o Freshdesk para sistemas externos, o mesmo gancho que nosso guia de webhooks do Freshdesk percorre, e a base para receitas úteis como notificar o Slack quando o sentimento cai. Uma observação: as regras de atualização não estão no plano gratuito, começam a partir do Growth.
3. Hourly Triggers (antigamente Time Triggers)
O terceiro tipo lida com a passagem do tempo, e a documentação de Hourly Triggers do Freshdesk é explícita ao dizer que essa é a funcionalidade "FKA Time Triggers". Essas são as regras que capturam o que não está acontecendo: tickets parados sem atendimento, se aproximando de uma violação de SLA, ou resolvidos mas não fechados. Um exemplo clássico é escalar qualquer ticket que fique 48 horas sem ser tocado, aumentando a prioridade e avisando um supervisor.
A pegadinha está no nome. Os Hourly Triggers rodam uma vez por hora, então qualquer limite de tempo que você definir "deve ser sempre maior ou igual a uma hora". Há mais alguns limites que vale conhecer antes de depender deles: só comparam tickets atualizados nos últimos 30 dias, e funcionam apenas com propriedades do ticket, não com propriedades de contato ou empresa, e não podem usar condições sobre assunto do e-mail, descrição, e-mail do solicitante, CC, tags ou anexos. Se você já configurou uma regra baseada em tempo e a viu atrasar, é por isso, e nosso guia dedicado a Hourly Triggers do Freshdesk explora as soluções alternativas.
Como configurar uma regra de automação do Freshdesk, passo a passo
Depois de saber qual tipo você precisa, a construção segue o mesmo formato nos três: um evento opcional, algumas condições e uma ou mais ações.

Aqui está o passo a passo para uma regra de Ticket Creation, a que a maioria das equipes usa para começar:
- Vá em Admin > Workflows > Automations e abra a aba Ticket Creation.
- Clique em New Rule e dê a ela um nome que você reconheça depois ("Route billing to Finance" é melhor do que "Rule 7").
- Defina suas condições, por exemplo o assunto do ticket contém "refund" OU o tipo é "Billing". Use os operadores E/OU e blocos aninhados para algo mais elaborado.
- Defina suas ações: atribuir ao grupo Financeiro, definir a prioridade como Alta, enviar uma notificação. Você pode empilhar várias.
- Confira a ordem de execução. Arraste a regra para a posição certa e decida, pelo ícone de engrenagem, se você quer o comportamento de apenas a primeira correspondência ou todas as correspondências. Só esse passo já evita a maior parte das dores de cabeça do tipo "por que minha regra não disparou".
- Salve e teste com um ticket real antes de confiar nela em produção.
Alguns hábitos práticos tornam isso menos doloroso. O Freshdesk vem com regras de exemplo prontas (como uma que roteia tickets de reembolso para um grupo de faturamento) que você pode estudar ou clonar em vez de começar do zero, e cada regra mostra estatísticas próprias de quantos tickets ela afetou nos últimos 7 dias, sua checagem mais rápida de que uma regra realmente está fazendo algo. Também não há limite para o número de condições em uma regra, então você pode ser bem específico, só lembre que cada condição é algo que você teve que pensar com antecedência.
As outras camadas de automação: cenários e roteamento
Os três tipos de regra recebem quase toda a atenção, mas duas funcionalidades vizinhas fazem um bocado de trabalho silencioso, e as pessoas costumam confundi-las com regras de automação.
As automações de cenário são a prima manual. Em vez de disparar por condições, são pacotes de ações de um clique que um agente executa em um ticket, a camada de macro. Em vez de marcar um ticket como Refund, atribuí-lo ao grupo Refunds e definir o status como Processing manualmente toda vez, você agrupa tudo isso em um Scenario e executa com um único clique (ou em lote, em tickets selecionados). Elas ficam em Admin > Agent Productivity > Scenario Automations, e você pode definir se cada uma é privada, do grupo todo ou compartilhada com todos. Nosso guia de automações de cenário do Freshdesk vai mais fundo, mas a captura de tela abaixo mostra a variedade de ações que um cenário pode conter.

A atribuição automática de tickets é a outra funcionalidade vizinha. Alimentada pelo motor Omniroute do Freshdesk, ela decide quem recebe um ticket com base na carga, disponibilidade e habilidades dos agentes. Existem três métodos de roteamento: round-robin (circular, consciente da capacidade), baseado em carga (atribui conforme a ocupação de cada agente) e por habilidade (combina idioma ou expertise em produto). A ressalva importante: o Advanced Automatic Routing é exclusivo dos planos Pro e Enterprise, então as opções mais avançadas de atribuição automática não estão disponíveis nos planos mais baratos.

De qual plano do Freshdesk você precisa para regras de automação?
Nem toda automação está disponível em todo plano, e é daí que vem boa parte da confusão do tipo "por que não encontro essa configuração". Veja como as peças se encaixam nos níveis de preço do Freshdesk. (Os valores refletem os planos independentes do Freshdesk; os preços são anuais, por agente.)
| Funcionalidade de automação | Free | Growth ($19) | Pro ($55) | Enterprise ($89) |
|---|---|---|---|---|
| Regras de Ticket Creation | ✅ | ✅ | ✅ | ✅ |
| Regras de Ticket Updates | ❌ | ✅ | ✅ | ✅ |
| Hourly Triggers | ❌ | ✅ | ✅ | ✅ |
| Automações de cenário | ❌ | ✅ | ✅ | ✅ |
| Advanced Automatic Routing (round-robin / baseado em carga) | ❌ | ❌ | ✅ | ✅ |
| Roteamento por habilidade | ❌ | ❌ | ❌ | ✅ |
| Condições por regra | Ilimitadas | Ilimitadas | Ilimitadas | Ilimitadas |
O resumo: a triagem básica na criação é gratuita, mas qualquer coisa reativa, baseada em tempo ou sensível à carga exige pelo menos o plano Growth, e o roteamento mais inteligente fica restrito a Pro e Enterprise. Se você está avaliando se vale a pena dar o salto, nossa comparação de planos do Freshdesk e nossa análise honesta do Freshdesk entram nos prós e contras.
Onde as regras de automação do Freshdesk esbarram em um limite
As regras de automação são boas em exatamente uma coisa: fazer o que você mandou, quando as condições que você escreveu são verdadeiras. Esse também é o teto delas. Toda regra é um palpite que você fez com antecedência sobre a aparência dos tickets, e os tickets raramente cooperam.

Três paredes aparecem repetidamente:
- As regras correspondem a condições, não a significado. Uma regra de criação pode rotear um ticket cujo assunto contém "refund", mas um cliente que escreve "quero meu dinheiro de volta" passa direto por ela. Você acaba mantendo listas de palavras-chave cada vez mais longas, e está sempre a uma formulação de distância de perder um caso.
- A lógica baseada em tempo é grosseira. Os Hourly Triggers só acordam uma vez por hora, então "escalar se não houver resposta em 30 minutos" simplesmente não é algo que dá para expressar. Para filas que se movem rápido, uma hora é uma eternidade.
- Elas não conseguem realmente responder nada. As regras podem rotear, marcar com tags, definir prioridade e pré-preencher uma resposta pronta, mas não conseguem ler uma pergunta e escrever a resposta de verdade. Esse trabalho continua recaindo sobre uma pessoa.
Sentimos isso também do lado comercial. Em uma avaliação, um cliente do Freshdesk não conseguia fazer uma nova regra de automação conviver com o conjunto de regras já existente, as regras viviam disputando a ordem de execução, e ele era repetidamente direcionado de volta ao próprio Freddy AI do Freshdesk quando pedia ajuda ao suporte. O problema não era que as regras fossem ruins; é que empilhar cada vez mais lógica se-então para aproximar a compreensão acaba desmoronando sob o próprio peso. É a mesma lacuna que nossos artigos sobre triagem automática por IA do Freshdesk e marcação por intenção continuam apontando: no momento em que você quer que o sistema entenda o ticket em vez de apenas comparar um campo, você já superou o que o motor de regras consegue oferecer.
Experimente a eesel para os tickets que as regras não alcançam
Se você chegou até aqui, provavelmente já tem suas regras de roteamento bem ajustadas e está encarando a pilha de tickets que elas não conseguem fechar. É exatamente essa lacuna que a eesel AI foi criada para preencher. Ela fica sobre o seu Freshdesk atual (além de Slack, e-mail, Shopify e mais de 100 outras ferramentas), aprende com seus tickets anteriores e documentos de ajuda em minutos, e lê o que cada cliente realmente quis dizer, para poder redigir ou resolver por completo respostas que regras baseadas em palavra-chave nunca conseguiriam dar.
A parte que importa ao lado das regras do Freshdesk: você mantém o controle sobre quais tickets a IA toca. Em vez de um interruptor tudo ou nada, você delimita por tipo de ticket ou nível de confiança, para que ela cuide das perguntas repetitivas e deixe os casos de borda para sua equipe, aquela preocupação de "não vamos deixar a IA responder tudo automaticamente" que trava a maioria das implantações. A cobrança é feita a uma tarifa fixa de $0,40 por resolução, sem taxas por assento e com um limite de gastos definido por você. E, como ela se soma ao Freshdesk em vez de substituí-lo, não há migração alguma para agendar.

Você pode começar com $50 de crédito e sem cartão, apontá-la para seus tickets reais e ver o que ela resolve antes de gastar um centavo. Experimente a eesel e mantenha as regras do Freshdesk que você já construiu; a eesel simplesmente cobre tudo o que elas não alcançam.
Perguntas frequentes
Quais são os três tipos de regras de automação do Freshdesk?
Onde encontro as regras de automação no Freshdesk?
Por que minha regra de automação do Freshdesk não está funcionando?
As regras de automação do Freshdesk exigem um plano pago?
As regras de automação do Freshdesk conseguem realmente responder aos clientes sozinhas?
Qual é a diferença entre regras de automação e automações de cenário no Freshdesk?

Article by
Rama Adi Nugraha
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.








