Como negociar SLA em contratos de TI sem sair no prejuízo

Um diretor de TI me disse, em janeiro deste ano: "a gente fechou uptime.com.br/" style="color:#1a365d;text-decoration:underline;font-weight:500;">SLA de 99,9% com o fornecedor de cloud. Está tudo certo".

Em março, o sistema caiu por 6 horas num horário de pico. Quando ele foi acionar a penalidade, descobriu duas coisas:

Primeiro: 6 horas em 30 dias dá 0,83% de downtime. O sistema ficou com 99,17% no mês. Ferozmente abaixo do SLA. Penalidade prevista.

Segundo: a penalidade era "crédito de 5% da mensalidade do mês". Mensalidade de R$ 38 mil. Crédito de R$ 1.900. Para um incidente que custou R$ 340 mil ao negócio.

Esse é o problema com SLA. Não é o número. É o que acontece quando ele é descumprido.

A armadilha do SLA em percentual

Percentual de uptime parece a métrica óbvia. É a métrica que todo fornecedor anuncia. É a métrica mais inútil para negociação real.

Vamos comparar dois fornecedores hipotéticos, ambos oferecendo 99,9% de uptime:

Fornecedor A: 0,1% distribuído em micro-interrupções de 30-60 segundos espalhadas ao longo do mês. Cliente final raramente nota.

Fornecedor B: 0,1% concentrado em um único incidente de 43 minutos uma vez por mês, geralmente em horário de pico.

Mesmo SLA. Realidades operacionais completamente diferentes.

O que eu negocio em vez de só percentual:

• Tempo máximo de incidente individual (MTBF, MTTR)
• Número máximo de incidentes por mês
• Limite de incidentes em horário comercial
• SLA específico para módulos críticos do sistema

Um SLA bem estruturado tem 6 a 10 métricas, não uma só.

Métricas que importam vs métricas que enchem contrato

Vou listar o que importa e o que enche contrato.

O que importa

Tempo de resposta inicial em chamado crítico: quanto tempo o fornecedor leva para reconhecer e começar a tratar um chamado P1. Negocie 15 minutos ou menos para sistemas críticos.

Tempo de resolução em chamado crítico: quanto tempo para resolver totalmente. Negocie 4 horas ou menos para P1, 8 horas para P2.

Performance: não só uptime, mas tempo de resposta da aplicação. Lentidão crônica é o pior tipo de problema porque não dispara SLA mas degrada o negócio.

Capacidade: garantia de suportar X usuários simultâneos ou Y transações por segundo.

O que enche contrato

Disponibilidade do portal de suporte: ok, é importante, mas não é diferenciador. Todo fornecedor tem.

Tempo de aprovação de mudança: métrica que o fornecedor inventa para mostrar que faz alguma coisa. Não tem impacto operacional real.

Indicadores de satisfação: NPS do suporte, etc. São agradáveis mas não geram ação.

Se um SLA tem 30 métricas, desconfie. É bagunça intencional para esconder o que falta.

Penalidades reais: o que negociar e o que aceitar

Penalidade não é dinheiro de volta. Penalidade é incentivo para o fornecedor priorizar o problema.

Se o fornecedor quebra o SLA e a penalidade é 5% do mês, ele faz cálculo de custo-benefício. Talvez seja mais barato pagar a penalidade do que investir em infraestrutura redundante.

Penalidade boa dói no caixa do fornecedor.

O que funciona:

• Crédito escalonado: 10% no primeiro descumprimento mensal, 25% no segundo, 50% no terceiro
• Direito de rescisão sem ônus após 3 meses consecutivos de descumprimento
• Indenização adicional sobre prejuízos comprovados (não substituída pelo crédito)
• Auditoria do incidente com acesso a logs completos

O que não funciona:

• Crédito que vence em 90 dias se não usado
• Crédito que só pode ser usado em compras adicionais (você precisa comprar mais para usar o crédito do erro deles)
• Limite máximo de penalidade mensal que cobre só uma fração do impacto possível

Janelas de manutenção: a brecha que o fornecedor usa

Janela de manutenção planejada não entra no cálculo de SLA. É padrão. E é onde mora boa parte da disponibilidade real perdida.

Cliente do setor de saúde que atendi: contrato com janela "até 8 horas mensais, em horário a definir pelo fornecedor com aviso de 24h".

Na prática, o fornecedor fazia 6 horas de manutenção todo terceiro sábado do mês, das 6h às 12h. Para o setor de saúde, sábado de manhã é horário de pico ambulatorial. O atendimento ficava manual a cada terceiro sábado.

O cliente nunca acionou SLA porque a janela estava dentro do contrato. Mas o impacto operacional era enorme.

O que negociar:

• Janela máxima total mensal (4h é razoável para sistemas em nuvem maduros)
• Janela definida em horário de baixa criticidade para o SEU negócio (você negocia, não o fornecedor)
• Aviso prévio mínimo (5-7 dias para manutenção planejada, exceto emergências)
• Direito de adiar manutenção em períodos críticos (fechamento mensal, datas-pico)
• Limite de manutenções emergenciais por trimestre (porque tudo pode ser "emergência")

A janela de manutenção é o lado escuro do SLA. Cobre disponibilidade real que não conta no contrato. Negocie como se contasse — porque conta para o seu negócio.

O checklist de SLA que eu uso antes de assinar qualquer contrato

Antes de qualquer contrato de TI que tenha SLA passar pela mesa do cliente, eu rodo esse checklist:

1. SLA tem percentual de uptime? Sim. Mas tem também MTTR, MTBF, e tempo máximo de incidente individual? Se não, voltar para negociação.
2. Penalidade é em dinheiro ou crédito? Se crédito, vence? Pode ser usado em qualquer compra ou só nas próximas mensalidades? Negociar para crédito sem prazo e sem restrição.
3. Penalidade é proporcional ao impacto possível? Crédito de 5% para incidente que pode custar 50% da mensalidade em prejuízo é desequilibrado.
4. Há direito de rescisão sem ônus após X descumprimentos? Se não, o fornecedor não tem incentivo real para corrigir.
5. Janela de manutenção tem limite total mensal? Está em horário não-crítico para meu negócio?
6. Há SLA específico para módulos críticos, ou só para o sistema como um todo?
7. Há SLA de performance, não só de disponibilidade?
8. Como o SLA é medido? Pelo fornecedor (auto-reporte) ou por ferramenta independente?
9. Há direito de auditar os logs em caso de divergência?
10. Há cláusula de melhoria contínua? (Se um trimestre tem mais de X incidentes, o fornecedor apresenta plano de ação documentado)

10 perguntas. Se passar nas 10, o SLA é defensável. Se falhar em mais de 3, está mal negociado.

SLA de suporte: o componente esquecido

Todo mundo negocia SLA de disponibilidade. Quase ninguém negocia SLA de suporte.

SLA de suporte é o que define como o fornecedor responde quando você abre chamado. Tempo de primeira resposta, tempo de resolução, canal de comunicação, escalação.

Sem isso, o fornecedor responde no tempo que quiser. "Chamado P1" pode demorar 4 horas para receber primeira resposta, e isso ser tecnicamente aceitável.

O que negociar:

• Classificação clara de severidade (P1/P2/P3/P4) com critérios objetivos
• Tempo máximo de primeira resposta por severidade
• Tempo máximo de resolução por severidade
• Canal disponível (telefone direto para P1, não só portal)
• Escalação automática se SLA não for cumprido
• Plano de comunicação durante incidente longo (update a cada 30 min para P1)

O que fazer com SLA já assinado e desfavorável

Cliente recorrente me pergunta: "o contrato está assinado, o SLA é ruim. O que posso fazer?"

Três opções:

1. Aditivo contratual. Documentar formalmente os incidentes recentes, calcular impacto financeiro, propor renegociação. Fornecedor geralmente topa, especialmente se o cliente acena com possibilidade de não renovação.

2. Carta-acordo paralela. Algumas vezes o fornecedor não quer aditar o contrato, mas aceita assinar carta-acordo paralela com compromissos operacionais (resposta mais rápida, comunicação adicional). Não tem força legal completa, mas em relação de longo prazo funciona.

3. Preparar saída. Se o fornecedor não se mexer, comece a planejar a substituição. 18-24 meses dá tempo. Não espere o contrato terminar para começar a pensar.

Janela de adaptação inicial: o período crítico

Tem uma fase do contrato que raramente é tratada bem: os primeiros 90 dias.

Nesse período, fornecedor está aprendendo seu ambiente. Bugs aparecem. Configurações precisam ser ajustadas. SLA padrão raramente é cumprido.

O que negociar:

• Cláusula de "go-live assistido" com SLA reduzido nos primeiros 60-90 dias
• Reuniões semanais de acompanhamento
• Equipe alocada do fornecedor exclusivamente para o cliente nesse período
• Critérios claros de "sair do go-live" — quando o contrato regular passa a valer

Sem essas cláusulas, o cliente acaba lutando com SLA contratual que o fornecedor sabe que não vai cumprir, gerando atrito desnecessário na fase mais crítica da relação.

Em resumo: SLA defensável em 7 pontos

1. Múltiplas métricas, não só uptime: tempo de resposta, throughput, taxa de erro, RPO, RTO
2. SLA mensal, não anual
3. Limite máximo total de janela de manutenção, em horário definido pelo cliente
4. Penalidade em dinheiro, escalonada por reincidência
5. Direito de rescisão sem ônus após X violações
6. SLA de suporte explícito: tempo de resposta, resolução, escalação
7. Auditoria independente do SLA reportado

SLA com esses 7 pontos é proteção real. SLA sem eles é formalidade.

Perguntas que sempre recebo sobre SLA

"Se eu negociar SLA muito apertado, o fornecedor vai aumentar muito o preço?"

Sim, vai. Mas geralmente o aumento é desproporcional à proteção que você ganha. Fornecedor que aumenta preço 40% para passar de SLA 99,9% para 99,99% está te dizendo que não tem maturidade técnica para entregar 99,99%. Procure outro.

"SLA com penalidade alta não vai gerar atrito constante na relação?"

Não, se for bem escrito. Penalidade alta funciona como dissuasor. Fornecedor que sabe que vai sair caro descumprir investe em prevenção. Acaba que SLA exigente reduz incidentes — e portanto reduz a frequência de cobrança de penalidade.

"Meu fornecedor diz que SLA escalonado é cláusula leonina. É?"

Não. É padrão em contratos corporativos de TI maduros. Fornecedor que diz isso ou está blefando ou nunca trabalhou com cliente exigente. Em qualquer dos casos, sinal amarelo.

"E se o problema vier de terceiro (cloud, telecom)?"

Tem que estar previsto. SLA bem escrito tem cláusula de "exceções por dependência de terceiros" com lista taxativa e limites de tempo aplicáveis. Sem isso, todo problema vira "culpa do terceiro" e você fica sem proteção.

O template de SLA que disponibilizo tem esse checklist embutido nas cláusulas, junto com sugestões de redação. Não substitui análise jurídica, mas dá ponto de partida muito melhor do que aceitar o template do fornecedor.

SLA por severidade: o modelo que funciona

Cláusula de SLA mal estruturada é fonte número um de conflito em contratos de TI. Cliente reclama de problema. Fornecedor responde "isso não viola o SLA". Discussão se arrasta. O problema persiste.

O modelo que reduz conflito: SLA estratificado por severidade, com definição clara de cada nível.

Severidade 1 (Crítica): sistema fora do ar ou impacto material em operação crítica. Resposta em até 30 minutos, resolução em até 4 horas, esforço dedicado contínuo, comunicação a cada 30 minutos durante a resolução.

Severidade 2 (Alta): funcionalidade importante degradada com workaround viável. Resposta em até 2 horas, resolução em até 8 horas úteis, comunicação a cada 2 horas durante a resolução.

Severidade 3 (Média): funcionalidade não crítica afetada ou problema com baixo impacto operacional. Resposta em até 4 horas úteis, resolução em até 5 dias úteis.

Severidade 4 (Baixa): melhoria, consulta, problema cosmético. Resposta em até 1 dia útil, resolução em prazo acordado caso a caso.

A classificação inicial é proposta pelo cliente. Fornecedor pode contestar com justificativa técnica. Em caso de divergência, escalation a nível executivo com prazo definido. Sem esse processo, cada chamado vira negociação.

Métricas: o que medir realmente importa

Outro ponto sensível: o que o SLA mede precisa refletir o que o cliente valoriza. Métricas comuns que estão fora de calibração com a necessidade real:

Uptime mensal apenas. Métrica clássica, mas pode esconder distribuição ruim. 99,5% mensal soa bem — mas representa 3,6 horas de indisponibilidade. Se essas 3,6 horas vierem em 30 minutos de pico, o impacto é maior que se vierem distribuídas. Métrica complementar: distribuição de incidentes por hora do dia, pico de impacto medido em transações afetadas.

Tempo médio de resolução. Média esconde outliers. Empresa precisa medir percentil 90 e 95 — esses são os que afetam clientes percebidamente. Outliers (incidentes que resistem 24h+) merecem tratamento separado.

Quantidade de chamados. Métrica vaidosa. Quantidade alta pode ser sinal de muito uso ou de muito problema. Métrica útil é "chamados por usuário ativo" ou "chamados por transação processada" — densidade, não volume absoluto.

Definir métricas relevantes economiza horas de discussão estéril durante a vigência. E vincula o SLA ao que de fato importa para o negócio.

A cláusula de revisão periódica do SLA

SLA congelado durante 3 anos vira anacronismo. Tecnologia evolui, expectativas evoluem, mercado evolui. Contrato sério prevê revisão periódica dos parâmetros.

Modelo que funciona: revisão semestral dos indicadores e metas, com comitê de governança entre as partes. Pontos cobertos: análise dos indicadores reais versus contratados; identificação de tendências (melhora ou piora); ajustes de metas conforme evolução do contexto; tratamento de incidentes recorrentes com plano de ação.

O comitê serve também como instrumento de relacionamento. Discussão técnica regular evita acumulação de tensão. Quando há tensão, ela aparece e é tratada no momento certo — não explode no fim do contrato.

Tempo dedicado: 4-8 horas semestrais por parte. Benefício: relacionamento sustentável e SLA que realmente protege o cliente ao longo de toda a vigência. Empresa que ignora essa prática chega ao fim do contrato com acumulado de problemas — e renovação fica difícil.