SLA estourado: o que fazer antes, durante e depois

SLA estourado é o pesadelo silencioso de qualquer operação de atendimento: o ticket passa do prazo, o cliente percebe antes de você e a confiança começa a derreter. A boa notícia é que um estouro de SLA quase nunca é um evento isolado — ele tem sinais prévios, tem um jeito certo de ser comunicado e deixa lições claras para trás.

Este artigo é um playbook em três tempos: antes (como evitar o estouro com alertas e escalonamento), durante (o que dizer ao cliente quando o prazo já passou, com modelos prontos) e depois (como fazer a análise de causa raiz para não repetir o erro).

Primeiro, o básico: o que conta como SLA estourado

SLA (Service Level Agreement) é o compromisso de prazo firmado com o cliente — tempo de primeira resposta, tempo de resolução ou ambos. O SLA está estourado quando qualquer um desses prazos é ultrapassado sem resposta ou solução registrada.

Dois pontos que muita operação confunde:

• Prazo pausado não é prazo cumprido. Se o ticket ficou "aguardando cliente" por dias, o relógio pode pausar, mas a percepção do cliente não pausa junto. Monitore os dois.
• SLA interno ≠ SLA contratual. O interno deve ser mais apertado que o prometido ao cliente, justamente para criar margem de reação.

Se você ainda não mede SLA de forma estruturada, comece pelo guia de KPIs essenciais de help desk — SLA sem contexto de volume, TMA e backlog vira só um número vermelho no painel.

Antes: como evitar que o SLA estoure

A maior parte dos estouros é previsível. O ticket não passa do prazo de repente — ele envelhece na fila enquanto ninguém olha. Três mecanismos resolvem a maioria dos casos:

1. Alertas preventivos em faixas de risco

Configure alertas escalonados, não um único aviso em cima da hora:

A lógica é simples: aos 50% o agente ainda resolve sozinho; aos 90% já é problema de gestão. Ferramentas como o ClickDesk permitem configurar essas regras por prioridade, canal e tipo de cliente na página de atendimento.

2. Escalonamento automático (não dependa de boa vontade)

Escalonamento manual falha exatamente quando a operação está sobrecarregada — que é quando o SLA mais estoura. Automatize:

• Reatribuição: ticket a 90% do prazo sem resposta muda de fila ou vai para um agente sênior.
• Repriorização: ticket em risco sobe para o topo da fila de todos os agentes disponíveis.
• Notificação de gestão: supervisor recebe alerta com contexto (cliente, prazo, histórico), não só um "ticket #4521 em risco".

3. Capacidade realista

Nenhum alerta salva uma operação subdimensionada. Se os estouros são recorrentes e generalizados, o problema é estrutural: fila crescendo mais rápido do que a equipe resolve. Nesse caso, o caminho é atacar o acúmulo — veja como reduzir o backlog de tickets antes de apertar ainda mais os prazos.

Durante: o SLA estourou. E agora?

Estourou. O pior erro agora é o silêncio. Cliente que espera sem informação abandona o canal, abre ticket duplicado ou escala para a diretoria — e a taxa de abandono da sua operação agradece pelo estrago.

A regra de ouro: comunique antes que o cliente cobre. A mensagem precisa ter quatro elementos:

1. Reconhecimento direto do atraso (sem eufemismo, sem "devido ao alto volume").
2. Status real do que já foi feito.
3. Novo prazo concreto — data e hora, não "em breve".
4. Um dono — nome de quem está cuidando.

Modelos de mensagem de atraso (copie e adapte)

Modelo 1 — atraso na primeira resposta:

Olá, nome. Seu chamado #número deveria ter recebido retorno até prazo original e isso não aconteceu — pedimos desculpas pela falha. Ele já está em análise com nome do agente, e você receberá uma resposta até nova data/hora. Se algo mudar antes disso, avisamos por aqui.

Modelo 2 — atraso na resolução (problema em andamento):

Olá, nome. Atualizando sobre o chamado #número: identificamos que resumo objetivo da causa e a correção está em andamento. O prazo original era data e não conseguimos cumprir — o novo prazo é nova data/hora. Eu, nome, estou acompanhando pessoalmente e te atualizo até lá, mesmo que seja para dizer que ainda estamos trabalhando.

Modelo 3 — atraso sem previsão fechada (use com parcimônia):

Olá, nome. Seu chamado #número passou do prazo que prometemos e ainda não temos uma solução fechada — não vamos te dar uma data que não podemos garantir. O que já sabemos: status. Nosso compromisso: uma atualização a cada período, ex.: 24h até a resolução, começando data/hora. Qualquer avanço, você fica sabendo primeiro.

Modelo 4 — atraso em cliente crítico/contratual:

Olá, nome. Registramos formalmente a violação do SLA no chamado #número, previsto para prazo original. A causa foi causa objetiva e o plano de correção é: passo 1, passo 2, com conclusão prevista para data/hora. Nome, cargo, é o ponto de contato direto até o encerramento: canal. Após a resolução, enviaremos o relatório do ocorrido.

O que nunca fazer

• Culpar o volume. "Estamos com alta demanda" transfere o problema para o cliente.
• Prometer prazo novo sem lastro. Estourar o segundo prazo é muito pior que o primeiro.
• Responder qualquer coisa só para "parar o relógio". Resposta vazia que fecha o SLA no sistema mas não avança o caso destrói a métrica e a confiança ao mesmo tempo.

Depois: análise de causa raiz (ou o estouro vai se repetir)

Resolver o ticket atrasado apaga o incêndio. A análise de causa raiz evita o próximo. Para cada violação relevante — ou para o conjunto delas no fechamento do mês — responda:

As 4 perguntas do post-mortem de SLA

1. Onde o tempo foi perdido? Reconstrua a linha do tempo do ticket: quanto tempo na fila sem dono, quanto em atendimento ativo, quanto aguardando terceiros. O gargalo quase sempre está na espera, não na execução.
2. O alerta funcionou? Se ninguém foi avisado a tempo, o problema é de configuração. Se foi avisado e não agiu, é de processo ou capacidade.
3. Era evitável com informação? Muitos estouros vêm de tickets que ficaram parados esperando dados que o cliente poderia ter enviado no primeiro contato. Formulários melhores e autoatendimento reduzem esse ciclo.
4. É padrão ou exceção? Um estouro isolado num pico atípico pede ajuste fino. Estouros concentrados num tipo de ticket, num canal ou num horário pedem mudança estrutural (escala, roteamento, treinamento).

Transforme em rotina, não em caça às bruxas

O objetivo é corrigir o sistema, não apontar culpados. Consolide as violações num relatório mensal com: total de tickets, % dentro do SLA, violações por prioridade/canal/agente, e as ações corretivas do período. Se ainda não tem esse ritual, o passo a passo está em como montar um relatório de atendimento.

Na prática do mercado, operações que revisam violações de SLA toda semana — mesmo em reuniões de 15 minutos — reduzem reincidência de forma consistente, porque as causas se repetem: fila sem dono, prioridade mal classificada, dependência de outro time sem prazo acordado.

Checklist rápido: playbook do SLA estourado

• SLA interno mais apertado que o contratual
• Alertas em 50% / 75% / 90% do prazo configurados
• Escalonamento automático para tickets em risco
• Modelos de mensagem de atraso salvos como respostas rápidas
• Regra clara: comunicar o cliente antes de ele cobrar
• Post-mortem das violações no fechamento semanal/mensal
• Ações corretivas registradas e acompanhadas

Pare de descobrir o estouro pelo cliente

Se hoje você fica sabendo que o SLA estourou quando o cliente reclama, o problema não é a equipe — é a falta de visibilidade. No ClickDesk, você configura políticas de SLA por prioridade e canal, recebe alertas preventivos antes do estouro e escalona tickets em risco automaticamente, com relatórios de violação prontos para a reunião de gestão.

Conheça os alertas de SLA do ClickDesk e teste grátis por 14 dias, sem cartão de crédito.