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:
- 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 é.
- 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.
- 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.
- 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:
| Prioridade | Critério | Primeira resposta | Resolução |
|---|---|---|---|
| P1 — Crítico | Operação parada, falha geral, impacto direto em faturamento | 1h útil | 4h úteis |
| P2 — Alto | Função importante degradada, vários usuários afetados, com paliativo | 2h úteis | 8h úteis |
| P3 — Médio | Problema pontual, um usuário afetado, operação segue | 4h úteis | 24h úteis (3 dias) |
| P4 — Baixo | Dúvida, solicitação, melhoria, ajuste cosmético | 8h úteis | 40h ú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.
Outros termos do glossário
Meça isso na prática
SLA, CSAT e todas as métricas deste glossário, nativas na ClickDesk. 14 dias grátis.