Temporizadores de SLA e escalonamentos: modelagem de workflow manutenível

Por que regras baseadas em tempo ficam difíceis de manter

Regras baseadas em tempo normalmente começam simples: “Se um ticket não tiver resposta em 2 horas, notifique alguém.” Depois o fluxo cresce, equipes adicionam exceções e, de repente, ninguém tem certeza do que acontece. É assim que temporizadores de SLA e escalonamentos viram um labirinto.

Ajuda nomear as partes móveis de forma clara.

Um temporizador é o relógio que você inicia (ou agenda) após um evento, como “ticket passou para Waiting for Agent”. Um escalonamento é o que você faz quando esse relógio atinge um limite, como notificar um líder, mudar prioridade ou reatribuir o trabalho. Uma violação é o fato registrado que diz “perdemos o SLA”, usado para relatórios, alertas e follow-up.

Problemas aparecem quando a lógica de tempo fica espalhada pelo app: algumas verificações no fluxo de “atualizar ticket”, mais verificações em um job noturno e regras pontuais adicionadas depois para um cliente especial. Cada peça faz sentido isoladamente, mas juntas criam surpresas.

Sintomas típicos:

• O mesmo cálculo de tempo é copiado em vários fluxos, e correções não alcançam todas as cópias.
• Casos de borda passam despercebidos (pausa, retomada, reassignment, alternância de status, fins de semana vs horário comercial).
• Uma regra dispara duas vezes porque dois caminhos agendam temporizadores semelhantes.
• Auditar vira adivinhação: você não consegue responder “por que isso escalou?” sem ler o app inteiro.
• Pequenas mudanças parecem arriscadas, então as equipes adicionam exceções em vez de consertar o modelo.

O objetivo é comportamento previsível e fácil de alterar depois: uma fonte única de verdade para o tempo de SLA, estados de violação explícitos que você pode reportar e passos de escalonamento que podem ser ajustados sem caçar a lógica visual.

Comece definindo o SLA que você realmente precisa

Antes de construir temporizadores, escreva a promessa exata que você está medindo. Muito da lógica confusa vem de tentar cobrir todas as regras de tempo desde o dia 1.

Tipos comuns de SLA parecem semelhantes, mas medem coisas diferentes:

• Primeira resposta: tempo até um humano enviar a primeira resposta significativa.
• Resolução: tempo até o problema ser realmente fechado.
• Waiting on customer: tempo que você não quer contar enquanto está bloqueado.
• Handoff interno: tempo que um ticket pode ficar em uma fila específica.
• SLA de reabertura: o que acontece quando um item “fechado” volta.

Em seguida, decida o que “tempo” significa. Tempo de calendário conta 24/7. Tempo de trabalho conta apenas horas comerciais definidas (por exemplo, seg-sex, 9h–18h). Se você não precisa realmente de tempo de trabalho, evite-o no início. Ele adiciona casos de borda como feriados, fusos e dias parciais.

Depois, seja específico sobre pausas. Uma pausa não é só “status mudou.” É uma regra com dono. Quem pode pausar (apenas agente, apenas sistema, ação do cliente)? Quais status pausam (Waiting on Customer, On Hold, Pending Approval)? O que retoma? Ao retomar, você continua com o tempo restante ou reinicia o temporizador?

Por fim, defina o que uma violação significa em termos do produto. Uma violação deve ser algo concreto que você possa armazenar e consultar, por exemplo:

• uma flag de violação (true/false)
• um timestamp de violação (quando o prazo foi perdido)
• um estado de violação (Aproximando, Violado, Resolvido após violação)

Exemplo: “First response SLA breached” pode significar que o ticket ganha um estado Violado, um breached_at timestamp e um nível de escalonamento definido como 1.

Modele SLA como estados explícitos, não condições espalhadas

Se você quer que temporizadores e escalonamentos de SLA continuem legíveis, trate o SLA como uma pequena máquina de estados. Quando a “verdade” é espalhada por verificações pequenas (se agora > due, se prioridade é alta, se última resposta está vazia), a lógica visual fica confusa rápido e pequenas mudanças quebram coisas.

Comece com um conjunto curto e combinado de estados de SLA que todo passo do fluxo entenda. Para muitas equipes, estes cobrem a maioria dos casos:

• Em dia
• Aviso
• Violado
• Pausado
• Concluído

Uma única flag breached = true/false raramente é suficiente. Você ainda precisa saber qual SLA violou (primeira resposta vs resolução), se está atualmente pausado e se você já escalou. Sem esse contexto, as pessoas começam a derivar significado de comentários, timestamps e nomes de status. É aí que a lógica fica frágil.

Torne o estado explícito e armazene os timestamps que o expliquem. Então as decisões ficam simples: seu avaliador lê o registro, decide o próximo estado e todo o resto reage a esse estado.

Campos úteis para armazenar junto ao estado:

• started_at e due_at (qual relógio estamos rodando e quando vence?)
• breached_at (quando realmente ultrapassou o prazo?)
• paused_at e paused_reason (por que o relógio parou?)
• breach_reason (qual regra disparou a violação, em termos claros)
• last_escalation_level (para não notificar o mesmo nível duas vezes)

Exemplo: um ticket passa para “Waiting on customer.” Defina o estado de SLA para Pausado, registre paused_reason = "waiting_on_customer" e pare o temporizador. Quando o cliente responder, retome definindo um novo started_at (ou despausando e recalculando due_at). Sem caçar muitas condições.

Projete uma escada de escalonamento que caiba na sua organização

Uma escada de escalonamento é um plano claro do que acontece quando um temporizador de SLA está perto de violar ou já violou. O erro é copiar o organograma para o fluxo. Você quer o menor conjunto de passos que faça o item parado voltar a andar.

Uma escada simples que muitas equipes usam: o agente designado (Nível 0) recebe o primeiro lembrete, depois o líder de equipe (Nível 1) é acionado, e só depois disso vai para um gerente (Nível 2). Funciona porque começa onde o trabalho pode ser feito e só escala a autoridade quando necessário.

Para manter as regras de escalonamento fáceis de manter, armazene limites de escalonamento como dados, não condições codificadas. Coloque-os em uma tabela ou objeto de configurações: “primeiro lembrete após 30 minutos” ou “escalar para líder após 2 horas.” Quando a política mudar, você atualiza um lugar em vez de editar vários fluxos.

Mantenha os escalonamentos úteis, não barulhentos

Escalonamentos viram spam quando disparam com muita frequência. Adicione salvaguardas para que cada passo tenha um propósito:

• Uma regra de retry (por exemplo, reenvie para Nível 0 uma vez se não houver ação).
• Uma janela de cooldown (por exemplo, não enviar notificações de escalonamento por 60 minutos após uma enviada).
• Uma condição de parada (cancele futuros escalonamentos assim que o item mudar para um status conforme).
• Um nível máximo (não passe de Nível 2 a menos que um humano dispare manualmente).

Decida quem fica responsável após o escalonamento

Notificações sozinhas não resolvem trabalho parado se a responsabilidade ficar confusa. Defina regras de ownership: o ticket continua atribuído ao agente, é reatribuído ao líder, ou vai para uma fila compartilhada?

Exemplo: após escalonamento Nível 1, reatribua ao líder de equipe e marque o agente original como observador. Isso deixa claro quem deve agir a seguir e evita que o item fique quicando entre pessoas.

Um padrão de manutenção: eventos, avaliador, ações

A maneira mais fácil de manter temporizadores e escalonamentos de SLA é tratá‑los como um pequeno sistema com três partes: eventos, um avaliador e ações. Isso evita que a lógica de tempo se espalhe por dezenas de verificações “se tempo > X”.

1) Eventos: registre apenas o que aconteceu

Eventos são fatos simples que não devem conter cálculos de tempo. Eles respondem “o que mudou?” e não “o que devemos fazer sobre isso?” Eventos típicos incluem ticket criado, agente respondeu, cliente respondeu, status alterado, ou pausa/retomada manual.

Armazene-os como timestamps e campos de status (por exemplo: created_at, last_agent_reply_at, last_customer_reply_at, status, paused_at).

2) Avaliador: um único lugar que calcula tempo e define estado

Faça um único passo “avaliador de SLA” que rode após qualquer evento e em uma agenda periódica. Esse avaliador é o único lugar que calcula due_at e tempo restante. Ele lê os fatos atuais, recalcula prazos e escreve campos de estado de SLA explícitos como sla_response_state e sla_resolution_state.

É aqui que a modelagem de estado de violação fica limpa: o avaliador define estados como OK, Em risco, Violado, em vez de esconder lógica dentro de notificações.

3) Ações: reaja às mudanças de estado, não à matemática do tempo

Notificações, atribuições e escalonamentos devem disparar apenas quando um estado mudar (por exemplo: OK -> Aviso). Mantenha o envio de mensagens separado da atualização do estado de SLA. Assim você pode mudar quem é notificado sem tocar nos cálculos.

Passo a passo: construa temporizadores e escalonamentos em lógica visual

Uma configuração de fácil manutenção geralmente se parece com isto: alguns campos no registro, uma pequena tabela de políticas e um avaliador que decide o que acontece a seguir.

1) Configure dados para que a lógica de tempo tenha uma casa só

Comece com a entidade que possui o SLA (ticket, pedido, requisição). Adicione timestamps explícitos e um único campo “estado atual do SLA”. Mantenha simples e previsível.

Depois, adicione uma pequena tabela de políticas que descreva regras em vez de codificá‑las em muitos fluxos. Uma versão simples é uma linha por prioridade (P1, P2, P3) com colunas para minutos-alvo e limites de escalonamento (por exemplo: aviso em 80%, violação em 100%). A diferença entre mudar um registro e editar cinco fluxos é grande.

2) Rode um avaliador agendado, não dezenas de timers

Em vez de criar temporizadores separados por todo lado, use um processo agendado que verifique itens periodicamente (a cada minuto para SLAs estritos, a cada 5 minutos para muitas equipes). A agenda chama um avaliador que:

• seleciona registros ainda ativos (não fechados)
• calcula “agora vs due” e deriva o próximo estado
• calcula o próximo momento de verificação (para pular checagens desnecessárias)
• grava sla_state e next_check_at

Isso facilita porque você depura um avaliador, não muitos timers.

3) Faça ações baseadas em borda (apenas na mudança)

O avaliador deve emitir tanto o novo estado quanto se ele mudou. Só dispare mensagens ou crie tarefas quando o estado mudar (por exemplo Em dia -> Aviso, Aviso -> Violado). Se o registro permanecer Violado por uma hora, você não quer 12 notificações repetidas.

Um padrão prático: armazene sla_state e last_escalation_level, compare com os valores recém calculados e só então chame o sistema de mensagens (email/SMS/Telegram) ou crie uma tarefa interna.

Lidando com pausas, retomadas e mudanças de status

Pausas são onde regras de tempo geralmente se complicam. Se você não as modelar claramente, seu SLA ou continua rodando quando não deveria, ou reinicia quando alguém clica no status errado.

Uma regra simples: apenas um status (ou um pequeno conjunto) pausa o relógio. Uma escolha comum é Waiting for customer. Quando um ticket vai para esse status, registre um timestamp pause_started_at. Quando o cliente responde e o ticket sai desse status, feche a pausa escrevendo pause_ended_at e some a duração em paused_total_seconds.

Não mantenha só um contador. Capture cada janela de pausa (início, fim, quem ou o que a desencadeou) para ter trilha de auditoria. Depois, quando alguém perguntar por que um caso violou, você pode mostrar que ficou 19 horas esperando o cliente.

Reatribuição e mudanças normais de status não devem reiniciar o relógio. Mantenha timestamps de SLA separados dos campos de ownership. Por exemplo, sla_started_at e sla_due_at devem ser definidos uma vez (na criação ou quando a política muda), enquanto reassignment só atualiza assignee_id. Seu avaliador então calcula tempo decorrido como: agora menos sla_started_at menos paused_total_seconds.

Regras que mantêm temporizadores e escalonamentos previsíveis:

• Pause apenas em status explícitos (como Waiting for customer), não em flags suaves.
• Retome apenas ao sair desse status, não em qualquer mensagem recebida.
• Nunca reinicie o SLA em reassignment; trate como roteamento, não caso novo.
• Permita overrides manuais, mas exija um motivo e limite quem pode fazer.
• Registre cada mudança de status e janela de pausa.

Cenário de exemplo: ticket de suporte com SLAs de resposta e resolução

Uma forma simples de testar seu design é um ticket com dois SLAs: primeira resposta em 30 minutos e resolução completa em 8 horas. É aí que a lógica costuma quebrar se estiver espalhada por telas e botões.

Suponha que cada ticket guarde: state (New, InProgress, WaitingOnCustomer, Resolved), response_status (Pending, Warning, Breached, Met), resolution_status (Pending, Warning, Breached, Met), além de timestamps como created_at, first_agent_reply_at e resolved_at.

Linha do tempo realista:

• 09:00 Ticket criado (New). Temporizadores de resposta e resolução começam.
• 09:10 Atribuído ao Agente A (ainda Pending para ambos SLAs).
• 09:25 Sem resposta do agente. Resposta atinge 25 minutos e vira Aviso.
• 09:40 Ainda sem resposta. Resposta atinge 30 minutos e vira Violado.
• 09:45 Agente responde. Resposta vira Met (mesmo que tenha sido Violado, mantenha o registro da violação e marque Met para relatórios).
• 10:30 Cliente responde com mais informações. Ticket vai para InProgress e a resolução continua.
• 11:00 Agente faz uma pergunta. Ticket vai para WaitingOnCustomer e o temporizador de resolução pausa.
• 14:00 Cliente responde. Ticket volta a InProgress e o temporizador de resolução retoma.
• 16:30 Ticket resolvido. Resolução vira Met se o tempo ativo total estiver abaixo de 8 horas, caso contrário Violado.

Para escalonamentos, mantenha uma cadeia clara que dispare em transições de estado. Por exemplo, quando resposta virar Aviso, notifique o agente responsável. Quando virar Violado, notifique o líder de equipe e atualize a prioridade.

Em cada passo, atualize o mesmo pequeno conjunto de campos para ficar fácil de raciocinar:

• Defina response_status ou resolution_status para Pending, Warning, Breached ou Met.
• Grave *_warning_at e *_breach_at timestamps uma vez e nunca os sobrescreva.
• Incremente escalation_level (0, 1, 2) e defina escalated_to (Agent, Lead, Manager).
• Adicione uma linha no log sla_events com o tipo de evento e quem foi notificado.
• Se necessário, ajuste priority e due_at para que UI e relatórios mostrem o escalonamento.

A chave é que Aviso e Violado são estados explícitos. Você os vê nos dados, audita e muda a escada depois sem caçar verificações de tempo escondidas.

Armadilhas comuns e como evitá‑las

A lógica de SLA fica bagunçada quando se espalha. Uma verificação rápida de tempo adicionada a um botão aqui, um alerta condicional ali e logo ninguém explica por que um ticket escalou. Mantenha temporizadores e escalonamentos como uma peça pequena e central de lógica que todas as telas e ações consultem.

Uma armadilha comum é embutir checagens de tempo em muitos lugares (telas de UI, handlers de API, ações manuais). A correção é computar o status de SLA em um avaliador e armazenar o resultado no registro. As telas devem ler o status, não inventá‑lo.

Outra armadilha é deixar timers discordarem porque usam relógios diferentes. Se o navegador calcula “minutos desde criado” e o backend usa tempo do servidor, você verá casos de borda com suspensão, fusos e mudanças de horário. Prefira tempo do servidor para qualquer coisa que dispare um escalonamento.

Notificações também podem virar barulho rapidamente. Se você “verifica a cada minuto e envia se atrasado”, as pessoas podem receber spam a cada minuto. Vincule mensagens a transições: “aviso enviado”, “escalado”, “violado”. Assim você envia uma vez por etapa e pode auditar o que aconteceu.

A lógica de horas comerciais é outra fonte de complexidade acidental. Se cada regra tem seu próprio “se for fim de semana então…”, atualizações ficam penosas. Coloque a matemática de horas comerciais em uma função (ou bloco compartilhado) que retorne “minutos de SLA consumidos até agora” e reutilize-a.

Por fim, não confie em recomputar a violação do zero. Armazene o momento em que ocorreu:

• Salve breached_at na primeira vez que detectar uma violação e nunca o sobrescreva.
• Salve escalation_level e last_escalated_at para que ações sejam idempotentes.
• Salve notified_warning_at (ou similar) para evitar alertas repetidos.

Exemplo: um ticket atinge “Response SLA breached” às 10:07. Se você só recomputar, uma mudança de status posterior ou bug de pausa/retomada pode fazer parecer que a violação aconteceu às 10:42. Com breached_at = 10:07, relatórios e postmortems permanecem consistentes.

Checklist rápido para lógica de SLA mantível

Antes de adicionar timers e alertas, faça uma passada com o objetivo de tornar as regras legíveis daqui a um mês.

• Cada SLA tem limites claros. Escreva o evento exato de início, evento de parada, regras de pausa e o que conta como violação. Se você não aponta um evento único que inicia o relógio, a lógica se espalhará em condições aleatórias.
• Escalonamentos são uma escada, não um monte de alertas. Para cada nível, defina o limite (ex.: 30m, 2h, 1d), quem recebe, um cooldown (para não spam) e o nível máximo.
• Mudanças de estado são logged com contexto. Quando um estado de SLA muda (Running, Paused, Breached, Resolved), grave quem disparou, quando e por quê.
• Checagens agendadas são seguras para rodar duas vezes. Seu avaliador deve ser idempotente: se rodar de novo para o mesmo registro, não deve criar escalonamentos duplicados nem reenviar a mesma notificação.
• Notificações vêm de transições, não da matemática crua do tempo. Envie alertas quando o estado muda, não quando “agora - created_at > X” for verdadeiro.

Um teste prático: escolha um ticket perto de violar e reproduza sua linha do tempo. Se você não consegue explicar o que acontecerá a cada mudança de status sem ler todo o fluxo, seu modelo está espalhado demais.

Próximos passos: implemente, observe e refine

Construa a menor fatia útil primeiro. Escolha um SLA (por exemplo, primeira resposta) e um nível de escalonamento (por exemplo, notificar o líder da equipe). Você vai aprender mais em uma semana de uso real do que em um design perfeito no papel.

Mantenha limites e destinatários como dados, não lógica. Coloque minutos e horas, regras de horas úteis, quem recebe notificações e qual fila possui o caso em tabelas ou registros de configuração. Assim o fluxo fica estável enquanto o negócio ajusta números e roteamento.

Planeje uma visão de dashboard simples desde cedo. Você não precisa de um grande sistema de analytics, apenas uma visão compartilhada do que está acontecendo agora: em dia, aviso, violado, escalado.

Se estiver construindo isso em uma ferramenta no‑code, escolha uma plataforma que permita modelar dados, lógica e avaliadores agendados em um só lugar. Por exemplo, AppMaster (appmaster.io) suporta modelagem de banco, processos visuais e geração de apps prontos para produção, o que se encaixa bem com o padrão “eventos, avaliador, ações”.

Refine com segurança seguindo esta ordem:

1. Adicione um novo nível de escalonamento só depois que o Nível 1 se comportar bem
2. Expanda de um SLA para dois (resposta e resolução)
3. Adicione regras de pausa/retomada (waiting on customer, on hold)
4. Ajuste notificações (deduplicar, horas silenciosas, destinatários corretos)
5. Revise semanalmente: altere limites nos dados, não refaça o fluxo

Quando estiver pronto, construa uma versão pequena primeiro e cresça com feedback real e tickets reais.