Como este tema funciona na sua empresa
SLA é simples: 1-2 métricas (disponibilidade, tempo de resposta). Nível esperado é moderado (99% de disponibilidade, 4 horas de tempo de resposta). Penalidade é desconto simples na fatura (5-10% por violação). SLA é documento informal, frequentemente cabe em 1-2 páginas. Revisão é anual se há necessidade.
SLA é estruturado com 3-5 métricas: disponibilidade, performance, tempo de resposta, tempo de resolução. Nível varia por severidade (crítico 99.9%, alto 99.5%, normal 99%). Penalidade é desconto escalonado ou crédito de serviço (5-20%). SLA é documento formal com 5-10 páginas. Revisão é semestral conforme necessidade.
SLA é detalhado com 5+ métricas e múltiplos serviços. Níveis são muito rigorosos (99.9%+ para críticos). Penalidade é desconto, crédito, ou até rescisão de contrato se reincidente. SLA é documento robusto com 20+ páginas e apêndices técnicos. Revisão é trimestral ou contínua conforme evolução.
Acordo de nível de serviço (SLA) é contrato formal que especifica o nível de qualidade esperado de um fornecedor em dimensões como disponibilidade, tempo de resposta, performance, incluindo as métricas de medição, penalidades por violação, e exclusões aplicáveis[1].
Por que SLA precisa ser realista e não ambicioso demais
Empresas frequentemente definem SLA impossível de cumprir (99.99% de disponibilidade para sistema não-crítico). Resultado: fornecedor frequentemente falha, cliente fica frustrado, relacionamento vira conflito. O insight: 99% é moderado, 99.9% é rigoroso, 99.99% é extremo e caro. Empresas que definem SLA realista têm satisfação 75%+; aquelas com SLA ambicioso têm 40%. Custo de atingir SLA aumenta exponencialmente: 99% é relativamente barato; 99.9% custa 3-5x mais; 99.99% custa 10x mais.
Componentes essenciais de SLA bem estruturado
Disponibilidade (uptime): percentual de tempo que serviço está operacional. Exemplo: "99.5% de disponibilidade" significa até 3.6 horas de downtime ao mês é aceitável. Tempo de resposta: quanto tempo fornecedor tem para responder a incidente. Exemplo: "Crítico: 2h, Alto: 4h, Normal: 1 dia". Tempo de resolução: quanto tempo para resolver completamente. Exemplo: "Crítico: 4h, Alto: 1 dia, Normal: 3 dias". Performance: tempo de resposta de aplicação. Exemplo: "< 2 segundos para 95% das requisições". Sempre incluir percentil (95%, 99%), não apenas média.
SLA simples: "Disponibilidade 99% (7.2h downtime/mês). Tempo de resposta 4h para crítico, 1 dia para importante. Penalidade: 5% de desconto na fatura por mês com violação." Não precisa de fórmula complexa de cálculo. Revisar anualmente. Documentação pode ser simples (1-2 páginas em anexo ao contrato).
SLA estruturado por severidade: Crítico 99.5%, Alto 99%, Normal 98.5%. Tempo de resposta e resolução definido. Performance incluída (latência, throughput). Penalidade: 10% desconto/crédito por mês com breach. Fórmula de cálculo documentada. Revisão semestral. SLA é documento de 5-10 páginas com cálculos e exemplos.
SLA extremamente detalhado: múltiplos serviços com SLAs individuais. Críticos: 99.99%, importantes: 99.9%, operacionais: 99%. Penalidade: 15% desconto + crédito de serviço. Rescisão contratual se reincidente (>3 breaches em 6 meses). Cálculo de SLA automatizado via sistema de monitoramento. Auditoria trimestral de compliance.
Severidade, exclusões e a importância de ser específico
Definir critério de severidade para não cobrar SLA igual para tudo. Exemplo: "Crítico = sistema inteiro down" (80 usuários indisponíveis), "Alto = performance degradada" (sistema lento), "Normal = ajustes menores" (um usuário impactado). 80% dos incidentes é "Normal". Exclusões (situações onde SLA não se aplica): "SLA não se aplica a: (a) problemas causados por ação do cliente, (b) downtime agendado com 30 dias de aviso, (c) eventos de força maior (terremoto, mas não queda de energia em datacenter)." Ser muito específico; ambiguidade gera litígio e discordância.
Penalidades: o que funciona de verdade
Penalidade deve doer um pouco (senão fornecedor não se importa), mas não tanto (senão fornecedor não quer contrato). Penalidade média por falha de SLA: 5-10% do valor mensal. Opções: (1) desconto na fatura (mais simples), (2) crédito de serviço (dias grátis), (3) direito de rescisão (se reincidente). Cuidado: penalidade genérica "força maior" permite fornecedor escapar de qualquer violação. Melhor: "força maior = situações não previstas e não evitáveis (terremoto); não inclui falhas de infraestrutura de terceiros, problemas previsíveis, ou erros operacionais do fornecedor."
Como calcular e validar SLA
Disponibilidade é calculada como: Tempo operacional / Tempo total. Exemplo: "Sistema funcionou 720 horas em mês com 730 horas. Uptime = 720/730 = 98.6%." SLA de 99% permite até 7.2 horas de downtime; aqui não foi violado (é 1.4h de downtime). Validação: solicitar ao fornecedor logs de quando sistema foi down. Não confiar apenas no número reportado; auditar (validar dados brutos). "SLA sem medição é letra morta": se não mede, como sabe que cumpre?
Sinais de que seu SLA está mal formulado
Se você se reconhece em três ou mais cenários abaixo, revise seu SLA antes de assinar.
- SLA não tem fórmula explícita de cálculo; é ambíguo como vai ser medido
- SLA tem cláusula de "melhor esforço" em vez de "garantia"; fornecedor não é responsável
- Exclusão genérica por "força maior" sem definição clara (permite fornecedor escapar de qualquer falha)
- SLA é o mesmo para serviços críticos e operacionais; não há diferenciação de severidade
- Violação de SLA não gera consequência (sem desconto, sem crédito, sem remediação)
- SLA é limite máximo de performance atual (sem margem de segurança); impossível melhorar
- Ninguém mede SLA; é apenas um número no contrato que ninguém valida
- SLA viola legislação (ex: LGPD exige notificação em 72h, mas SLA permite 7 dias)
Caminhos para estruturar SLA realista
Viável com framework de SLA existente.
- Perfil necessário: gestor de TI + analista de contrato ou procurador
- Tempo estimado: 2-4 semanas para pesquisar e definir SLA
- Faz sentido quando: você tem experiência com fornecedor semelhante; conhece realidade de mercado
- Risco principal: SLA demasiado ambicioso ou frouxo por falta de experiência
Recomendado para outsourcing estratégico ou sem experiência prévia.
- Tipo de fornecedor: consultores jurídicos, especialistas em ITIL, consultores de procurement
- Vantagem: SLA realista, validação contra legislação, aprendizado de boas práticas
- Faz sentido quando: contrato é grande, outsourcing é crítico, legislação é complexa (LGPD, setor específico)
- Resultado típico: 4-8 semanas, SLA robusto e realista, protege ambos os lados
Precisa estruturar SLA para outsourcing?
O oHub conecta você gratuitamente a consultores jurídicos especializados em contratos de TI, especialistas em ITIL e consultores de procurement. Descreva seu contexto (tipo de serviço, criticidade, se já tem fornecedor) e receba propostas de apoio em menos de 3 minutos, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Qual é um bom SLA de disponibilidade para outsourcing?
99% (7.2h downtime/mês) é moderado; 99.5% (3.6h/mês) é rigoroso; 99.9% (43 min/mês) é muito rigoroso e caro. Para sistemas críticos (faturamento, email), comece com 99.5-99.9%. Para operacionais, 99% é adequado. Validar com fornecedor se é alcançável com o preço proposto.
Como diferenciar SLA por severidade?
Defina categorias: Crítico = sistema inteiro indisponível (80+ usuários). Alto = funcionalidade importante degradada. Normal = ajuste menor. Crítico tem SLA mais rigoroso (99.9%), normal tem mais flexível (99%). Tempo de resposta também varia: crítico responde em 2h, normal em 1 dia.
Quem deve medir o SLA: cliente ou fornecedor?
Idealmente, ambos. Fornecedor mede do seu lado (logs do sistema). Cliente valida (audita números). Se houver discrepância, investigar. Melhor: usar ferramenta de monitoramento independente (third-party monitoring) que registra dados que ambos confiam.
O que fazer se fornecedor regularmente viola SLA?
Primero, validar se medição está correta (auditoria de cálculo). Se violação é real, escalada: (1) notificação formal do breach, (2) acionamento de penalidade, (3) plano de melhoria com timeline, (4) se continua, renegociar ou descontinuar contrato.
Força maior exclui SLA? Como definir bem?
Força maior é evento não-previsto e não-evitável: terremoto, furacão, lei. Não inclui: falha de fornecedor de internet (previsível, evitável com redundância), manutenção não-comunicada (responsabilidade do fornecedor), erros operacionais. Ser específico na exclusão.
SLA deve incluir performance ou apenas disponibilidade?
Se serviço é crítico, incluir performance (tempo de resposta da aplicação, throughput). Exemplo: "99% disponibilidade E tempo de resposta < 2 segundos para 95% das requisições." Disponibilidade não significa rápido; incluir ambas as métricas.