O que é SLA de atendimento: definição, tipos e tabela pronta por prioridade

SLA (Service Level Agreement, ou acordo de nível de serviço) é o compromisso formal de prazo que sua empresa assume com o cliente: em quanto tempo um chamado recebe a primeira resposta e em quanto tempo é resolvido. No atendimento, o SLA transforma "vamos responder o quanto antes" — uma promessa que não se mede — em "respondemos em até 4 horas úteis" — uma promessa que se cumpre ou se quebra, com registro.

Sem SLA, a fila de tickets vira ordem de chegada temperada por quem grita mais alto. Com SLA, cada chamado tem um relógio, e o time sabe exatamente qual atender primeiro.

SLA, SLO e prazo interno: qual a diferença?

Três termos que se confundem na prática:

  • SLA é o acordo com o cliente — o prazo comunicado externamente, às vezes com penalidade contratual (comum em B2B e contratos de suporte).
  • SLO (Service Level Objective) é a meta interna, normalmente mais apertada que o SLA. Se o SLA promete 8 horas, o time trabalha para 4 — a folga absorve imprevistos.
  • Prazo interno de escalonamento é o gatilho operacional: "se o ticket P1 não teve resposta em 1 hora, notifique o supervisor".

Para times pequenos, tratar os três como uma coisa só funciona. Mas quando o suporte cresce, separar meta interna de promessa externa é o que evita quebrar acordo por causa de um dia atípico.

Os dois tipos de SLA que todo time precisa medir

SLA de primeira resposta

Mede o tempo entre o cliente abrir o chamado e receber a primeira resposta humana e útil — não a confirmação automática de recebimento. É o SLA que mais afeta a percepção do cliente: quem recebe um "já estamos analisando, aqui está o que sabemos até agora" em 30 minutos tolera esperar mais pela solução. Quem fica no vácuo por um dia já formou opinião, mesmo que o problema seja resolvido depois.

SLA de resolução

Mede o tempo entre a abertura e a solução efetiva do chamado. É o SLA que afeta o resultado: primeira resposta rápida com resolução arrastada é anestesia, não tratamento.

Um detalhe que muita gente erra: o relógio do SLA de resolução deve pausar quando o ticket está aguardando o cliente. Se você pediu um print e o cliente demorou dois dias para enviar, esses dois dias não contam contra o seu time. Ferramentas sérias fazem essa pausa automaticamente com base no status do ticket.

Alguns times maduros acompanham um terceiro tipo — o SLA de próxima resposta (tempo máximo entre interações depois da primeira), útil para evitar que tickets longos "esfriem" no meio da conversa. Comece pelos dois primeiros; adicione este quando os básicos estiverem sob controle.

Como definir SLA por prioridade

SLA único para tudo é um erro clássico: ou o prazo é apertado demais para dúvidas simples (e o time vive no vermelho), ou folgado demais para incidentes graves (e o cliente crítico espera na mesma fila do "como troco minha senha"). O caminho é classificar por prioridade, com critérios objetivos:

  1. Defina o que é cada prioridade em termos de impacto, não de sentimento. "P1 = cliente sem conseguir operar / falha que afeta faturamento" é objetivo. "P1 = cliente irritado" não é.
  2. Olhe seu histórico antes de prometer. Puxe o tempo real de primeira resposta e resolução dos últimos 60–90 dias. Prometa algo que você cumpre em 90–95% dos casos hoje — e aperte gradualmente.
  3. Decida entre horas úteis e horas corridas. Se o suporte funciona em horário comercial, o SLA deve contar em horas úteis; prometer "4 horas corridas" com time que sai às 18h é quebrar SLA toda noite. Suporte 24/7 para P1 é decisão de negócio (e de custo), não padrão.
  4. Amarre prioridade a formulário, não a achismo. Campos como "quantos usuários afetados?" e "consegue operar?" no formulário de abertura permitem classificar — e até rotear — automaticamente.

Tabela de SLA pronta para copiar

Um ponto de partida realista para times B2B de suporte em horário comercial (seg–sex, 9h–18h). Ajuste aos seus números:

PrioridadeCritérioPrimeira respostaResolução
P1 — CríticoOperação parada, falha geral, impacto direto em faturamento1h útil4h úteis
P2 — AltoFunção importante degradada, vários usuários afetados, com paliativo2h úteis8h úteis
P3 — MédioProblema pontual, um usuário afetado, operação segue4h úteis24h úteis (3 dias)
P4 — BaixoDúvida, solicitação, melhoria, ajuste cosmético8h úteis40h úteis (5 dias)

Duas regras de operação que fazem essa tabela funcionar:

  • Alerta em 75–80% do prazo. Não espere estourar para agir — configure notificação quando o ticket consumir 75% do SLA, com escalonamento para o supervisor.
  • Meta de cumprimento entre 90% e 95%, não 100%. Perseguir 100% leva o time a inflar prazos ou "resolver" no papel. Os 5–10% que estouram merecem análise de causa, não punição.

Se quiser aprofundar as métricas que orbitam o SLA — tempo de primeira resposta, tempo médio de resolução, CSAT — o glossário de atendimento tem os termos vizinhos.

Erros comuns ao implementar SLA de atendimento

  • Prometer sem medir antes. SLA definido em reunião comercial, sem olhar a capacidade real do time, nasce quebrado.
  • Contar hora corrida com time em horário comercial. O relógio precisa respeitar o expediente e os feriados — senão todo ticket aberto na sexta à noite "estoura" no sábado.
  • Não pausar o relógio quando a bola está com o cliente. Infla artificialmente as violações e desmoraliza a métrica perante o time.
  • Responder qualquer coisa para "bater o SLA". Mensagem vazia dentro do prazo cumpre a letra e mata o espírito. Cruze SLA com CSAT: prazo cumprido com nota baixa é sintoma, não sucesso.
  • SLA igual para todos os clientes. Planos enterprise, contratos com penalidade e clientes estratégicos costumam justificar políticas distintas por segmento.
  • Definir e nunca revisar. Time cresceu, produto mudou, volume dobrou — revise a tabela a cada trimestre com os relatórios na mão.
  • Usar violação de SLA como métrica de punição individual. O SLA mede o sistema (volume, escala, ferramentas), não só o esforço de cada atendente. Estouro recorrente geralmente é problema de dimensionamento ou de roteamento.

Como o ClickDesk aplica SLA na prática

No ClickDesk, o SLA não é um relatório que você confere depois — é parte do fluxo de trabalho:

  • Políticas de SLA por funil. Cada funil kanban de atendimento tem suas próprias regras de prazo por prioridade, então o funil de suporte técnico pode ter SLAs diferentes do funil financeiro.
  • Horários de atendimento integrados. Você cadastra o expediente do time e o relógio do SLA conta apenas horas úteis — tickets abertos fora do horário começam a contar na abertura do próximo expediente.
  • Prazo visível no ticket. O atendente vê quanto tempo resta em cada chamado, e as visualizações salvas permitem ordenar a fila por SLA em risco — quem está perto de estourar sobe.
  • Automações e gatilhos notificam responsáveis, escalam prioridade ou transferem o ticket quando o prazo se aproxima do limite.
  • Roteamento e formulários personalizados classificam a prioridade na entrada, para que o SLA certo seja aplicado sem triagem manual.
  • Relatórios exportáveis mostram cumprimento por período, funil e atendente — a base para revisar a tabela a cada trimestre.

E como IA também conta para o relógio: os agentes de IA resolvem as dúvidas repetitivas na hora, tirando volume da fila e liberando o time humano para os P1 e P2 — que é onde o SLA realmente decide a relação com o cliente.

Comece com uma tabela simples e cumpra

SLA de atendimento não precisa nascer perfeito. Copie a tabela acima, ajuste aos seus tempos reais, configure alertas antes do estouro e revise por trimestre. A diferença entre um suporte que promete e um que cumpre está menos na ambição do prazo e mais na disciplina de medi-lo.

Quer ver políticas de SLA com horários de atendimento funcionando no seu fluxo? Teste o ClickDesk grátis por 14 dias — sem cartão de crédito.

Meça isso na prática

SLA, CSAT e todas as métricas deste glossário, nativas na ClickDesk. 14 dias grátis.