Como Redigir um Contrato de SLA de TI

Um contrato de serviços de TI sem um SLA bem escrito é uma promessa vaga esperando virar conflito. Quando algo dá errado, o cliente acha que o combinado era uma coisa, o fornecedor acha que era outra, e não há documento que resolva a divergência. O SLA existe justamente para transformar expectativas subjetivas em compromissos objetivos e mensuráveis, protegendo os dois lados. Só que redigir um bom SLA é mais difícil do que parece: é fácil escrever cláusulas genéricas que não significam nada na prática, ou métricas impossíveis de medir, ou penalidades que ninguém consegue aplicar. Neste artigo você vai aprender o que é um contrato de SLA de TI, quais cláusulas ele precisa conter, como definir métricas que fazem sentido, como estruturar níveis de severidade e penalidades, e receberá uma estrutura de referência para não deixar buracos no seu acordo.

O que é um contrato de SLA de TI

SLA é a sigla de Service Level Agreement, ou Acordo de Nível de Serviço. É o documento, geralmente parte de um contrato maior, que define de forma objetiva e mensurável o que o prestador de serviço se compromete a entregar, com quais níveis de qualidade, em quais prazos, e o que acontece se esses compromissos não forem cumpridos.

O SLA cumpre três funções. Primeiro, alinha expectativas: cliente e fornecedor sabem exatamente o que foi combinado, sem margem para interpretação. Segundo, cria mensurabilidade: em vez de "atendimento rápido", há "resposta em até 30 minutos para incidentes críticos". Terceiro, estabelece consequências: define o que acontece quando o nível acordado não é atingido, dando dentes ao acordo.

Vale distinguir três termos que costumam ser confundidos. O SLA é o acordo voltado ao cliente, com os níveis de serviço prometidos. O SLO, Service Level Objective, é o objetivo interno de nível de serviço que o fornecedor persegue, geralmente mais rigoroso que o SLA para dar margem de segurança. O SLI, Service Level Indicator, é o indicador concreto que se mede, o número real. Na prática, o cliente lida com o SLA, mas entender essa cadeia ajuda a escrever acordos coerentes.

Por que um SLA bem escrito protege os dois lados

Existe uma percepção equivocada de que o SLA serve só para o cliente cobrar o fornecedor. Na verdade, ele protege ambos, e é isso que faz dele uma ferramenta de relacionamento saudável, não de guerra.

Para o cliente, o SLA garante previsibilidade e recurso. Ele sabe o que esperar e tem base contratual para cobrar quando o serviço falha. Sem SLA, o cliente fica refém da boa vontade do fornecedor e sem argumento objetivo quando as coisas dão errado.

Para o fornecedor, e isso é menos óbvio, o SLA delimita o escopo e protege contra expectativas infinitas. Um SLA bem escrito define exatamente o que está e o que não está coberto, quais são os horários de atendimento, o que conta como incidente crítico e o que não conta. Sem isso, o cliente tende a esperar disponibilidade total, resposta instantânea e escopo ilimitado, e a frustração é inevitável. O SLA transforma "resolva tudo sempre" em compromissos definidos e sustentáveis.

Um SLA malfeito, por outro lado, é pior do que nenhum. Métricas impossíveis geram descumprimento crônico e conflito. Cláusulas ambíguas viram disputa. Penalidades desproporcionais quebram a relação. Por isso, escrever bem importa tanto.

As cláusulas essenciais de um contrato de SLA

Um SLA completo cobre um conjunto de elementos. Faltar qualquer um deles deixa uma brecha que mais cedo ou mais tarde vira problema. Veja o que não pode faltar.

Escopo dos serviços

Descreve com precisão quais serviços estão cobertos pelo acordo: quais sistemas, quais tipos de atendimento, quais atividades. Igualmente importante, define o que não está no escopo, evitando a expansão silenciosa das expectativas. Um escopo claro é a fundação de tudo.

Horário de cobertura

Define quando o serviço está disponível: horário comercial, estendido, 24 horas por 7 dias, e como são tratados feriados. Um SLA de disponibilidade 24x7 tem custo e estrutura muito diferentes de um de horário comercial, e essa definição precisa ser explícita.

Métricas e níveis de serviço

O coração do SLA. Define os indicadores que serão medidos e os patamares acordados: tempo de resposta, tempo de resolução, disponibilidade, e assim por diante. Cada métrica precisa ter uma definição inequívoca de como é calculada. Trataremos disso em detalhe a seguir.

Níveis de severidade ou prioridade

Nem todo incidente é igual. Um sistema crítico fora do ar para toda a operação não pode ter o mesmo prazo de uma dúvida simples de um usuário. O SLA classifica os incidentes por severidade e atribui prazos diferentes a cada nível.

Responsabilidades das partes

Define o que cabe ao fornecedor e o que cabe ao cliente. Muitos SLAs falham porque o cliente também tem obrigações (fornecer acessos, reportar corretamente, disponibilizar informações) e, quando não as cumpre, o fornecedor não pode ser responsabilizado. Deixar isso claro é proteção mútua.

Exclusões

Situações em que o SLA não se aplica: manutenções programadas e comunicadas, falhas de terceiros fora do controle do fornecedor, casos de força maior, uso indevido pelo cliente. Sem exclusões, o fornecedor responde por coisas que não estão sob seu controle.

Medição e relatórios

Como as métricas serão medidas, com qual ferramenta, e como os resultados serão reportados ao cliente e com que periodicidade. Um SLA que ninguém mede não vale nada. A transparência dos relatórios é o que sustenta a confiança.

Penalidades e créditos de serviço

O que acontece quando o nível não é atingido. Costumam ser créditos de serviço, descontos proporcionais ao descumprimento, e não multas punitivas. Precisam ser proporcionais e aplicáveis na prática.

Revisão e governança

Como e quando o SLA será revisado, e como as partes se reúnem para acompanhar o desempenho. Um SLA é um documento vivo, que se ajusta conforme a operação e as necessidades evoluem.

Como definir métricas que fazem sentido

As métricas são onde a maioria dos SLAs erra, seja por serem vagas, seja por serem impossíveis. Um bom princípio é seguir a lógica SMART: métricas específicas, mensuráveis, atingíveis, relevantes e temporais. Veja as métricas mais comuns e como tratá-las.

Tempo de resposta Do registro do chamado ao primeiro atendimento Definir o que conta como "resposta" Tempo de resolução Do registro à solução do problema Descontar o tempo aguardando o cliente Disponibilidade (uptime) Percentual de tempo que o serviço está no ar Definir janela de medição e exclusões Taxa de resolução no primeiro contato Chamados resolvidos sem escalonar Não incentivar fechamento prematuro Satisfação do usuário (CSAT) Avaliação do cliente sobre o atendimento Método de coleta claro e consistente

Dois pontos merecem atenção especial. Primeiro, a disponibilidade em percentuais engana. A diferença entre 99% e 99,9% parece pequena, mas 99% permite mais de sete horas de indisponibilidade por mês, enquanto 99,9% permite menos de 45 minutos. Sempre traduza o percentual em tempo real de parada tolerada, para que ambos os lados entendam o que estão acordando. Segundo, o tempo de resolução deve descontar o período em que o chamado fica aguardando ação do cliente, porque não é justo responsabilizar o fornecedor por atrasos que não são dele.

Como estruturar níveis de severidade

A classificação de severidade é o que torna o SLA justo e operável. Uma estrutura comum trabalha com quatro níveis, cada um com prazos próprios de resposta e resolução.

• Crítico (severidade 1): sistema essencial totalmente indisponível, parada que afeta a operação inteira ou grande parte dela. Prazos mais curtos e agressivos, muitas vezes com acionamento imediato.
• Alto (severidade 2): função importante degradada ou indisponível, com impacto relevante, mas sem parar tudo. Prazos rápidos, porém menos que o crítico.
• Médio (severidade 3): problema que afeta um usuário ou um grupo pequeno, com contorno possível. Prazos moderados.
• Baixo (severidade 4): dúvidas, solicitações e problemas menores sem impacto operacional relevante. Prazos mais folgados.

O segredo é definir com clareza o critério de cada nível, para que a classificação de um chamado não vire disputa. Vale documentar exemplos concretos de cada severidade. E é importante alinhar o prazo à realidade: prometer resolução de incidente crítico em tempo impraticável só gera descumprimento e desgaste. Melhor um prazo realista e cumprido do que um prazo heroico e sempre furado.

Penalidades: como fazer com que funcionem

As penalidades dão consequência ao SLA, mas precisam ser desenhadas com equilíbrio. O modelo mais usado e mais saudável é o de créditos de serviço: quando o fornecedor não atinge o nível acordado, o cliente recebe um crédito ou desconto proporcional ao descumprimento, aplicável na fatura seguinte.

Alguns princípios guiam boas penalidades. Elas devem ser proporcionais ao impacto, escalando conforme a gravidade e a frequência do descumprimento. Devem ser aplicáveis na prática, com um mecanismo claro de cálculo e cobrança, e não uma cláusula bonita que ninguém consegue executar. E devem preservar a relação, funcionando como incentivo à melhoria e compensação justa, não como punição que inviabiliza o contrato ou transforma o fornecedor em adversário. Penalidades desproporcionais levam o fornecedor a precificar o risco para cima, encarecendo o serviço, ou a evitar o compromisso, esvaziando o SLA.

Estrutura de referência para o seu SLA

Reunindo tudo, uma estrutura de documento que cobre as bases costuma seguir esta ordem.

• 1. Identificação e partes: quem contrata e quem presta, vigência do acordo.
• 2. Objetivo e escopo: o que o serviço cobre e o que não cobre.
• 3. Definições: os termos técnicos usados no documento, para não haver ambiguidade.
• 4. Horário de cobertura: quando o serviço está disponível.
• 5. Níveis de severidade: a classificação dos incidentes e seus critérios.
• 6. Métricas e níveis de serviço: os indicadores e os patamares acordados, com prazos por severidade.
• 7. Responsabilidades das partes: o que cabe ao fornecedor e ao cliente.
• 8. Exclusões: as situações em que o SLA não se aplica.
• 9. Medição e relatórios: como se mede e como se reporta.
• 10. Penalidades e créditos: as consequências do descumprimento.
• 11. Governança e revisão: como o acordo é acompanhado e ajustado.

Essa estrutura não é uma camisa de força, é um mapa para garantir que nenhuma base fique descoberta. Adapte à realidade do seu serviço, mas revise cada item para não deixar buracos.

Como a Ródio Tech trabalha com SLA

Na Ródio Tech, o SLA não é uma formalidade contratual, é parte do método de operação. Estruturamos nossos serviços de suporte, help desk, service desk, infraestrutura e monitoração sobre acordos de nível de serviço claros, com métricas mensuráveis, níveis de severidade bem definidos e relatórios transparentes, alinhados às boas práticas de gerenciamento de serviços do ITIL. Isso dá ao cliente a previsibilidade que ele precisa e a nós o escopo claro que permite entregar com consistência.

Estamos no mercado desde 2004, somos certificados Great Place to Work e atendemos empresas como C&A, Fleury e CERC. Se você está avaliando um contrato de TI e quer entender como estruturar um SLA que proteja a sua operação, ou quer um parceiro que opere sob acordos sérios, podemos ajudar. Conheça nossos serviços de outsourcing de TI e de support desk.

Perguntas frequentes

Qual a diferença entre SLA, SLO e SLI? O SLA é o acordo voltado ao cliente, com os níveis prometidos e as consequências do descumprimento. O SLO é o objetivo interno que o fornecedor persegue, geralmente mais rigoroso que o SLA para ter margem. O SLI é o indicador concreto medido, o número real. Os três formam uma cadeia: o SLI mede, o SLO orienta a operação, o SLA formaliza o compromisso.

Que nível de disponibilidade devo exigir no meu SLA? Depende de quão crítico é o sistema. Cada "nove" a mais (de 99% para 99,9% para 99,99%) aumenta bastante o custo e a estrutura necessária. O erro comum é exigir disponibilidade altíssima para tudo. O certo é dimensionar por criticidade: sistemas essenciais pedem mais nove, sistemas secundários toleram menos. E sempre traduza o percentual em tempo real de parada aceitável.

Penalidades muito altas garantem melhor serviço? Não. Penalidades desproporcionais levam o fornecedor a encarecer o serviço para precificar o risco, ou a resistir ao compromisso. O melhor SLA usa créditos de serviço proporcionais, que compensam o cliente de forma justa e incentivam a melhoria sem quebrar a relação. O objetivo é serviço bom e sustentável, não punição.

Posso usar um modelo de SLA pronto da internet? Como ponto de partida para entender a estrutura, sim. Mas um SLA precisa refletir a realidade específica do seu serviço, escopo, criticidade e capacidade de entrega. Modelos genéricos costumam ter métricas que não se aplicam ou que são impossíveis de medir no seu contexto. Adapte sempre, e idealmente com apoio de quem entende de operação de TI.

Referências

• Axelos. ITIL 4, práticas de Service Level Management e Service Design. https://www.axelos.com/certifications/itil-service-management
• Google Cloud. "Site Reliability Engineering", capítulos sobre SLA, SLO e SLI. https://sre.google/books/
• ISO/IEC. Norma 20000-1, gerenciamento de serviços de TI. https://www.iso.org/standard/70636.html
• Microsoft Learn. "Service level agreements" e boas práticas de acordos de serviço. https://learn.microsoft.com/en-us/azure/architecture/
• NIST. Special Publication 800-35, guia de serviços de TI e acordos de nível de serviço. https://csrc.nist.gov/publications/sp800

Principais pontos

1. SLA: sigla de Service Level Agreement (Acordo de Nível de Serviço), o documento que define de forma objetiva o que o prestador entrega, com quais prazos e o que acontece em caso de descumprimento.
2. Cadeia SLA, SLO, SLI: o SLA é o acordo voltado ao cliente, o SLO é o objetivo interno mais rigoroso perseguido pelo fornecedor, e o SLI é o indicador concreto que se mede.
3. Disponibilidade em números: 99% de disponibilidade permite mais de sete horas de indisponibilidade por mês, enquanto 99,9% permite menos de 45 minutos, por isso o percentual deve sempre ser traduzido em tempo real de parada.
4. Níveis de severidade: a estrutura comum usa quatro níveis (crítico, alto, médio e baixo), cada um com prazos próprios de resposta e resolução.
5. Penalidades: o modelo mais usado e saudável é o de créditos de serviço (descontos proporcionais ao descumprimento na fatura seguinte), não multas punitivas.