Principal Primeiros passos do administrador Automações de Adiar (snooze) com prazo

Automações de Adiar (snooze) com prazo

Última atualização em Jul 20, 2026

Quando usar

  • Você quer que uma automação coloque a conversa em Adiada (snooze) e reabra sozinha depois de um tempo.
  • Você quer escolher por quanto tempo a conversa fica adiada (1 hora, até amanhã, 1 mês, tempo personalizado).
  • Você está montando um fluxo de follow-up e precisa que o ticket volte no momento certo.
  • Você caiu no problema mais comum: a automação de Adiar fica re-adiando a conversa toda vez que o cliente responde ("loop").

O que a ação faz

A ação de automação Adiar Conversa coloca a conversa no estado Adiada (snoozed). Agora você pode escolher quando ela deve reabrir:

Opção O que faz
Até a próxima mensagem do usuário Adia sem prazo: reabre quando o cliente responder
Em 1 hora Reabre 1h depois de a regra rodar
Até amanhã Reabre amanhã de manhã (9h)
Até semana que vem Reabre na próxima segunda (9h)
Por 1 mês Reabre no início do próximo mês (9h)
Tempo personalizado Você define a duração (nº + horas/dias/semanas)

O prazo é sempre relativo ao momento em que a regra dispara (ex.: "em 1 hora" = 1h a partir de agora), nunca uma data fixa.


Como cada prazo é calculado

Contando sempre a partir do momento em que a regra dispara:

Opção Reabre em…
Até a próxima mensagem do usuário Sem horário fixo — só reabre quando o cliente responder
Em 1 hora Exatamente 1 hora depois do disparo (disparou 14h37 → reabre 15h37)
Até amanhã No dia seguinte, às 9h
Até semana que vem Na próxima segunda-feira, às 9h
Por 1 mês Na primeira segunda-feira do mês seguinte, às 9h
Tempo personalizado Agora + a duração escolhida (nº × horas/dias/semanas), com limite de 1 ano

Detalhes que evitam surpresa:

  • As opções "até amanhã / semana que vem / 1 mês" sempre caem às 9h (começo do expediente), e não no horário exato em que a regra rodou.
  • "Por 1 mês" não é "30 dias corridos" nem "mesmo dia do mês que vem": é a primeira segunda-feira do próximo mês, para o ticket voltar no começo de uma semana útil.
  • "Em 1 hora" mantém os minutos do disparo (não arredonda para a hora cheia).
  • Essas regras são idênticas às do adiar manual — a automação apenas reaproveita a mesma lógica.

Como uma conversa adiada volta a abrir

Existem dois caminhos para uma conversa adiada reabrir:

  1. O cliente responde — qualquer conversa adiada reabre automaticamente ao receber uma nova mensagem do cliente (comportamento padrão do Cloud Chat, independente do prazo).
  2. O prazo vence — se você adiou com prazo, ela reabre sozinha quando o prazo chega.

Ponto de atenção: o "loop" de re-adiar

Este é o comportamento que mais gera dúvida.

Se você cria uma automação de Adiar no evento Conversa Atualizada com uma condição que continua verdadeira (ex.: uma tag que permanece na conversa), ela vai re-adiar a conversa toda vez que o cliente responder.

Por quê: quando o cliente responde, a conversa reabre. Essa reabertura conta como uma "atualização" da conversa → a regra dispara de novo → e, como a condição (a tag) ainda está lá, ela adia outra vez. Vira um ciclo.

Isso não é um erro — é o funcionamento natural de automações orientadas a evento. O que resolve é desenhar a regra para não se repetir.


Boas práticas: como evitar o loop

A ideia central: faça a regra "consumir" o que a disparou, para o gatilho valer só uma vez.

Opção A — Remover a tag que disparou a regra (mais simples)

Na mesma regra, adicione duas ações:

  • Adiar Conversa → (o período desejado)
  • Remover etiqueta → a tag do gatilho

Assim, quando a conversa reabrir na resposta do cliente, a condição (tag = X) já é falsa → a regra não re-adia.

Opção B — Usar um atributo personalizado como "etapa/flag"

Em vez de uma tag, use um atributo personalizado (ex.: followup_etapa) e vá avançando/limpando ele a cada passo. Útil quando você quer controlar quantas vezes a automação roda.

Escolha o evento certo

  • Conversa Criada → dispara só quando o ticket nasce (não re-dispara em respostas). Ideal para "adiar todo ticket novo de tal caixa de entrada". Obs.: condições por tag geralmente não funcionam aqui, porque tags costumam ser aplicadas depois da criação.
  • Conversa Atualizada → necessário para gatilhos por tag/atributo (aplicados depois da criação). Aqui, use sempre o padrão de consumir a tag (Opção A/B) para não repetir.

Exemplo prático: fluxo de follow-up

Objetivo: "conversa marcada com a tag follow-up → esperar X, mandar mensagem, esperar de novo, e fechar se o cliente não responder".

  • Regra 1 — Inicia
    • Evento: Conversa Atualizada · Condição: tem a tag follow-up
    • Ações: Adiar (ex.: por 1 dia) + Remover etiqueta follow-up + Adicionar etiqueta followup-1
  • Regra 2 — Follow-up
    • Evento: Conversa Atualizada · Condição: tem a tag followup-1
    • Ações: Enviar mensagem (follow-up) + Adiar (ex.: por 1 dia) + Remover followup-1 + Adicionar followup-2
  • Regra 3 — Encerrar
    • Evento: Conversa Atualizada · Condição: tem a tag followup-2
    • Ações: Enviar mensagem final + Resolver + Remover followup-2

Cada regra remove sua própria tag e passa a próxima — por isso não há loop, e a sequência anda de forma controlada. Se o cliente responder no meio, a conversa reabre e o atendimento humano assume normalmente.


Observações

Do's & don'ts:

  • ✅ Toda regra de Adiar por tag deve remover a tag que a disparou (ou usar atributo como etapa).
  • ✅ Para adiar tickets novos, prefira o evento Conversa Criada.
  • ✅ Use o prazo quando quiser reabrir sozinho depois de um tempo; use "até a próxima mensagem" quando quiser reabrir só na resposta do cliente.
  • ❌ Não deixe uma regra de Adiar em Conversa Atualizada com uma condição que nunca deixa de ser verdadeira — ela vai re-adiar a cada resposta.