SLA de suporte de TI: defina métricas e cobre seu fornecedor

Definir um SLA de suporte de TI adequado é a diferença entre ter um contrato executável e assinar um documento que ninguém vai abrir até a próxima crise. Não raro, empresas fecham acordos de suporte repletos de expressões como “atendimento ágil” e “resolução em tempo hábil”, termos que soam bem na proposta comercial, mas não dão base para cobrar absolutamente nada quando o servidor cai ou o sistema de gestão para. Um acordo de nível de serviço sem números concretos cria falsa sensação de segurança enquanto o problema cresce.

Este guia cobre o que um SLA de suporte de TI de verdade precisa conter: quais métricas devem estar no documento, como montar a tabela de prioridades, quais cláusulas tornam o acordo executável e como monitorar o cumprimento todo mês. A Corebit opera com SLAs formalizados em contrato, com prazos definidos por prioridade e cobertura tanto remota quanto presencial, esse modelo serve de referência prática ao longo do texto.

O que é um SLA de suporte de TI (e por que a maioria falha)

Um acordo de nível de serviço é um documento contratual que define as obrigações de desempenho de um fornecedor de TI: quanto tempo tem para responder, quanto tempo tem para resolver e qual percentual do tempo o serviço precisa estar disponível. Resposta, resolução e disponibilidade medem coisas distintas e precisam de metas separadas.

Pense em uma empresa com o ERP fora do ar. O tempo de resposta mede quanto tempo o fornecedor levou para abrir o chamado e iniciar o atendimento. O tempo de resolução, referenciado na literatura técnica principalmente pela sigla MTTR (mean time to resolve), mede quanto tempo levou até o sistema voltar a funcionar. A disponibilidade mede qual percentual do mês aquele ERP ficou acessível. Confundir esses conceitos é o primeiro erro de quem redige um SLA.

Por que SLAs sem números e janelas de contagem não funcionam

Um contrato que diz “suporte prestado com rapidez” não tem como ser cobrado. Para que o acordo de nível de serviço seja executável, ele precisa especificar número, unidade de medida, janela de contagem e o que pausa ou reinicia o prazo. A ISO/IEC 20000-1 serve de referência para padronização no Brasil e deixa claro que metas sem critério de apuração são apenas burocracia. Um SLA só protege o cliente quando cada prazo tem um número concreto associado. “Resolução em até 4 horas úteis a partir do registro do ticket” é cobrável. “Resolução em tempo hábil” não é, e essa distinção precisa estar clara antes de assinar qualquer contrato.

As métricas e KPIs do SLA de suporte de TI que precisam estar no documento

Monitorar desempenho de suporte sem os indicadores certos é como dirigir olhando só para o velocímetro: você sabe a velocidade, mas não sabe se o motor está queimando.

Taxa de cumprimento de SLA, MTTR e tempo de primeira resposta

As métricas operacionais mais importantes têm fórmulas diretas. A taxa de cumprimento de SLA é calculada assim: tickets resolvidos no prazo, divididos pelo total de tickets sujeitos ao SLA, multiplicados por 100. O MTTR é a soma do tempo de resolução de todos os chamados fechados dividida pelo número de chamados fechados. O tempo de primeira resposta é a soma do intervalo entre abertura e primeiro contato dividida pelo número de tickets respondidos.

No mercado brasileiro, referências setoriais indicam que fornecedores de alto desempenho mantêm taxas de cumprimento de SLA de primeira resposta acima de 96%. Se o seu fornecedor não consegue apresentar esse número mensalmente, há um problema de transparência ou de execução, e os dois precisam ser tratados.

FCR, taxa de reabertura e CSAT como indicadores de qualidade real

Monitorar apenas conformidade de prazo pode mascarar problemas crônicos. Um fornecedor pode fechar chamados dentro do prazo e reabri-los logo depois, o que indica que a solução foi superficial. O FCR, ou taxa de resolução no primeiro contato, revela isso: tickets resolvidos na primeira interação divididos pelo total de tickets, multiplicados por 100. A taxa de reabertura complementa esse número mostrando quantos chamados voltaram após o fechamento.

O CSAT, percentual de avaliações positivas após o encerramento do chamado, fecha o ciclo medindo a percepção do usuário. Um fornecedor que fecha chamados rapidamente mas recebe avaliações ruins dos usuários provavelmente resolve rápido e mal. FCR, taxa de reabertura e CSAT precisam aparecer no relatório mensal junto com as métricas de prazo, eles revelam a qualidade do serviço onde os indicadores de tempo não chegam.

Como estruturar a tabela de prioridades e prazos

Sem critérios objetivos de prioridade, todo chamado vira urgente ou nenhum vira. O modelo mais funcional usa quatro níveis baseados na combinação de impacto no negócio e urgência do problema.

Matriz de impacto x urgência: como classificar chamados sem subjetividade

P1 é indisponibilidade total de um serviço crítico ou múltiplos usuários afetados simultaneamente. P2 é degradação grave com impacto em processos essenciais. P3 é problema localizado sem risco imediato de paralisação. P4 é dúvida pontual ou melhoria sem impacto operacional. Esses critérios precisam estar escritos no contrato com exemplos concretos, porque a interpretação subjetiva de “urgente” é a principal causa de conflito entre cliente e fornecedor.

Benchmarks de prazos para 2026 e como adaptá-los ao seu contexto

Os intervalos de referência praticados no mercado brasileiro em 2026, com base em guias de gestão de serviços de TI e contratos de suporte gerenciado, apontam para as seguintes metas por prioridade:

Prioridade	Resposta inicial	Resolução
P1 / Crítico	até 15 min	até 2 h
P2 / Alto	até 1 h	até 4 h
P3 / Médio	até 4 h	até 24 h
P4 / Baixo	até 24 h	até 72 h

Esses são referenciais, não regras absolutas, variações existem conforme o porte da empresa e o escopo contratado. O contrato precisa especificar se os prazos contam em horas úteis ou corridas e qual é a janela de atendimento contratada: 8×5, 12×5 ou 24×7. Um SLA de P1 com resolução em 2 horas corridas e atendimento apenas em horário comercial é contraditório e vai gerar conflito na primeira crise de madrugada.

Cláusulas que tornam o SLA executável no contrato

Sem as cláusulas certas, o SLA é uma lista de boas intenções. Com elas, é um instrumento de cobrança real.

Escopo, critério de início da contagem e responsabilidades das partes

Algumas cláusulas evitam a maioria das disputas. A primeira é o escopo: quais sistemas, usuários, filiais e tipos de incidente estão cobertos e o que fica excluído, como projetos sob demanda ou equipamentos fora de garantia. A segunda é o critério de início: a contagem começa no registro do ticket com número de protocolo válido, não no momento em que o problema surgiu. Sem esse critério, o fornecedor pode argumentar que o relógio só começou quando ele “tomou conhecimento” do problema.

Igualmente importante é a matriz de responsabilidades. O contrato deve dizer o que compete ao fornecedor e o que compete ao cliente. Exemplos práticos: fornecer acesso remoto e credenciais é obrigação do cliente; registrar, diagnosticar e corrigir o incidente é obrigação do fornecedor. Sem essa divisão clara, qualquer atraso vira jogo de culpa.

Escalonamento automático, pausa do prazo e penalidades proporcionais

O escalonamento precisa de gatilhos objetivos escritos no contrato. Um exemplo funcional: chamado P1 não estabilizado em 30 minutos sobe automaticamente para N2; após 60 minutos sem solução, o gestor de operações é acionado. Sem essa regra, o chamado crítico fica parado no nível errado enquanto o técnico tenta resolver sozinho.

O contrato também deve definir o que pausa a contagem do prazo, como dependência formal do cliente ou manutenção programada comunicada com 72 horas de antecedência. Para penalidades, o modelo mais usado é crédito proporcional sobre a mensalidade por violação confirmada, com percentual vinculado ao nível de prioridade descumprido. Em contratos de suporte gerenciado para pequenas e médias empresas, faixas entre 5% e 10% da mensalidade por evento aparecem com frequência, embora o mercado registre variações mais amplas dependendo do escopo e do porte do acordo. SLAs com metas irreais são mais difíceis de defender em caso de disputa, portanto o equilíbrio entre meta ambiciosa e meta executável protege os dois lados.

Como monitorar e cobrar o cumprimento do SLA de suporte de TI todo mês

Assinar um bom SLA e não monitorar o cumprimento é o mesmo que não ter SLA nenhum. O acompanhamento ativo é o que transforma o documento em ferramenta de gestão.

O que exigir no relatório mensal do fornecedor

O relatório mensal precisa ser entregue por obrigação contratual, não solicitado pelo cliente a cada mês. Os indicadores mínimos são: volume de chamados por prioridade, tempo médio de primeira resposta, MTTR, taxa de cumprimento de SLA, taxa de reabertura, indisponibilidades registradas e CSAT. A recusa em fornecer esse relatório de forma sistemática é um sinal de risco e deve ser tratada como critério de avaliação do fornecedor, não como questão administrativa secundária.

Sinais de descumprimento e como agir sem conflito desnecessário

Alguns padrões indicam problemas antes que eles se tornem crises. Tickets P1 fechados fora do prazo sendo registrados como “dentro do SLA” por critério equivocado de contagem, taxa de reabertura crescente mês a mês e ausência de escalonamento em incidentes críticos são alertas concretos. O caminho estruturado começa pela revisão do relatório com o fornecedor, segue para notificação formal com base nas cláusulas de penalidade e, se o problema for sistêmico, termina na renegociação de metas ou na rescisão do contrato.

O que diferencia um SLA real de uma promessa de atendimento

Muitos fornecedores respondem com agilidade nos primeiros meses do contrato e desaceleram progressivamente, justamente porque não há consequência formal para o atraso. O compromisso verbal não tem como ser cobrado, e essa ausência de mecanismo de pressão é o que explica a deterioração do serviço ao longo do tempo.

SLA definido em contrato x compromisso verbal: onde está a diferença

Um acordo de nível de serviço real tem métricas mensuráveis, janela de contagem definida, relatório mensal obrigatório e penalidade escrita. A Corebit opera com esse modelo: SLAs formalizados em contrato com prazos específicos por prioridade e cobertura tanto remota quanto presencial. Para pequenas e médias empresas que buscam suporte ágil sem depender de um técnico presente no escritório o tempo todo, essa estrutura garante que o prazo está no papel e a penalidade está definida, não apenas prometida na proposta comercial.

Perguntas para avaliar qualquer fornecedor de TI antes de assinar

Antes de fechar contrato com qualquer fornecedor, faça estas perguntas diretamente:

• Os prazos de resposta e resolução por prioridade estão escritos no contrato?
• O relatório mensal de desempenho é entregue por obrigação contratual?
• O contrato define o que pausa e o que reinicia a contagem do prazo?
• Hápenalidade prevista para violaçãode SLA em chamados P1?
• O atendimento cobre tanto suporte remoto quanto presencial quando necessário?

Se a resposta a qualquer uma dessas perguntas for “não” ou “a gente combina depois”, a decisão já está tomada, e você ainda não assinou nada.

Conclusão

Um SLA de suporte de TI só protege a empresa quando reúne métricas concretas, cláusulas executáveis e um processo ativo de monitoramento mensal. Documento sem número, sem penalidade e sem relatório obrigatório é burocracia com aparência de garantia, e vai falhar no momento em que mais importa.

Na prática, o acordo precisa definir prioridades com critérios objetivos usando a matriz de impacto por urgência, incluir cláusulas de escopo, escalonamento e penalidade redigidas sem ambiguidade e prever a entrega do relatório mensal como parte integrante do serviço contratado. Esses elementos juntos transformam o SLA de promessa em instrumento de gestão real.

Na hora de escolher um fornecedor de TI, exija que o SLA esteja no contrato, não apenas na proposta comercial. Fornecedores que operam com acordos formalizados, prazos claros por prioridade e cobertura remota e presencial, como a Corebit, demonstram que esse nível de estrutura é viável sem burocracia excessiva. Se o fornecedor não aceita colocar os prazos no papel, a resposta sobre o que esperar quando o sistema cair já está dada.

Perguntas Frequentes (FAQs) – SLA de suporte de TI: defina métricas e cobre seu fornecedor