SLA de TI: Como Definir Métricas que Realmente Protegem o Negócio

Um SLA sem penalidade real é um documento declaratório, não um compromisso — é a diferença entre um fornecedor que promete "resposta rápida" e um contrato que define exatamente o que "rápido" significa, e o que acontece se essa promessa não for cumprida. Muitas empresas descobrem essa diferença tarde demais, só quando um incidente crítico revela que o SLA assinado não protegia ninguém de fato. Este guia explica como definir um SLA de TI que funciona de verdade — seja para um fornecedor externo, seja internamente entre a área de TI e o resto da empresa.

O que é um SLA de TI, sem juridiquês

SLA (Service Level Agreement, ou Acordo de Nível de Serviço) é um contrato formal que define os níveis de serviço que serão entregues — prazos de atendimento, métricas de qualidade, disponibilidade de sistemas e responsabilidades de cada parte. E um detalhe importante: o SLA não é exclusivo de contratos com fornecedores externos. No contexto interno de uma empresa, o "cliente" é qualquer área que depende da TI para operar — comercial, financeiro, RH — o que torna o SLA igualmente necessário para regular essa relação interna.

Os três elementos centrais de qualquer SLA

1. Escopo do serviço — o que está coberto, e igualmente importante, o que não está.
2. Métricas e metas — os indicadores que serão medidos e o valor-alvo para cada um.
3. Consequências — penalidades, créditos ou ajustes contratuais em caso de descumprimento.

Um SLA que define apenas o primeiro item, sem métricas mensuráveis e sem consequências reais, não é um SLA — é uma lista de expectativas sem mecanismo de cobrança.

Como definir níveis de prioridade

Antes de definir prazos, é preciso classificar as demandas por criticidade. Uma classificação funcional combina dois eixos: urgência (o quanto o serviço afetado é necessário naquele momento) e impacto (quantas pessoas ou processos são prejudicados pela falha). A combinação desses dois critérios gera os níveis de prioridade — normalmente de P1 (crítico) a P4 (baixo). Um exemplo de estrutura comum:

Prioridade	Exemplo de critério	Prazo de resolução típico
P1 — Crítico	Sistema essencial fora do ar, afetando toda a operação	Até 4 horas
P2 — Alto	Funcionalidade importante indisponível, afetando parte da operação	Até 8-12 horas
P3 — Médio	Problema pontual, com contorno disponível	Até 3 dias úteis
P4 — Baixo	Solicitação sem urgência operacional	Prazo acordado, sem pressão crítica

Ajuste esses números à capacidade real da equipe antes de publicar — um SLA com prazos que a equipe nunca vai conseguir cumprir é tão inútil quanto um sem prazos definidos.

As métricas que realmente importam

• Tempo de primeira resposta — quanto tempo a equipe leva para iniciar o atendimento depois que o chamado é aberto. É um dos indicadores mais críticos em contratos de suporte técnico ou infraestrutura crítica, mesmo quando a resolução completa ainda vai levar mais tempo.
• MTTR (tempo médio de resolução) — quanto tempo é necessário para solucionar o problema por completo. Essencial para avaliar eficiência real da equipe e identificar gargalos operacionais.
• Percentual dentro do SLA — a porcentagem de atendimentos concluídos dentro do prazo definido, idealmente segmentada por prioridade e tipo de serviço — a média geral pode esconder um problema concentrado numa categoria específica.
• Disponibilidade (uptime) — para sistemas críticos, o padrão de mercado considerado saudável costuma ficar acima de 99,9%.

O que precisa estar nas cláusulas de penalidade

Penalidades genéricas ou desproporcionais não protegem nenhuma das partes. Um bom SLA prevê:

• Créditos de serviço — desconto proporcional na fatura seguinte, em caso de violação.
• Gatilhos claros de escalada — quando e para quem o problema deve ser escalado se o prazo inicial não for cumprido.
• Limites de responsabilidade compatíveis com o serviço prestado — evitando tanto penalidades injustas para o fornecedor quanto proteção insuficiente para o cliente.

Um erro comum em SLAs mal desenhados é transferir implicitamente toda a responsabilidade para o fornecedor, sem prever nenhuma obrigação do lado do cliente (acesso a sistemas, decisões rápidas em momentos de crise, informações necessárias para o diagnóstico) — em uma relação de verdade, as duas partes têm obrigações.

SLA não é documento estático

As melhores práticas recomendam revisar o SLA pelo menos anualmente, ou sempre que houver mudança significativa na infraestrutura ou nos objetivos de negócio. Ferramentas de monitoramento em tempo real ajudam a detectar desvios antes que virem violação formal — configurar alertas que disparem antes de estourar a meta é mais eficiente do que descobrir o problema só no relatório mensal.

O erro mais caro: tratar violação de SLA só como punição

Boas práticas de ITSM recomendam usar violações de SLA como oportunidade de melhoria de processo, não apenas como ferramenta punitiva. Um SLA violado repetidamente na mesma categoria de incidente é um sinal de que existe uma causa raiz não resolvida — não apenas uma cobrança de crédito a ser processada.

Fale com quem estrutura SLA pensando em proteger o negócio, não só cumprir formalidade

A Forge Code ajuda empresas a estruturar SLAs de TI — internos ou com fornecedores — com métricas que realmente refletem o que protege a operação.

Solicitar consultoria de SLA de TI →

---

Perguntas Frequentes

O que é um SLA de TI? É um contrato formal que define os níveis de serviço de TI a serem entregues — prazos de atendimento, métricas de qualidade, disponibilidade de sistemas e responsabilidades de cada parte, seja com um fornecedor externo ou internamente entre a TI e outras áreas da empresa.

Quais são as métricas mais importantes de um SLA de TI? Tempo de primeira resposta, MTTR (tempo médio de resolução), percentual de atendimentos dentro do prazo (segmentado por prioridade) e disponibilidade (uptime) dos sistemas críticos.

Como definir níveis de prioridade em um SLA? Combinando dois eixos: urgência (quão necessário é o serviço naquele momento) e impacto (quantas pessoas ou processos são afetados). Essa combinação gera níveis de P1 (crítico) a P4 (baixo), cada um com prazo próprio.

O que precisa ter uma cláusula de penalidade de SLA? Créditos de serviço proporcionais à violação, gatilhos claros de escalada e limites de responsabilidade compatíveis com o serviço prestado — evitando penalidades desproporcionais em qualquer direção.

Com que frequência um SLA de TI deve ser revisado? Pelo menos anualmente, ou sempre que houver mudança significativa na infraestrutura ou nos objetivos de negócio.