Como definir SLA de atendimento por canal sem criar promessas impossíveis

Um SLA útil não é o menor número que cabe em um slide. É uma promessa que combina expectativa do cliente, capacidade real, prioridade, calendário e uma ação clara quando o prazo corre risco.

Separe promessa externa, meta interna e indicador

SLA costuma ser usado para três coisas diferentes: a promessa comunicada ao cliente, a meta operacional da equipe e o indicador exibido no painel. Misturar essas camadas gera conflito. A operação pode perseguir uma meta interna mais rigorosa, mas o cliente precisa receber uma expectativa que a empresa consegue sustentar nos canais e horários publicados. Antes de escolher minutos ou horas, escreva qual experiência será protegida e qual decisão a medição deve orientar.

A documentação da Zendesk descreve SLA como uma política que mede tempos de resposta e resolução. O Google SRE separa indicador, objetivo e acordo: primeiro se define o comportamento importante, depois a meta e, quando aplicável, a consequência do compromisso. Para atendimento, essa disciplina evita transformar uma média histórica em contrato sem analisar capacidade, risco e custo. Uma meta precisa ter um dono e uma resposta prevista quando não for cumprida.

Crie uma ficha por promessa: público atendido, canais incluídos, horário, prioridade, início, pausa, fim, meta, comunicação e tratamento da violação. Se houver acordo comercial, jurídico ou regulatório, valide-o com as áreas responsáveis. Este guia organiza o processo operacional; não substitui revisão contratual. Uma promessa externa deve ser simples de explicar, enquanto a regra interna pode guardar a precisão necessária para auditoria.

Respeite o canal sem criar quatro operações

WhatsApp, Instagram, e-mail e chat não precisam ter o mesmo tempo de primeira resposta. Um chat apresentado como síncrono exige disponibilidade imediata; um e-mail pode aceitar uma janela maior. Ainda assim, evite quatro modelos incompatíveis. Mantenha a mesma taxonomia de prioridade, os mesmos donos e os mesmos estados, variando calendário e meta apenas quando a experiência realmente muda. Isso permite transferir uma conversa sem perder a regra ou recomeçar o relógio.

Não confunda velocidade do canal com gravidade do caso. Uma cobrança duplicada recebida por e-mail pode ser mais urgente do que uma dúvida simples no chat. Primeiro classifique impacto e urgência; depois aplique a meta correspondente ao canal e ao tipo de trabalho. A fila deve mostrar tempo restante, idade e risco, não apenas ordenar pela mensagem mais recente. Use o guia de regras de escalonamento para definir quem assume casos em risco.

Comece com poucas faixas: primeira resposta normal, primeira resposta prioritária, próxima atualização e resolução quando ela estiver sob controle da equipe. Dependências externas pedem uma promessa de acompanhamento, não um prazo de solução inventado. Diferencie também cliente esperando equipe de equipe esperando cliente. O estado precisa explicar por que o relógio corre ou pausa, sem esconder conversas que continuam abertas e relevantes para o cliente.

Defina o relógio antes de escolher o número

Todo SLA precisa de eventos inequívocos. A primeira resposta pode começar na primeira mensagem elegível do cliente e terminar na primeira resposta pública humana com informação útil. A resolução pode começar na abertura e terminar apenas quando a solução foi comunicada e o estado mudou. Mensagem automática de recebimento não deve virar resposta humana no painel. Consulte o guia de tempo de primeira resposta para auditar a fórmula.

Documente calendário, fuso horário, feriados e comportamento fora do expediente. A Atlassian permite combinar metas com calendários e condições de início, pausa e fim. A lógica operacional é mais importante que a ferramenta: o mesmo caso não pode aparecer cumprido em um relatório e violado em outro porque cada equipe usa relógios diferentes. Registre a versão da regra aplicada para explicar resultados quando o calendário ou a prioridade mudar.

Pausas exigem cuidado. Esperar uma informação realmente necessária do cliente pode pausar um relógio definido dessa forma; transferir o caso, aguardar outra equipe interna ou deixar uma conversa sem dono normalmente não deveria apagar o tempo. Cada pausa precisa de motivo, evento de retomada e visibilidade no histórico. Se a prioridade aumentar, preserve o tempo já consumido e aplique a política documentada em vez de reiniciar o caso silenciosamente.

Teste a promessa contra capacidade, exceções e violações

Antes de publicar uma meta, simule uma semana real. Separe volume por intervalo, canal, prioridade e equipe; inclua picos, almoço, troca de turno, feriados e ausências. Compare a carga com pessoas disponíveis e com o trabalho que exige investigação. Uma meta que depende de esforço heroico falhará justamente quando o volume aumentar. Faça um piloto em uma fila e revise conversas reais antes de ampliar a promessa para todos os canais.

Use histórico como evidência, não como destino automático. Se a mediana é boa mas a cauda acumula horas de espera, prometer pela média esconderá clientes que mais precisam de atenção. Mostre cumprimento por faixa, volume dentro e fora do prazo, backlog aberto e percentis. O Google SRE alerta que metas carregam implicações de produto e negócio. Relacione a promessa ao backlog e à idade da fila, porque casos abertos não podem desaparecer da medição.

Um painel que só fica vermelho depois do atraso chega tarde. Defina alertas progressivos: risco próximo, ação necessária, violação e recorrência. Cada nível precisa de responsável, contexto e próxima decisão. Quando houver violação, preserve canal, prioridade, calendário, eventos, pausas, transferências, responsável e impacto. Não conserte o número apagando histórico. Classifique a causa e ajuste capacidade, roteamento ou regra. Acompanhe também retornos prometidos para evitar um SLA bonito com compromissos esquecidos.