Um SLA de TI bem construído responde a uma pergunta simples que qualquer gestor ou analista de tecnologia já ouviu dos usuários: “quando isso vai ser resolvido?”. Sem uma resposta clara e documentada, cada chamado vira uma negociação informal, o backlog cresce sem critério e a percepção de qualidade do suporte cai, independentemente do esforço real da equipe.
O problema, na maioria das empresas, não é a ausência do documento. É que o SLA existe em alguma pasta, com prazos genéricos que ninguém revisou desde a implantação, sem vínculo com ferramentas e sem consequência real pelo descumprimento. Resultado: uma folha de papel que não orienta nada.
Este guia mostra como criar um SLA de TI que funcione na prática. Com a estrutura certa, as métricas adequadas para cada tipo de serviço e os critérios que transformam o acordo em um instrumento de governança, não em promessa vazia.
O que é um SLA de TI (e o que ele não é)
SLA de TI, do inglês Service Level Agreement, é um contrato formal entre um provedor de serviços de TI e seu cliente, definindo os níveis de serviço que serão entregues. Ele detalha direitos e deveres de ambas as partes, estipula prazos de atendimento, métricas de qualidade, disponibilidade de sistemas e responsabilidades de cada envolvido.
No contexto interno das empresas, o “cliente” é qualquer área que depende da TI para operar: comercial, financeiro, operações, RH. Isso significa que o SLA não é exclusivo de contratos com fornecedores externos; ele é igualmente necessário para regular a relação entre o time de TI e o restante da organização.
O que o SLA não é:
- Um documento feito uma vez e esquecido na intranet;
- Uma lista de metas definidas apenas pela TI, sem consultar as áreas atendidas;
- Um substituto para processos e ferramentas de gestão;
- Sinônimo de penalidade. Ele deve funcionar como referência de melhoria contínua.
Segundo a ABNT, que padroniza a gestão de serviços de TI no Brasil, o SLA deve cobrir indicadores claros e mensuráveis, evitando interpretações subjetivas que gerem conflitos entre equipes. Sem um SLA bem estruturado, tudo vira emergência.
Por que criar um SLA de TI agora
Equipes de TI em empresas de 50 a 500 colaboradores costumam operar sem SLA formal por um motivo simples: a operação cresceu rápido demais para parar e documentar. O suporte vai acontecendo, os chamados chegam por WhatsApp, e-mail ou corredor, e o que deveria ser um processo vira um conjunto de favores.
Além disso, o perfil do público atendido mudou. Colaboradores cada vez mais digitais têm expectativas altas sobre tempo de resposta. Estudos de mercado apontam que atrasos e falta de previsibilidade estão entre as principais causas de insatisfação, e a gestão de SLA surge como prática essencial para garantir que os serviços sejam entregues dentro dos padrões esperados.
Para o time de TI, o benefício também é direto: com um SLA em vigor, é possível demonstrar resultados para a diretoria com dados concretos, priorizar chamados com critério e negociar capacidade de equipe com base em volume real de demanda.
Leia mais:
Do WhatsApp ao SLA: como organizar chamados de TI e profissionalizar o suporte.
Tipos de SLA de TI: qual modelo usar
Antes de definir métricas, é preciso escolher o modelo de SLA mais adequado à sua realidade. A indústria categoriza os SLAs em diferentes tipos para atender a necessidades específicas. O SLA baseado em serviço é um acordo padrão aplicado a todos os clientes que utilizam um determinado serviço, sendo comum em ofertas de SaaS. O SLA baseado no cliente é personalizado para atender às exigências exclusivas de uma organização, cobrindo todos os serviços que ela consome.
Existe ainda um terceiro modelo, menos comum mas muito útil em operações maiores: o SLA multinível, que combina os dois anteriores. Nele, um conjunto de regras vale para toda a empresa (nível corporativo), enquanto ajustes específicos são feitos por área ou tipo de serviço.
Para equipes de TI em empresas de médio porte, o modelo baseado em serviço é geralmente o ponto de partida mais prático: define prazos por tipo de chamado e permite evolução gradual conforme a operação amadurece.
Como criar um SLA de TI: passo a passo
A seguir, o processo para estruturar um SLA de TI que seja operacional desde o primeiro dia.
Passo 1: mapeie os serviços prestados pela TI
O SLA só pode cobrir o que está documentado. Antes de definir qualquer prazo, liste todos os serviços que a TI entrega: suporte a hardware, acesso a sistemas, gestão de senhas, manutenção de infraestrutura, provisionamento de equipamentos, entre outros. Esse mapeamento é a base do catálogo de serviços, que alimenta o SLA.
Passo 2: classifique os chamados por prioridade
Nem todo chamado tem o mesmo impacto no negócio. É importante definir níveis de prioridade para classificar as demandas de acordo com sua urgência e impacto no negócio. Uma classificação funcional considera dois eixos:
- Urgência: o quanto o serviço afetado é necessário naquele momento;
- Impacto: quantas pessoas ou processos são prejudicados pela falha.
A combinação desses dois critérios gera os níveis de prioridade, normalmente de P1 (crítico) a P4 (baixo). O SLA pode estipular, por exemplo:
- Incidentes P1 críticos resolvidos em até 4 horas;
- P2 em até 24 horas;
- P3 em até 3 dias.
Ajuste esses números à capacidade real da sua equipe antes de publicar.
Passo 3: defina as métricas centrais
Com os serviços mapeados e as prioridades definidas, chegou a hora de estabelecer os indicadores que o SLA vai monitorar. As métricas mais utilizadas são:
- Tempo de resposta: prazo para o primeiro contato do analista com o usuário após a abertura do chamado;
- Tempo de resolução: prazo total para encerramento do incidente ou solicitação;
- Disponibilidade (uptime): percentual mínimo de tempo que um sistema ou serviço deve ficar disponível e funcional, como uptime de 99,5% mensal;
- Taxa de resolução no primeiro contato (FCR): percentual de chamados encerrados sem escalonamento;
- Taxa de cumprimento do SLA: percentual de tickets atendidos dentro dos prazos acordados.
Passo 4: estabeleça os canais de atendimento e horários de cobertura
O SLA precisa deixar claro em quais canais os chamados serão recebidos, qual o horário de cobertura e o que acontece fora desse horário para incidentes críticos. Definir isso evita o problema clássico de chamados abertos às 23h com expectativa de atendimento imediato, além de proteger a equipe de cobranças fora do escopo contratado.
Passo 5: documente o processo de escalonamento
Estabeleça caminhos claros de escalonamento para incidentes que excedam os limites do SLA. Especifique quem deve ser contatado em cada nível de escalonamento e a resposta esperada em cada estágio. Sem esse fluxo, os chamados críticos ficam parados aguardando a iniciativa de analistas sem autoridade para decidir.
Passo 6: defina consequências pelo descumprimento
Um SLA sem consequências pelo descumprimento é apenas um documento decorativo. Isso não significa punição automática, mas sim um mecanismo que gere responsabilização real. Seja por reuniões de revisão, créditos de serviço em contratos externos ou relatórios formais para a gestão.
Passo 7: valide o SLA com as áreas atendidas
A elaboração de um SLA consistente e confiável exige o esforço conjunto dos departamentos, das partes interessadas e dos usuários. Apresente o documento às principais áreas antes de publicar. Além de garantir aderência, esse processo cria alinhamento sobre o que a TI pode e não pode entregar, reduzindo expectativas irrealistas de ambos os lados.
Métricas de SLA de TI: o que monitorar e como interpretar
Ter as métricas no papel é diferente de monitorá-las com regularidade. Os acordos de nível de serviço são monitorados por meio de plataformas de gestão que registram e medem incidentes, solicitações e métricas de desempenho. Cada compromisso de serviço, como tempo de resposta, tempo de resolução ou tempo de atividade, tem um cronômetro associado que é iniciado e interrompido com base em condições predefinidas.
Abaixo estão as métricas mais relevantes e o que elas revelam sobre a operação:
- MTTR (mean time to resolution): tempo médio de resolução de incidentes. É o indicador mais monitorado porque impacta diretamente a disponibilidade dos serviços e a produtividade dos usuários;
- FCR (first contact resolution): chamados resolvidos no primeiro atendimento. Uma taxa alta indica boa base de conhecimento e analistas bem treinados;
- SLA compliance: percentual de tickets atendidos dentro do prazo. Abaixo de 90% é sinal de que os prazos estão subdimensionados ou a equipe está sobrecarregada;
- Taxa de reabertura: incidentes fechados que voltam a abrir porque não foram totalmente resolvidos. Uma taxa alta pode indicar soluções paliativas mal comunicadas ou pressão para fechar tickets sem resolver completamente.
Além das métricas técnicas, vale incluir a satisfação do usuário, coletada por pesquisas curtas após o encerramento do chamado. Os acordos de nível de experiência (XLAs) preenchem a lacuna dos SLAs, concentrando-se em como os usuários percebem a qualidade do serviço. Um SLA pode garantir 99,9% de disponibilidade, mas isso não significa que as pessoas estejam satisfeitas com os tempos de resposta ou com a resolução de incidentes.
Erros comuns ao criar um SLA de TI
Mesmo equipes experientes cometem os mesmos equívocos na elaboração do primeiro SLA. Os mais frequentes são:
- Definir prazos sem base histórica de atendimento, prometendo o que a equipe não tem capacidade de entregar;
- Criar um único SLA genérico para todos os serviços, sem distinção por tipo de chamado ou impacto;
- Ignorar os horários de cobertura real da equipe, gerando expectativas de atendimento 24/7 sem suporte para isso;
- Não envolver as áreas usuárias na construção do documento;
- Tratar o SLA como documento estático. A atualização periódica potencializa a utilidade do SLA, podendo adicionar detalhes que estavam faltando e tornar claros obstáculos antes não detalhados, o que inclusive pode impactar as expectativas dos usuários em relação ao suporte recebido.
Como a Nortrez pode ajudar
Criar um SLA de TI bem estruturado é uma etapa. Fazer com que ele funcione no dia a dia da operação depende de dois pilares: processo e ferramenta.
No lado da ferramenta, o Freshservice, da Freshworks, é uma plataforma ITSM alinhada ao ITIL que automatiza o monitoramento de SLA de ponta a ponta. A plataforma inclui módulos para gestão de incidentes, gestão de problemas, gestão de mudanças e gestão de ativos, monitoramento de SLA, base de conhecimento, catálogo de serviços e automação de fluxos de trabalho, permitindo que as organizações mantenham a conformidade e impulsionem a melhoria contínua do serviço. Na prática, isso significa que os prazos definidos no SLA viram regras dentro da plataforma: o sistema alerta quando um ticket está próximo da violação, escala automaticamente para o responsável e gera relatórios de cumprimento sem intervenção manual.
Em novembro de 2025, a Freshworks lançou o Intelligent Routing no Freshservice: atribuição automática de chamados baseada em habilidade do analista, disponibilidade e balanceamento de carga, com o objetivo de prevenir violações de SLA antes que ocorram.
No lado do processo, a Nortrez atua na implantação consultiva do Freshservice, o que inclui a definição de categorias de chamados, configuração dos níveis de prioridade, criação do catálogo de serviços e alinhamento dos prazos de SLA com a realidade da equipe. Não é só instalar uma ferramenta: é garantir que o que foi acordado no papel funcione dentro do sistema desde o primeiro dia de operação.
Perguntas frequentes sobre SLA de TI
O que é SLA de TI?
SLA de TI é um acordo formal que define os prazos, métricas de qualidade e responsabilidades entre a equipe de tecnologia e as áreas que ela atende. Ele estabelece o que será entregue, em quanto tempo e com qual nível de qualidade, funcionando como base para a governança do suporte interno.
Qual é o tempo de resposta ideal para um SLA de TI?
Não existe um prazo universal. O tempo de resposta deve ser definido com base na criticidade do chamado: incidentes críticos (P1) costumam ter SLA de 1 a 2 horas para primeiro contato, enquanto solicitações de baixo impacto podem ter prazo de 1 a 2 dias úteis. O mais importante é que o prazo seja compatível com a capacidade real da equipe.
Qual a diferença entre SLA, OLA e UC?
Para cumprir um SLA com o cliente, a equipe de TI frequentemente precisa de dois outros tipos de acordo. O primeiro é o OLA (Operational Level Agreement), um acordo interno entre departamentos da própria TI que define responsabilidades entre times, como redes, servidores e suporte. O segundo é o UC (Underpinning Contract), um contrato com fornecedores externos cujo cumprimento é necessário para manter o serviço prometido. Por exemplo: o SLA compromete 99,5% de disponibilidade do serviço de e-mail ao cliente, o OLA entre a equipe de redes e a equipe de servidores garante resposta interna em 15 minutos, e o UC com o provedor de internet assegura a infraestrutura que sustenta tudo isso.
Com que frequência o SLA de TI deve ser revisado?
O SLA deve ser revisado no mínimo a cada seis meses ou sempre que houver mudança significativa no volume de chamados, na composição da equipe ou nos serviços prestados. Revisões anuais são o mínimo aceitável; trimestral é o recomendado para operações em crescimento.
É possível ter SLA sem uma ferramenta de service desk?
Tecnicamente sim, mas a execução fica comprometida. Sem um sistema que registre e cronometre cada chamado, o monitoramento depende de planilhas manuais, o que gera inconsistências e consome tempo que poderia ser usado no próprio atendimento.
