Como calcular SLA de verdade: MTTR, MTBF e tempo de resposta sem se enganar com painel verde

Por que o painel verde mente (e o cliente sente)

O cenário é clássico: o relatório mensal abre com “98% de SLA cumprido”, a diretoria comemora, e mesmo assim o cliente liga reclamando de demora. Os dois estão certos. O painel não está mentindo sobre o que ele mede — ele está medindo a coisa errada, ou medindo certo só uma parte do problema.

Um SLA de cumprimento alto convive bem com péssima experiência por três motivos: ele costuma medir só o fechamento (e não a primeira resposta), costuma contar o relógio errado (24h corridas em vez do horário contratado), e dilui os poucos chamados terríveis numa média gigante de chamados triviais. O resultado é um número verde tecnicamente correto e comercialmente perigoso.

Para sair dessa, você precisa de quatro métricas calculadas com clareza, não de um único percentual. As próximas seções trazem cada fórmula com um exemplo numérico (ilustrativo) que você consegue refazer na estrutura de planilha de apoio descrita no fim do artigo.

• O painel mede fechamento, mas o cliente sente a primeira resposta.
• A média esconde o outlier: um chamado parado 29 dias some dentro de centenas de chamados rápidos.
• Relógio errado (24h vs horário comercial) infla artificialmente o cumprimento.

SLA de verdade: a fórmula e o relógio que ninguém ajusta

SLA de cumprimento é a porcentagem de chamados resolvidos dentro do prazo acordado. A fórmula é simples: SLA% = (chamados dentro do prazo ÷ total de chamados elegíveis) × 100. O problema nunca é a divisão — é o que entra em cada termo.

Primeiro, o relógio. Se o contrato é “8 horas em horário comercial (9h-18h, seg-sex)”, um chamado aberto sexta 17h e respondido segunda 10h consumiu 2 horas úteis, não 65 horas corridas. Painéis configurados em tempo corrido reprovam chamados que cumpriram o acordo — ou, pior, em sentido inverso, aprovam quem estourou. Segundo, as pausas: tempo aguardando o cliente (“pending customer”) normalmente não conta contra o SLA, e se você esquece de pausar, o número degrada sozinho.

Exemplo numérico (valores ilustrativos, só para demonstrar a fórmula): suponha 1.000 chamados no mês, 940 elegíveis (60 cancelados/duplicados saem do denominador) e 921 dentro do prazo. SLA = 921 ÷ 940 = 98,0%. Bonito. Mas isso é SLA de resolução. Não diz nada sobre quanto tempo o cliente esperou para ser respondido pela primeira vez.

• SLA% = (dentro do prazo ÷ elegíveis) × 100 — sempre defina o denominador antes do numerador.
• Configure calendário de atendimento (horário comercial) e pausas de SLA, ou o número fica fictício.
• Separe SLA de resposta de SLA de resolução: são contratos diferentes e o cliente sente o primeiro.

MTTR: tempo médio de reparo (e o outlier que ele esconde)

MTTR (Mean Time To Repair / Resolve) é o tempo médio para resolver um chamado depois que ele foi aberto. Fórmula: MTTR = soma do tempo de reparo de todos os chamados ÷ número de chamados resolvidos. É a métrica que melhor traduz “quanto tempo o problema fica de pé”.

O MTTR é onde o outlier se esconde. Imagine 100 chamados: 99 resolvidos em 2 horas e 1 parado por 29 dias (696 horas) — situação real como a do chamado #2685787, que tinha um gap de cerca de 29 dias. MTTR = (99×2 + 696) ÷ 100 = 8,9 horas. A média sobe pouco e o painel continua confortável, mas existe um cliente que esperou um mês. Por isso, calcule também a mediana e o percentil 90 (P90): se a mediana é 2h e o P90 é 40h, você sabe que a cauda longa existe mesmo quando a média disfarça.

Dica de cálculo: meça o MTTR no mesmo relógio do SLA (horário comercial, descontando pausas). MTTR em tempo corrido e SLA em horário útil dão números que não conversam entre si — e ninguém entende por que o relatório não bate.

• MTTR = soma dos tempos de reparo ÷ chamados resolvidos.
• Sempre acompanhe MTTR junto de mediana e P90 — a média sozinha esconde a cauda longa.
• Use o mesmo calendário do SLA para o MTTR, senão os relatórios não fecham.

MTBF: o reincidente que o cumprimento nunca mostra

MTBF (Mean Time Between Failures) é o tempo médio entre falhas de um mesmo serviço ou ativo. Fórmula clássica: MTBF = tempo total de operação ÷ número de falhas no período. Ele responde a pergunta que o SLA nunca responde: “este problema volta?”.

Atenção a um ponto prático: um ITSM conta chamados, não falhas com uptime medido. Para usar MTBF no help desk, você trata cada chamado de incidente repetido como um proxy de falha e precisa informar de fora a janela de operação do serviço (ex.: horas do mês em que ele deveria estar de pé). É uma aproximação, mas já basta para revelar reincidência. Exemplo (ilustrativo): um serviço operou 720 horas no mês e teve 6 incidentes. MTBF ≈ 720 ÷ 6 = 120 horas, ou seja, uma falha a cada 5 dias. Resolver em 2h cada vez não conserta o fato de que ele quebra 6 vezes.

É aqui que SLA, MTTR e MTBF precisam ser lidos juntos: cumprimento alto + MTTR baixo + MTBF baixo = você é ótimo apagando incêndios recorrentes. A correção real não está em responder mais rápido, e sim em atacar a causa-raiz para que a falha pare de voltar.

• MTBF ≈ tempo total de operação ÷ número de falhas (no ITSM, chamados de incidente repetido viram proxy de falha).
• MTBF baixo = reincidência — o sintoma que o SLA de cumprimento nunca mostra.
• Cruze as três métricas: cumprimento alto com MTBF baixo significa que você apaga incêndio em vez de prevenir.

Tempo de resposta: a métrica que o cliente realmente sente

Tempo de Primeira Resposta (TPR, ou FRT — First Response Time) é o intervalo entre a abertura do chamado e a primeira resposta humana significativa. É a métrica mais correlacionada com a percepção de qualidade, e é justamente a que mais some dos painéis focados em fechamento.

Fórmula: TPR médio = soma dos tempos de primeira resposta ÷ número de chamados respondidos. Atenção ao que conta como “resposta”: um autorreply de “recebemos seu chamado” não é primeira resposta real. Se o seu sistema marca o robô como resposta, o TPR fica lindo e falso. Calcule também o TPR no mesmo relógio comercial e acompanhe o P90 — porque o cliente que esperou no topo da cauda é exatamente o que reclama.

Quando você junta tudo (com os valores ilustrativos deste guia): SLA de resolução 98,0%, MTTR 8,9h, MTBF de ~120h em alguns serviços e um TPR mediano de exemplo de 35 min mas com P90 de 9h, a história fica completa. O verde do painel era verdade. A reclamação também. As duas convivem porque cada uma fala de uma métrica diferente.

• TPR = soma dos tempos de primeira resposta ÷ chamados respondidos.
• Não conte autorreply de robô como primeira resposta — invalida a métrica.
• Acompanhe o P90 do TPR: é o cliente da cauda longa que abre a reclamação.

A planilha de apoio: estrutura para reproduzir tudo

Você consegue calcular as quatro métricas numa planilha simples, e recomendamos montar a sua para auditar o painel. A estrutura mínima é uma aba de dados (um chamado por linha) e uma aba de resumo com as fórmulas agregadas.

Aba Dados, uma coluna por campo: ID do chamado, Serviço vinculado, Data/hora de abertura, Data/hora da primeira resposta, Data/hora de resolução, Tempo útil de resposta (h), Tempo útil de reparo (h), Dentro do prazo? (SIM/NÃO), É reabertura? (SIM/NÃO). O “tempo útil” é o que respeita horário comercial e pausas — calcule com função de dias úteis/horas úteis, não com subtração simples de datas.

Aba Resumo, com as agregações: SLA% = CONT.SE(Dentro do prazo=”SIM”) ÷ total elegível; MTTR = MÉDIA(Tempo útil de reparo) e também MED() e PERCENTIL(…;0,9); TPR = MÉDIA(Tempo útil de resposta) + P90; MTBF por serviço = horas de operação do período ÷ CONT.SE(incidentes do serviço). Com essa estrutura você reproduz a lógica dos exemplos do artigo e, mais importante, descobre onde o seu painel está medindo o relógio errado.

• Aba Dados: um chamado por linha, com tempos úteis (horário comercial), não tempo corrido.
• Aba Resumo: SLA% por CONT.SE, MTTR/MTTR-P90 por MÉDIA/PERCENTIL, MTBF por serviço (com a janela de operação informada à parte).
• Sempre calcule mediana e P90 ao lado da média — é o que revela a cauda longa que o cliente sente.

Onde a IA entra: número e causa-raiz no mesmo lugar

Calcular as métricas resolve metade do problema; a outra metade é entender por que o reincidente existe. É aqui que o Copilot de IA da Service Up, dentro do Znuny, atua: ele cruza tempo vs SLA por chamado, identifica os gaps (como os ~29 dias do chamado #2685787) e gera o Relatório de Causa-Raiz que explica o porquê, não só o quanto.

Os números são reais e medidos no nosso próprio ambiente: em 30 dias, 974 chamados, 647 analisados pela IA (66% de cobertura), 85 serviços vinculados; cobertura de análise de sentimento em 88% e de causa-raiz (RCA) em 84%. O painel agregado agrupa os chamados por serviço, com a causa-raiz da IA como detalhe — exatamente a leitura que liga a reincidência por serviço ao motivo de fundo (o sinal que o MTBF também tenta capturar).

A tese é simples: a IA não substitui o analista que decide. Ela acelera o cálculo, ajuda a achar o outlier escondido na média e entrega a causa-raiz pronta para a pessoa agir. A IA acelera; o humano decide. Se você quer parar de confiar só no verde do painel, fale com a gente.

• A IA da Service Up cruza tempo vs SLA por chamado e expõe os gaps que a média esconde.
• O painel agregado liga a reincidência por serviço à causa-raiz de fundo.
• Métricas reais de 30 dias: 974 chamados, 647 analisados, 66% de cobertura, 85 serviços, sentimento 88%, RCA 84%.