Tempo de resposta vs SLA: como medir, visualizar e parar de estourar prazo

O paradoxo do painel verde

É a cena clássica: a diretoria abre o dashboard, o indicador de SLA está em alto cumprimento, tudo verde. No mesmo dia, clientes ligam reclamando que “ninguém responde” e que o chamado “ficou parado por semanas”. As duas coisas podem ser verdadeiras ao mesmo tempo — e o motivo é simples: o painel mede uma coisa, o cliente sente outra.

Na maioria das configurações de help desk, o SLA padrão monitorado é o tempo de resolução: da abertura ao fechamento do chamado. Esse número pode estar lindo porque o chamado foi resolvido dentro do prazo contratual de, digamos, 72 horas úteis. Só que dentro dessas 72 horas pode ter havido muitos dias de calendário em que o cliente mandou uma mensagem e ninguém respondeu — porque o relógio do SLA estava pausado em status “pending”, ou porque a régua só conta o estado final.

A experiência de espera do cliente não é a duração total do ticket. É a soma dos silêncios. Por isso o termo SLA tempo de resposta precisa ser decomposto em métricas distintas antes de virar meta.

• O cliente percebe latência, não duração agregada.
• SLA de resolução verde pode conviver com FRT ruim e gaps longos.
• O número que tranquiliza a gestão é o que pode esconder a insatisfação.

As três métricas que você precisa separar

Antes de qualquer fórmula, é preciso parar de tratar “tempo de resposta” como um número só. São três medidas diferentes, com comportamentos e metas diferentes.

FRT (First Response Time / Tempo de Primeira Resposta): tempo entre a abertura do chamado e a primeira resposta humana real ao cliente — não a confirmação automática de recebimento. É a métrica mais correlacionada com a percepção de “fui atendido”.

Tempo entre interações (Next Response Time): tempo que o cliente espera por CADA resposta seguinte depois que ele se manifesta. É aqui que moram os gaps silenciosos. Um chamado pode ter FRT excelente e ainda assim deixar o cliente vários dias sem retorno numa rodada posterior.

Tempo de resolução (Resolution Time): da abertura ao fechamento. É o que quase todo SLA contratual mede e o que vai verde no painel. Importante, mas insuficiente sozinho.

• FRT mede a primeira impressão de atendimento.
• Tempo entre interações expõe o abandono no meio do caminho.
• Resolução é o teto contratual — não o termômetro da experiência.

As fórmulas: medindo em tempo útil, não em relógio de parede

Medir tempo em horas corridas pune a equipe por horários em que ninguém deveria estar trabalhando. A base correta é o tempo útil, calculado dentro do calendário de atendimento (ex.: seg-sex, 8h-18h), descontando feriados e os períodos legítimos de espera pelo cliente.

FRT útil = HorasÚteis(abertura → primeira resposta do agente). Exemplo: chamado aberto sexta 17h30, primeira resposta segunda 9h00. Em relógio de parede são ~63h. Em tempo útil (descontando noite e fim de semana, jornada 8h-18h): 0h30 de sexta + 1h de segunda = 1h30. A meta de FRT deve ser comparada com 1h30, não com 63h.

Tempo entre interações = HorasÚteis(mensagem do cliente → próxima resposta do agente), calculado para cada par. O gap relevante é o MÁXIMO desses intervalos, não a média — porque é o pior silêncio que o cliente lembra.

Tempo de resolução útil = HorasÚteis(abertura → fechamento) − Σ(tempo em status “pending”/aguardando cliente). É essa subtração que faz o SLA ficar verde mesmo com gaps longos — e por isso ele precisa ser lido ao lado do gap máximo, nunca sozinho.

% de cumprimento de SLA = (chamados dentro do alvo ÷ total de chamados) × 100, calculado SEPARADAMENTE para cada uma das três métricas. Um único percentual agregado é exatamente o que mascara o problema.

• Sempre desconte fora-de-horário e pausas legítimas: meça tempo útil.
• Para gaps, reporte o MÁXIMO por chamado, não a média.
• Calcule % de cumprimento por métrica (FRT, interação, resolução) — nunca um número único.

Gráficos sob demanda: o que pedir ao Copilot

Dentro do módulo de Relatório de Causa-Raiz / AI Copilot da Service Up, no Znuny, você pede gráficos em linguagem natural sobre os chamados do período e também consulta a visão de tempo vs SLA. Três pedidos ajudam a furar o paradoxo do painel verde.

1) Distribuição do tempo de primeira resposta — em vez de uma média que esconde tudo, peça a forma da distribuição e leia os percentis. P50 conta a rotina; P90 e P95 contam onde o cliente sofre. Peça algo como: “distribuição do tempo de primeira resposta dos chamados do período”.

2) Tempo vs SLA — relacione o tempo decorrido de cada chamado com o alvo de SLA para enxergar quem está perto do limite. Peça: “compare o tempo de atendimento dos chamados contra o alvo de SLA”.

3) Maior gap por chamado — peça a visão do maior intervalo de silêncio entre interações. Foi nesse tipo de leitura que o gap de ~29 dias do chamado #2685787 ficou evidente. Peça: “qual o maior intervalo entre interações por chamado no período”.

O Copilot já cruza isso com a análise de sentimento (88% de cobertura no período): muitas vezes a virada de sentimento negativo coincide com o início de um gap longo — e foram 22 palavras negativas detectadas no recorte. Esse cruzamento transforma um número de SLA em uma causa raiz acionável.

• Distribuição de FRT: leia P90/P95, não a média.
• Tempo vs SLA: enxergue quem está perto de estourar.
• Maior gap por chamado, cruzado com sentimento.

Metas que valem a pena perseguir

Meta não é o número que enche os olhos — é o número que muda comportamento. Defina alvos por métrica e, principalmente, por percentil.

FRT: estabeleça o alvo em P90, não na média. “90% dos chamados com primeira resposta em até X horas úteis” protege contra a média mascarada por uns poucos atendimentos instantâneos. A média sozinha sempre parece melhor do que a realidade da cauda.

Gaps: a meta mais poderosa é “zero chamados com gap acima de N dias úteis”. Ela ataca diretamente o silêncio que gera reclamação mesmo com SLA verde. Acompanhe o número de chamados que violam esse teto, não a média de gap.

Resolução: mantenha o alvo contratual, mas leia-o sempre ao lado do FRT e do gap máximo. Os três juntos contam a história inteira; qualquer um sozinho mente por omissão.

Operacionalize: o Copilot processa o período via “Processar agora” ou pelo console (bin/znuny.Console.pl Maint::AICopilot::RCAScan) e devolve a análise. No recorte de 30 dias foram 974 chamados, 647 analisados (66% de cobertura), 85 serviços vinculados. Vale notar que 182 chamados estavam sem serviço vinculado e o serviço campeão em volume foi “Consultoria::Dúvida” com 142 — onde vincular serviço corretamente é o primeiro passo para medir SLA por serviço com precisão.

• FRT como meta de P90, nunca de média.
• Gaps com meta de teto absoluto: zero acima de N dias úteis.
• Resolução lida em conjunto com FRT e gap máximo — os três contam a verdade.

A IA acelera, o humano decide

O ponto não é substituir o analista de SLA por um robô. O Copilot da Service Up faz o trabalho pesado e chato: vasculha os 647 chamados analisados, cruza tempo vs SLA com a análise de sentimento e te entrega a causa raiz como detalhe — inclusive no painel agregado, em que os chamados do período aparecem agrupados por serviço vinculado.

O que ele não faz é decidir que o processo de triagem precisa mudar, ou que aquele serviço específico precisa de mais um agente, ou que o template de primeira resposta está empurrando o cliente para o silêncio. Isso é decisão humana, informada por dados que antes ficavam invisíveis no painel verde.

Em uma frase: a IA acelera; o humano decide. O módulo é parte da plataforma da Service Up, parceira Znuny/OTOBO, e existe justamente para tirar a gestão de SLA do achismo do indicador agregado e colocá-la na régua certa. Quer ver isso nos seus próprios chamados? Fale com o comercial da Service Up no WhatsApp +55 11 5192-3351.

• A IA cruza tempo vs SLA com sentimento em escala.
• A decisão de mudar processo, template ou alocação continua humana.
• Módulo da Service Up para Znuny — RCA, sentimento e SLA no mesmo lugar.