"Vamos responder o mais rápido possível" não é um prazo. Para o cliente, é uma promessa vaga; para a equipe, é impossível de medir. O SLA transforma essa promessa num número: em quanto tempo o pedido será respondido e em quanto tempo será resolvido.
O que é SLA
SLA vem de Service Level Agreement, ou acordo de nível de serviço. No atendimento ao cliente, é a meta de tempo combinada para tratar cada tipo de pedido, conforme a prioridade. Um SLA bem definido responde a três perguntas: o quê (que tipo de pedido), em quanto tempo e contando como (corrido ou em horário útil).
Dois relógios: primeira resposta e resolução
- Primeira resposta: o tempo até alguém da equipe dar o primeiro retorno real ao cliente. Mostra que o pedido foi visto e tem dono.
- Resolução: o tempo até o problema estar resolvido de fato.
Os dois importam, e por motivos diferentes. Uma primeira resposta rápida acalma o cliente; uma resolução no prazo é o que ele lembra. Medir só a resolução esconde a sensação de abandono dos primeiros momentos.
Como contar o prazo em horário útil
Se a equipe trabalha de segunda a sexta, das 8h às 18h, o prazo só deve correr nesse horário. Um exemplo:
| Situação | Conta | Vence |
|---|---|---|
| Caso aberto na sexta, 16h, com SLA de 4 horas úteis | 2 h na sexta (16h–18h) + 2 h na segunda (8h–10h) | segunda, 10h |
| O mesmo caso, com feriado na segunda | 2 h na sexta + 2 h na terça | terça, 10h |
| O mesmo caso, contado em horas corridas | 4 h direto | sexta, 20h |
Contar em horas corridas um atendimento que só funciona no expediente faz a equipe "estourar" prazos durante a madrugada, e o indicador perde o sentido. O calendário do SLA precisa ter o expediente da equipe e os feriados.
Quando o relógio deve parar
Enquanto o caso está aguardando o cliente — um documento, uma informação, um teste —, o prazo deve ficar pausado: a demora não é da equipe. A pausa precisa de regras claras, senão vira esconderijo de atraso:
- só pausa quando o pedido ao cliente está registrado no caso;
- o relógio volta a correr assim que o cliente responde;
- sem resposta depois de um prazo combinado, o caso é encerrado com aviso, e pode ser reaberto.
Prioridade: impacto × urgência
Nem todo pedido tem o mesmo prazo. A forma mais usada de definir a prioridade, herdada do ITIL, cruza o impacto (quantas pessoas ou quanto do negócio é afetado) com a urgência (quão rápido o dano acontece). Um exemplo de tabela — os prazos são ilustrativos, cada empresa define os seus:
| Prioridade | Quando | 1ª resposta | Resolução |
|---|---|---|---|
| P1 — Crítica | Impacto alto e urgência alta: a operação parou | 30 min | 4 h úteis |
| P2 — Alta | Impacto alto ou urgência alta | 1 h | 8 h úteis |
| P3 — Média | Impacto e urgência médios | 4 h | 3 dias úteis |
| P4 — Baixa | Dúvida, pedido de melhoria | 1 dia útil | 10 dias úteis |
Os indicadores que importam
- Percentual resolvido no prazo, por tipo e por prioridade, contra a meta.
- Casos em risco agora: os que já consumiram boa parte do prazo e ainda não foram resolvidos.
- Fila por idade: quantos casos estão abertos há 1, 3, 7, 15 dias.
- Satisfação depois da solução: cumprir o prazo e deixar o cliente insatisfeito também é um problema.
Avisar antes de estourar
O indicador do fim do mês mostra o que já deu errado. O que evita o estouro é o aviso antecipado: quando o caso consome uma fração do prazo — 75%, por exemplo —, o responsável é avisado; se o prazo vencer, o líder também. Assim a fila é reorganizada enquanto ainda dá tempo.
Na prática
No ProjeTeam Atendimento, cada tipo de pedido tem as suas metas de primeira resposta e de resolução, contadas no calendário da equipe, com feriados; "aguardando o cliente" pausa o prazo; com 75% do tempo usado o responsável é avisado, e, vencido, o líder também. O Dashboard do atendimento mostra o resolvido no prazo contra a meta e os casos em risco. Para o suporte de TI interno, a prioridade sai da matriz impacto × urgência — veja a página para empresas de TI.
