Como medir SLA real em um Service Desk (sem maquiagem)

SLA (Service Level Agreement) é a métrica mais discutida e menos confiável em service desk. A razão? Em 8 de 10 implantações que auditamos na i9aTech ao longo de 2024-2026, o cálculo apresentado ao board está maquiado — por exclusões silenciosas, pausas automáticas, reabertura tratada como ticket novo e clausulas de exceção que ninguém lê.

Este guia mostra como medir SLA de verdade: os 6 KPIs que importam, queries SQL prontas para GLPI e OTRS, dashboard executivo e o checklist anti-maquiagem que aplicamos em auditoria.

Por que o SLA reportado quase nunca bate com a realidade

O número que aparece no relatório executivo é normalmente um SLA contábil, não operacional. As 5 distorções mais comuns:

1. Pausa de SLA durante “aguardando cliente”. Em muitos workflows, o relógio para enquanto o ticket espera resposta do solicitante. Resultado: ticket que ficou 14 dias em aberto aparece como resolvido em 2 horas.
2. Reclassificação retroativa de prioridade. Ticket aberto como P1 que estoura SLA é rebaixado para P3 antes do fechamento — o histórico mostra cumprimento perfeito.
3. Reabertura tratada como novo ticket. Cliente reclama, ticket é reaberto, relatório conta como ticket novo com SLA zerado. Métrica de retrabalho some.
4. Janela de atendimento maquiada. SLA configurado para 8h-18h dias úteis, mas tickets chegam 24/7. Tempo real de espera fica 3x maior que o reportado.
5. Exclusão de categorias inconvenientes. “Tickets do projeto X não contam para SLA porque é projeto especial.” Em pouco tempo, 30% dos tickets viram exceção.

Os 6 KPIs que o C-level precisa ver

1. First Response Time (FRT)

Tempo entre abertura e a primeira interação humana real com o solicitante. Excluir auto-respostas (e-mail de confirmação, “recebemos seu chamado”) — elas não resolvem nada.

Metas de mercado para 2026 (operação madura): P1 ≤ 15 min, P2 ≤ 1h, P3 ≤ 4h, P4 ≤ 8h. Operação iniciante: dobre os números.

2. Mean Time To Resolution (MTTR)

Tempo total entre abertura e fechamento confirmado (não fechamento administrativo). Inclui tudo: investigação, escalation N2/N3, espera por terceiros, validação com solicitante.

Reporte mediana, não média. Tickets cabeludos de 30 dias inflam a média e escondem que 80% da operação resolve em 4h. Use também P90 (em 90% dos casos resolvemos em até X horas) — é o número que o usuário sente.

3. First Contact Resolution (FCR)

Percentual de tickets resolvidos no primeiro contato sem escalation e sem reabertura nos 7 dias seguintes. FCR sem checagem de reabertura é fictício.

Meta: ≥ 70% para operação N1 com KB madura. Abaixo de 50% sinaliza KB pobre ou triagem ruim.

4. Reopen Rate

Percentual de tickets fechados que foram reabertos em 7/14/30 dias. Indicador brutal de qualidade real — esconde pouca coisa.

Reopen rate > 15% significa que o atendimento está empurrando tickets em vez de resolver. Geralmente vem de pressão por SLA mal configurada.

5. SLA Compliance (com filtros revelados)

Não reporte um número só. Reporte 3 versões lado a lado:

• SLA oficial — com pausas, exclusões e janela conforme contrato.
• SLA bruto — relógio rodando 24/7, sem pausas, sem exclusões.
• SLA perceived — do ponto de vista do solicitante (do clique até o “obrigado, resolvido”).

Diferença > 20 pontos entre oficial e bruto é red flag — sua operação está vendendo um SLA que o cliente não recebe.

6. CSAT (e quanto dela vem de robô)

Satisfação do solicitante coletada após fechamento (escala 1-5). KPI complementar — SLA verde com CSAT 2,8 significa que você está cumprindo papel mas entregando mal.

Atenção: taxa de resposta importa mais que a média. CSAT 4,8 com 8% de respondentes é amostra viciada. Reporte com response rate sempre.

Como medir no GLPI (SQL pronto)

O GLPI 10+ tem dashboard nativo, mas dependendo dos plugins instalados as métricas podem estar incompletas. Para MTTR bruto (sem pausas, sem exclusões), use a query direto no banco:

-- GLPI: MTTR bruto em horas, por prioridade, últimos 90 dias
SELECT
  priority,
  COUNT(*) AS tickets,
  ROUND(AVG(TIMESTAMPDIFF(MINUTE, date, solvedate)) / 60, 2) AS mttr_horas_avg,
  ROUND(
    SUBSTRING_INDEX(
      SUBSTRING_INDEX(
        GROUP_CONCAT(TIMESTAMPDIFF(MINUTE, date, solvedate) ORDER BY TIMESTAMPDIFF(MINUTE, date, solvedate)),
        ',',
        FLOOR(COUNT(*) * 0.5) + 1
      ),
      ',',
      -1
    ) / 60, 2
  ) AS mttr_horas_mediana
FROM glpi_tickets
WHERE solvedate IS NOT NULL
  AND date >= DATE_SUB(NOW(), INTERVAL 90 DAY)
  AND is_deleted = 0
GROUP BY priority
ORDER BY priority DESC;

Para reopen rate, cruze a tabela glpi_tickets com glpi_logs filtrando por mudança de status de “fechado” para “atribuído”:

-- GLPI: tickets reabertos em até 7 dias após fechamento
SELECT
  DATE_FORMAT(t.date, '%Y-%m') AS mes,
  COUNT(DISTINCT t.id) AS reabertos,
  (SELECT COUNT(*) FROM glpi_tickets WHERE solvedate IS NOT NULL
   AND DATE_FORMAT(solvedate, '%Y-%m') = DATE_FORMAT(t.date, '%Y-%m')) AS total_fechados
FROM glpi_tickets t
JOIN glpi_logs l ON l.items_id = t.id
WHERE l.itemtype = 'Ticket'
  AND l.id_search_option = 12  -- mudança de status
  AND l.old_value IN ('5', '6')  -- fechado/solucionado
  AND l.new_value IN ('2', '3', '4')  -- volta a aberto
  AND TIMESTAMPDIFF(DAY, t.solvedate, l.date_mod) <= 7
GROUP BY mes
ORDER BY mes DESC LIMIT 12;

Como configurar SLA correto no GLPI

No GLPI 10+ você define SLA por combinação de categoria + tipo + impacto + urgência. Os erros mais frequentes na configuração:

• SLA único “4h pra tudo” — sem variação por categoria, perde sentido.
• Calendário de atendimento que ignora finais de semana mesmo para P1 — produção parando às 23h de sexta espera segunda.
• Não definir SLA de resposta separado do SLA de resolução — métrica vira balaio de gato.
• Pausa automática de SLA por status “aguardando” — fazer manual sempre, com justificativa.

Checklist anti-maquiagem (12 itens)

Antes de apresentar o SLA do mês para o C-level, passe este checklist. Se 3 ou mais itens estiverem nas exceções, o número está distorcido.

• Auto-respostas estão excluídas do cálculo de FRT?
• Tickets pausados > 24h tem justificativa registrada?
• Reaberturas em 7 dias estão sendo contadas?
• Reclassificações de prioridade pós-abertura estão rastreadas?
• Calendário de atendimento bate com o contrato com o cliente?
• Tickets P1 fora do horário comercial respeitam SLA 24/7?
• Categorias “projeto” ou “especial” estão no relatório (e não fora)?
• Mediana é reportada junto com a média?
• P90 está visível no dashboard?
• Reopen rate < 15%?
• CSAT tem response rate >= 30%?
• Você consegue rodar a query SQL bruta e bater com o dashboard oficial em ± 5 pontos?

Dashboard executivo de 1 página

O C-level olha 90 segundos. O dashboard precisa caber em uma tela e ter, no mínimo:

• Volume do mês (e variação % vs mês anterior)
• SLA Compliance — oficial / bruto / perceived (3 números lado a lado)
• MTTR mediana + P90 por prioridade
• FCR e Reopen Rate (lado a lado — eles se contradizem se tiver problema)
• CSAT com response rate
• Top 5 categorias geradoras de ticket (revela onde investir self-service)

Tudo o que sobrar é detalhe operacional — vai para o segundo dashboard, que o C-level pode abrir se quiser. Detalhamento de mais na primeira página esconde o sinal no ruído.

Próximo passo

Se você desconfia que o SLA reportado na sua operação não bate com a realidade, a i9aTech faz auditoria de mensuração em 5 dias úteis — rodamos as queries brutas no seu GLPI ou OTRS, comparamos com o dashboard oficial e entregamos o relatório de aderência com plano de correção.

Agende o diagnóstico gratuito de 30 minutos e veja se faz sentido pra sua operação.