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:
- O cliente responde — qualquer conversa adiada reabre automaticamente ao receber uma nova mensagem do cliente (comportamento padrão do Cloud Chat, independente do prazo).
- 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 etiquetafollowup-1
- Evento: Conversa Atualizada · Condição: tem a tag
- 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+ Adicionarfollowup-2
- Evento: Conversa Atualizada · Condição: tem a tag
- Regra 3 — Encerrar
- Evento: Conversa Atualizada · Condição: tem a tag
followup-2 - Ações: Enviar mensagem final + Resolver + Remover
followup-2
- Evento: Conversa Atualizada · Condição: tem a tag
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.