Definir quais SLAs um bom contrato de serviços gerenciados de TI deve ter é uma das decisões mais estratégicas que um gestor de tecnologia pode tomar antes de assinar com um MSP. Esses indicadores não são apenas cláusulas contratuais: eles traduzem, em números e prazos concretos, o nível de comprometimento do fornecedor com a disponibilidade dos seus sistemas, a velocidade de resposta a incidentes e a continuidade do negócio — especialmente crítica em ambientes que lidam com dados sensíveis, transações financeiras ou infraestrutura em nuvem.
O problema é que muitos contratos de serviços gerenciados circulam com SLAs genéricos, que parecem robustos no papel mas deixam brechas significativas na prática: janelas de atendimento vagas, métricas de uptime sem penalidades reais ou ausência de distinção entre incidentes críticos e chamados de baixa prioridade. Para empresas de médio e grande porte — sobretudo as que operam em setores regulados ou dependem de ambientes Azure e Microsoft 365 — essa imprecisão pode custar caro.
Nas próximas seções, você vai entender quais são os SLAs essenciais que qualquer contrato de MSP sério precisa contemplar, o que cada um significa na prática e como avaliá-los com critério técnico antes de fechar qualquer acordo.
O que é SLA em um contrato de serviços gerenciados de TI?
SLA é a sigla para Service Level Agreement — em português, Acordo de Nível de Serviço. Trata-se de um documento formal, parte integrante do contrato de serviços gerenciados de TI, que define com precisão quais compromissos o fornecedor assume em relação à qualidade, disponibilidade e tempo de resposta dos serviços prestados.
Em termos práticos, o SLA responde perguntas como: em quanto tempo o fornecedor deve abrir um chamado? Qual é o prazo máximo para resolver uma falha crítica? Quanto tempo os sistemas podem ficar indisponíveis por mês sem que isso configure descumprimento contratual? Sem essas respostas formalizadas, a relação entre empresa contratante e MSP fica sujeita a interpretações subjetivas — e, na prática, quem perde é sempre o cliente.
No contexto de um MSP Microsoft que gerencia ambientes Azure e Microsoft 365, os SLAs ganham ainda mais relevância porque os serviços de nuvem já possuem seus próprios acordos de nível de serviço com a Microsoft — e o MSP precisa garantir que os SLAs contratuais com o cliente sejam compatíveis com o que a plataforma efetivamente entrega.
Por que os SLAs são indispensáveis em contratos de TI gerenciada?
Um contrato de serviços gerenciados sem SLAs bem definidos é, na prática, um contrato de intenções — não de compromissos. A ausência de métricas claras cria um ambiente onde o fornecedor pode alegar que "atendeu dentro do prazo razoável" sem que haja parâmetro objetivo para contestar essa afirmação.
Para empresas de médio e grande porte, especialmente as que operam em setores regulados como financeiro ou saúde, essa lacuna representa risco direto ao negócio. Uma falha no ambiente de produção sem SLA de recuperação definido pode se traduzir em horas de indisponibilidade, perda de receita, violações de compliance e, no caso de ambientes que processam transações via Pix, exposição regulatória perante o Banco Central.
Os SLAs também funcionam como instrumento de governança: eles criam a base para relatórios periódicos, revisões de desempenho e decisões de renovação ou rescisão contratual. Sem eles, a gestão do fornecedor vira um exercício de percepção subjetiva, não de dados concretos.
Quais SLAs um bom contrato de serviços gerenciados de TI deve ter?
1. Tempo de Resposta (Response Time): o primeiro contato após um chamado
O tempo de resposta define em quanto tempo o fornecedor deve acusar o recebimento do chamado e iniciar o atendimento — não necessariamente resolver o problema, mas demonstrar que o incidente foi registrado e que um técnico está alocado. Esse indicador é fundamental porque sinaliza ao cliente que sua demanda foi reconhecida.
Em contratos maduros, o tempo de resposta varia conforme a criticidade do chamado: incidentes críticos (sistemas de produção fora do ar) costumam exigir resposta em 15 a 30 minutos; chamados de baixa prioridade podem ter janela de até 8 horas úteis. O contrato deve especificar esses prazos para cada nível de severidade.
2. Tempo de Resolução (Resolution Time): prazo máximo para solucionar incidentes
Diferente do tempo de resposta, o tempo de resolução define o prazo máximo para que o problema seja efetivamente solucionado. Esse é, frequentemente, o SLA mais disputado nas negociações — porque depende de variáveis técnicas nem sempre controláveis pelo MSP, como falhas em infraestrutura de terceiros ou necessidade de acesso físico ao ambiente.
Bons contratos distinguem resolução de contorno (workaround): um sistema pode ser restaurado parcialmente em 2 horas, mas a correção definitiva pode levar 48 horas. Ambos os prazos devem estar formalizados.
3. Disponibilidade e Uptime: garantia de funcionamento dos sistemas (ex.: 99,9%)
O SLA de disponibilidade expressa, em percentual, o tempo em que os sistemas devem estar operacionais em um determinado período (geralmente mensal). O famoso "três noves" (99,9%) equivale a aproximadamente 43 minutos de indisponibilidade permitida por mês. Já 99,99% reduz esse limite para cerca de 4 minutos.
É essencial que o contrato especifique o que conta como indisponibilidade — manutenções programadas geralmente são excluídas do cálculo — e como o uptime é medido (monitoramento contínuo, janelas de verificação, etc.). Em ambientes Azure, a Microsoft já publica SLAs de disponibilidade por serviço, e o MSP deve alinhar seus compromissos contratuais a esses limites reais.
4. Classificação e Priorização de Chamados: critérios para incidentes críticos, altos, médios e baixos
Sem uma matriz de priorização clara, todos os chamados tendem a ser tratados como urgentes — ou nenhum é. Um bom contrato define ao menos quatro níveis de severidade:
- Crítico: sistema de produção indisponível, impacto em toda a operação (ex.: ERP fora do ar, falha em ambiente de pagamentos).
- Alto: funcionalidade crítica degradada, impacto parcial na operação.
- Médio: funcionalidade não crítica afetada, existe contorno disponível.
- Baixo: dúvidas, solicitações de melhoria, ajustes não urgentes.
Para cada nível, devem estar definidos os prazos de resposta e resolução correspondentes.
5. Janela de Atendimento: horário comercial, 24×7 ou plantão de emergência
A janela de atendimento define quando o MSP está disponível para receber e tratar chamados. Contratos que cobrem apenas horário comercial (8h às 18h, dias úteis) são adequados para ambientes de escritório sem operação noturna. Já empresas com operações contínuas — como e-commerces, fintechs ou hospitais — precisam de cobertura 24×7 ou, no mínimo, plantão de emergência fora do horário comercial.
O contrato deve deixar explícito se o atendimento fora do horário padrão tem custo adicional e quais canais estão disponíveis (telefone, portal, WhatsApp, e-mail).
6. Tempo de Recuperação de Desastres (RTO e RPO): continuidade do negócio em caso de falha grave
Dois dos SLAs mais críticos — e frequentemente ausentes em contratos de MSPs menos maduros — são o RTO (Recovery Time Objective) e o RPO (Recovery Point Objective).
- RTO define o tempo máximo para restaurar os sistemas após um desastre (ex.: 4 horas).
- RPO define o ponto máximo de perda de dados aceitável, medido em tempo (ex.: dados de até 1 hora antes do incidente devem ser recuperáveis).
Esses parâmetros têm impacto direto na estratégia de backup e recuperação. Empresas que ainda não definiram esses números devem considerar que um ataque de ransomware sem backup adequado pode tornar a recuperação inviável — e um contrato sem RTO/RPO definidos não oferece nenhuma garantia nesse cenário.
7. Indicadores de Desempenho (KPIs): métricas que comprovam o cumprimento dos SLAs
SLAs sem KPIs são declarações sem verificação. Os principais indicadores que devem constar no contrato incluem:
- Percentual de chamados respondidos dentro do prazo acordado.
- Percentual de chamados resolvidos dentro do prazo acordado.
- Uptime efetivo dos sistemas monitorados.
- Tempo médio de resposta (MTTR — Mean Time to Respond).
- Tempo médio de resolução (MTTR — Mean Time to Resolve).
- Volume de incidentes recorrentes (indicador de qualidade da correção).
Esses dados devem ser coletados automaticamente por ferramentas de monitoramento e disponibilizados ao cliente em relatórios periódicos.
8. Penalidades e Compensações: o que acontece quando o fornecedor descumpre os acordos
Um SLA sem cláusula de penalidade é uma promessa sem consequência. O contrato deve prever o que acontece quando os prazos acordados não são cumpridos — geralmente na forma de créditos de serviço, descontos na fatura do período ou, em casos graves, direito de rescisão sem multa.
A estrutura mais comum é escalonada: descumprir o SLA em até 5% do mês gera um crédito de X%; acima de 10%, o crédito aumenta. O importante é que as penalidades sejam proporcionais ao impacto do descumprimento e que o processo para solicitá-las seja simples e documentado.
9. Processo de Escalonamento: quem acionar quando o nível de suporte atual não resolve
Todo ambiente de TI gerenciado enfrenta, eventualmente, incidentes que ultrapassam a capacidade do nível 1 de suporte. O contrato deve definir uma matriz de escalonamento clara: quais são os níveis de suporte (N1, N2, N3), em quanto tempo um chamado sobe de nível se não for resolvido, e quem são os pontos de contato em cada escalada — incluindo nomes, cargos e canais de comunicação.
Em MSPs que atuam com Microsoft Azure, o escalonamento pode incluir acionamento direto do suporte Microsoft — e o contrato deve esclarecer se esse canal está disponível e em quais condições.
10. Relatórios e Revisão Periódica dos SLAs: transparência e melhoria contínua
O ciclo de gestão dos SLAs não termina na assinatura do contrato. Bons contratos preveem relatórios mensais de desempenho — com os KPIs acordados — e reuniões periódicas de revisão (trimestrais ou semestrais) para avaliar se os níveis de serviço ainda são adequados às necessidades do negócio.
Essa prática, além de garantir transparência, permite ajustar os SLAs conforme o ambiente evolui: uma empresa que migra para Azure, por exemplo, pode precisar de SLAs mais rigorosos de disponibilidade do que tinha no ambiente on-premises anterior.
Diferença entre SLA, OLA e UC: como esses acordos se complementam no contrato
Além do SLA, dois outros tipos de acordo aparecem frequentemente em contratos de TI gerenciada e causam confusão:
- OLA (Operational Level Agreement): acordo interno entre equipes do próprio fornecedor de serviços, definindo como cada área contribui para o cumprimento do SLA externo. Por exemplo, o acordo entre o time de suporte N1 e o time de infraestrutura N3 sobre prazos de escalonamento.
- UC (Underpinning Contract): contrato com fornecedores externos que suportam a entrega do serviço — como o contrato do MSP com a Microsoft Azure ou com um provedor de conectividade. O UC define o que o MSP pode garantir ao cliente com base no que seus próprios fornecedores entregam.
A relação entre os três é hierárquica: o SLA define o que o cliente espera; o OLA organiza internamente como o MSP entrega; o UC estabelece os limites impostos por terceiros. Um MSP sério conhece esses três níveis e garante que os SLAs prometidos ao cliente são sustentados por OLAs e UCs coerentes.
SLA x SLM: como o Gerenciamento de Nível de Serviço garante o cumprimento dos acordos
O SLM (Service Level Management) — Gerenciamento de Nível de Serviço — é o processo contínuo de monitoramento, reporte e melhoria dos SLAs. Enquanto o SLA é o documento estático que define os compromissos, o SLM é o processo dinâmico que garante que esses compromissos sejam cumpridos na prática.
Na metodologia ITIL, o SLM é uma das práticas centrais de gestão de serviços. Ele envolve coleta automatizada de dados de desempenho, análise de tendências, identificação de causas-raiz de descumprimentos e proposição de melhorias. Para o cliente, o SLM se manifesta nos relatórios periódicos e nas reuniões de revisão — que são, portanto, parte do serviço contratado, não um extra.
Ao fazer a transição da TI interna para um modelo gerenciado, uma das primeiras perguntas a fazer ao MSP é justamente como funciona o processo de SLM: quais ferramentas são usadas para monitoramento, com que frequência os relatórios são emitidos e quem é o responsável pela gestão do contrato do lado do fornecedor.
Como avaliar se os SLAs propostos pelo fornecedor são realistas para o seu negócio
SLAs agressivos demais podem ser sinal de proposta comercial irresponsável — ou de um fornecedor que não pretende honrá-los. Avaliar a viabilidade dos SLAs propostos exige olhar tanto para as necessidades do seu negócio quanto para a capacidade real do fornecedor de entregá-los.
Checklist: perguntas essenciais antes de assinar um contrato de TI gerenciada
- O fornecedor tem equipe suficiente para cobrir a janela de atendimento prometida (incluindo férias e rotatividade)?
- Quais ferramentas de monitoramento são usadas? Os dados são acessíveis ao cliente em tempo real?
- O MSP já prestou serviços para empresas do mesmo porte e setor? Há referências verificáveis?
- As certificações técnicas da equipe são compatíveis com a complexidade do ambiente a ser gerenciado?
- Os SLAs de RTO e RPO são suportados por uma estratégia de backup documentada?
- O processo de escalonamento inclui acesso ao suporte do fabricante (ex.: Microsoft) quando necessário?
- As penalidades por descumprimento estão claramente definidas e são proporcionais ao impacto?
- O contrato prevê revisão periódica dos SLAs conforme o ambiente evolui?
Erros comuns em SLAs de TI que prejudicam a empresa contratante
- Confundir tempo de resposta com tempo de resolução: aceitar um SLA de "resposta em 30 minutos" sem definir prazo de resolução é um erro frequente.
- Não definir o que conta como indisponibilidade: fornecedores podem excluir manutenções, incidentes de terceiros e janelas de atualização do cálculo de uptime — reduzindo artificialmente o tempo de indisponibilidade computado.
- Ausência de RTO e RPO: contratos que não definem esses parâmetros deixam a empresa sem garantia em cenários de desastre.
- SLAs genéricos sem distinção por criticidade: um único prazo de resolução para todos os chamados ignora que uma falha no sistema de pagamentos é radicalmente diferente de um problema de impressora.
- Processo de penalidade burocrático demais: se solicitar o crédito exige abertura de processo formal complexo, na prática o cliente nunca aciona a cláusula.
O que mais não pode faltar em um contrato de suporte de TI além dos SLAs?
Escopo detalhado dos serviços cobertos e excluídos
O contrato deve listar explicitamente quais serviços estão incluídos no escopo — monitoramento proativo, gestão de patches, suporte a usuários, administração de Azure, gestão de licenças Microsoft 365 — e, igualmente importante, o que está fora do escopo. Serviços excluídos que não estejam documentados viram fonte de conflito: o cliente assume que está coberto; o MSP cobra como projeto adicional.
Cláusulas de confidencialidade e segurança da informação
Um MSP tem acesso privilegiado a sistemas, dados e credenciais da empresa contratante. O contrato deve incluir NDA (Non-Disclosure Agreement) robusto, definir como as credenciais são armazenadas e gerenciadas (idealmente via cofre de senhas corporativo), e estabelecer responsabilidades em caso de incidente de segurança originado por falha do fornecedor. Em ambientes que processam dados pessoais, as cláusulas devem estar alinhadas à LGPD, com o MSP figurando formalmente como operador de dados.
Para empresas que têm dúvidas sobre os riscos de terceirizar a TI, a qualidade dessas cláusulas é um dos principais fatores de mitigação de risco.
Condições de rescisão e transição de fornecedor
O contrato deve prever prazos de aviso prévio para rescisão (geralmente 30 a 90 dias), condições em que a rescisão pode ocorrer sem multa (incluindo descumprimento reiterado de SLAs), e um plano de transição que garanta continuidade operacional durante a migração para outro fornecedor. Sem essa cláusula, a empresa pode ficar refém de um MSP com desempenho insatisfatório por não conseguir sair do contrato sem custos proibitivos.
Exemplos práticos de SLAs em contratos de TI gerenciada por porte de empresa
SLAs recomendados para pequenas e médias empresas (PMEs)
PMEs geralmente operam em horário comercial e têm menor complexidade de ambiente. Uma estrutura de SLA adequada para esse perfil inclui:
- Tempo de resposta: até 1 hora para incidentes críticos; até 4 horas para médios e baixos.
- Tempo de resolução: até 8 horas para críticos; até 3 dias úteis para médios.
- Uptime: 99,5% (equivale a cerca de 3,6 horas de indisponibilidade por mês).
- Janela de atendimento: horário comercial (8h–18h), dias úteis, com plantão de emergência para incidentes críticos.
- RTO: 8 horas; RPO: 24 horas.
SLAs recomendados para grandes empresas e ambientes críticos
Grandes empresas, fintechs, instituições financeiras e ambientes que processam transações em tempo real exigem SLAs significativamente mais rigorosos:
- Tempo de resposta: até 15 minutos para incidentes críticos; até 1 hora para altos.
- Tempo de resolução: até 4 horas para críticos; até 8 horas para altos.
- Uptime: 99,9% ou superior (menos de 44 minutos de indisponibilidade por mês).
- Janela de atendimento: 24×7, com equipe dedicada ou de plantão.
- RTO: 2 horas; RPO: 1 hora ou menos.
- Relatórios: mensais com dashboard em tempo real disponível ao cliente.
Nesses ambientes, a estratégia de backup tem papel central na viabilidade dos SLAs de RTO e RPO. Soluções como backup corporativo com Acronis oferecem recursos de recuperação granular que tornam esses prazos tecnicamente alcançáveis.
Perguntas Frequentes (FAQ)
Qual é o tempo de resposta ideal em um SLA de TI?
Não existe um tempo de resposta universalmente ideal — ele depende da criticidade do ambiente e do impacto do incidente no negócio. Como referência, incidentes críticos (sistemas de produção fora do ar) devem ter resposta em 15 a 30 minutos em ambientes de alta disponibilidade. Para ambientes de escritório com operação em horário comercial, 1 hora para críticos e 4 horas para chamados de média prioridade é uma faixa razoável. O mais importante é que os prazos estejam segmentados por nível de severidade e que reflitam a capacidade real da equipe do fornecedor — não apenas o que soa bem na proposta comercial.
O que acontece se o fornecedor de TI descumprir o SLA?
Depende do que está previsto em contrato. Em contratos bem estruturados, o descumprimento do SLA gera créditos de serviço (descontos na fatura do período proporcional ao tempo de violação), e descumprimentos reiterados podem dar ao cliente o direito de rescisão contratual sem multa. Em contratos mal redigidos, o descumprimento gera apenas uma conversa — sem consequência financeira. Por isso, revisar as cláusulas de penalidade antes de assinar é tão importante quanto negociar os prazos em si. Se o fornecedor resistir a incluir penalidades contratuais, isso é um sinal de alerta sobre a confiança que ele mesmo tem na sua capacidade de entrega.
