👤 Para todos os usuários
🔐 Disponível para todos os planos
🎯 Para quem quer que o processo reaja sozinho quando um prazo se aproxima ou vence, sem depender de alguém monitorar a fila
Cards parados são o sinal mais claro de processo em risco. A solicitação está no pipe, o prazo está visível, mas ninguém agiu. Quando isso se repete, o processo perde credibilidade e o time passa a gerenciar urgências em vez de trabalhar com previsibilidade.
Escalonamento automático resolve esse ponto sem depender de alguém monitorar ativamente a fila. O processo reage sozinho quando um prazo se aproxima ou vence, movendo o card e notificando quem precisa agir antes que o problema vire crise.
📖 O que você vai entender aqui:
Três tipos de alerta, três lógicas de prazo
Antes de configurar qualquer automação de escalonamento, é preciso entender qual tipo de prazo você está monitorando. O Pipefy oferece três alertas com lógicas distintas, e cada um responde a uma pergunta diferente.
Alerta de vencimento: o card ultrapassou a data de vencimento definida no formulário? Use para processos em que cada solicitação tem um prazo próprio, como aprovações com deadline específico ou entregas com data acordada com o cliente. O alerta fica amarelo quando a data se aproxima e vermelho quando passa.
Alerta de atraso: o card está na mesma fase há mais tempo do que o permitido? Use quando o gargalo está em uma etapa específica do processo, independente da data do card. Um chamado de suporte que não pode ficar mais de 4 horas em "Análise" usa alerta de atraso na fase, não vencimento no card.
Alerta de expirado: o card está no pipe há mais tempo do que o processo inteiro deveria levar? Use para controlar o SLA end-to-end, quando o risco não está em uma fase específica, mas no tempo total de resolução.
A escolha do alerta define qual evento vai disparar o escalonamento. Escolher errado significa monitorar o sintoma errado.
Quando cada alerta faz sentido
| Situação | Alerta correto |
| Cada card tem um prazo próprio (data negociada, deadline contratual) | Vencimento |
| Uma etapa específica não pode demorar mais que X horas/dias | Atraso (por fase) |
| O processo inteiro não pode levar mais que X dias | Expirado (por pipe) |
Uma armadilha comum: configurar alerta de vencimento quando o problema real é tempo em fase. Se o card foi criado com prazo de 30 dias mas está travado há 5 dias na mesma etapa, o vencimento não vai sinalizar nada por mais 25 dias. O alerta de atraso na fase detecta o problema muito antes.
A lógica do escalonamento: duas automações encadeadas
Independente do tipo de alerta escolhido, o escalonamento por prazo funciona com duas automações que trabalham juntas.
A primeira automação é temporal: roda em intervalos regulares, verifica todos os cards do pipe e move para uma fase de escalonamento aqueles que atendem ao critério de prazo. Funciona como uma varredura periódica da fila.
A segunda automação é reativa: quando um card entra na fase de escalonamento, dispara a notificação para quem precisa agir.
Separar as duas automações é o que torna o sistema robusto. A varredura não precisa saber quem notificar. A notificação não precisa saber qual é o critério de prazo. Cada regra faz uma coisa, e as duas funcionam de forma independente.
Um caso de uso real
Processo: atendimento de chamados de TI com SLA de 5 dias úteis.
Problema: chamados sem resolução chegavam ao quinto dia sem que o gestor soubesse. O time só percebia o descumprimento de SLA depois que o prazo vencia, quando o cliente já estava insatisfeito e o chamado já estava em vermelho no pipe.
O alerta configurado: vencimento no card, com data de vencimento preenchida no formulário inicial.
As duas automações:
Automação 1: varredura de prazo Evento: atividade recorrente a cada hora Condição: campo "data de vencimento" é exatamente 1 dia antes de hoje Ação: mover card para a fase "Escalonamento SLA"
Automação 2: notificação de escalonamento Evento: card entra na fase "Escalonamento SLA" Condição: nenhuma Ação: enviar template de e-mail para o campo "gestor responsável"
Com essa configuração, o gestor recebe o aviso 24 horas antes do vencimento para qualquer chamado ainda aberto. O time passa a resolver ou escalar no dia 4, não descobrir o problema no dia 6.
⚠ A fase de escalonamento não é o destino final do card. Após a notificação, o card ainda precisa ser movido para a resolução, para um nível superior de aprovação ou para reabertura com novo prazo. Defina antes quem é responsável por essa movimentação.
Como definir a antecedência do escalonamento
A configuração de prazo usa lógica relativa, não data fixa. O critério não é "mova quando a data for 15/06". É "mova quando a data de vencimento for exatamente X dias à frente de hoje". Isso significa que a automação funciona para qualquer card criado no futuro, sem precisar ser reconfigurada.
A antecedência ideal depende do tempo real de resolução do problema que o escalonamento deve resolver:
Se o gestor precisa de 1 dia para intervir e resolver, escale com 1 dia de antecedência. Se o processo de escalada envolve mais pessoas e aprovações, escale com 3 a 5 dias. Escalar no dia do vencimento costuma ser tarde demais.
O que observar antes de ativar
A frequência da varredura define a precisão do escalonamento. Para SLAs em dias, uma varredura diária em horário fixo costuma ser suficiente e consome menos tarefas de automação. Para SLAs em horas, a varredura a cada meia hora faz diferença. Ajuste a frequência ao nível de precisão que o processo exige.
Tarefas de automação são contabilizadas em toda varredura. A automação recorrente verifica todos os cards do pipe a cada intervalo, mesmo os que não atendem ao critério de prazo. Em pipes com alto volume de cards abertos, o consumo pode ser significativo. Monitore o uso após ativar.
Cuidado com loops de escalonamento. Se um card é movido para a fase de escalonamento e depois retorna para a fase anterior com o prazo ainda ativo, a próxima varredura vai movê-lo novamente. Avalie se a condição precisa de um filtro adicional para evitar que o mesmo card seja escalonado várias vezes. [⚠ VALIDAR: confirmar se o Pipefy suporta condição de etiqueta ausente para esse filtro]
SLA modificado após card criado não afeta cards existentes. Mudanças na configuração de alerta de atraso ou expirado valem apenas para novos cards e para a primeira vez que um card existente entra em uma fase com SLA. Cards que já estão atrasados não são recalculados.
Antes de avançar, confirme:
☐ Você identificou qual tipo de alerta monitora o prazo correto para o seu processo (vencimento, atraso ou expirado)
☐ O campo de data usado como critério está preenchido nos cards do pipe
☐ A fase de escalonamento existe no pipe antes de criar as automações
☐ Você definiu quem é responsável por mover o card após o escalonamento
☐ As duas automações estão ativas e você acompanhou pelo menos um card passar por elas
