SLA de TI que existe só no papel não serve para nada. Estruturar um SLA de TI de verdade significa criar um documento que alinha expectativa, define responsabilidade e dá ao gestor uma base concreta para cobrar resultado — não um texto genérico de contrato que ninguém lê depois de assinar.
Para empresas que dependem de service desk e suporte recorrente, SLA bem definido evita discussão no calor do problema e deixa claro o que foi combinado antes que a crise aconteça.
O que é SLA de TI e o que ele precisa conter
Os principais pontos abordados neste artigo:
- O que é SLA de TI e o que ele precisa conter
- Como classificar criticidade de chamados
- Horário de cobertura e o que ele significa na prática
- Como o SLA se conecta com o service desk
- Consequências pelo descumprimento: por que isso precisa estar no contrato
SLA (Service Level Agreement) é o acordo de nível de serviço — define compromissos mensuráveis entre a empresa e o fornecedor de TI (ou entre o departamento de TI e as áreas internas que atende).
Um SLA funcional precisa conter, no mínimo:
- Classificação de chamados por criticidade — com definição clara do que caracteriza cada nível
- Tempo de resposta por nível — quanto tempo o fornecedor tem para iniciar o atendimento
- Tempo de resolução por nível — quanto tempo o fornecedor tem para encerrar o chamado
- Horário de cobertura — quando o SLA se aplica
- Exceções — situações que suspendem ou alteram o SLA (problema externo ao controle do fornecedor, por exemplo)
- Consequências pelo descumprimento — o que acontece quando o SLA não é cumprido
- Forma de medição e reporte — como o cumprimento é documentado e comunicado
Como classificar criticidade de chamados
A categorização mais prática usa dois eixos: impacto (quantas pessoas ou processos são afetados) e urgência (quanto tempo a empresa pode tolerar o problema sem consequência grave).
Uma estrutura funcional para a maioria das PMEs:
Crítico: sistema de produção fora do ar, servidor indisponível, falha de rede que afeta toda a empresa, incidente de segurança ativo. SLA de resposta: até 30 minutos. SLA de resolução ou workaround: até 4 horas.
Alto: usuário sem acesso a sistema essencial, e-mail corporativo fora, impressora de uso coletivo parada, falha que afeta um departamento inteiro. SLA de resposta: até 2 horas. SLA de resolução: até 8 horas úteis.
Normal: problema de um único usuário sem impacto em outros, configuração, dúvida, ajuste de software, manutenção programada. SLA de resposta: até 4 horas úteis. SLA de resolução: até 2 dias úteis.
Horário de cobertura e o que ele significa na prática
SLA de "resposta em 30 minutos" em horário comercial é completamente diferente de "resposta em 30 minutos" 24 horas por dia, 7 dias por semana. O horário de cobertura precisa estar explícito no contrato — e o cliente precisa entender o que acontece fora desse horário.
Para operações com funcionamento fora do horário comercial — varejo, indústria com turno noturno, hospitais, logística — SLA estendido ou plantão 24/7 pode ser necessário. Isso tem custo diferente e precisa ser negociado de forma explícita.
Como o SLA se conecta com o service desk
SLA sem ferramenta de gestão de chamados é teoria. Para o SLA funcionar na prática, cada chamado precisa ser registrado com timestamp de abertura e encerramento, e o sistema precisa calcular automaticamente se o prazo foi cumprido.
O service desk é a estrutura que viabiliza o SLA: fila organizada, prioridade automática por criticidade, alertas de prazo próximo e relatórios de cumprimento. Sem ele, o SLA existe no contrato mas ninguém sabe se está sendo cumprido.
Consequências pelo descumprimento: por que isso precisa estar no contrato
SLA sem penalidade é recomendação, não compromisso. O fornecedor que sabe que nada acontece quando o prazo é descumprido tem incentivo menor para cumprir.
As formas mais comuns de penalidade em contratos de suporte de TI são: desconto proporcional na fatura do mês, crédito de horas adicionais de atendimento ou processo formal de escalonamento quando o SLA é descumprido repetidamente.
Revisão periódica do SLA
SLA não é documento estático. O ambiente muda, a empresa cresce, novos sistemas são adotados, o volume de chamados aumenta. Revisar o SLA periodicamente — pelo menos uma vez por ano — garante que os prazos e a classificação ainda refletem a realidade da operação.
Essa revisão deve ser parte da governança do contrato, não uma renegociação de emergência depois de um problema grave.
Conclusão
Estruturar um SLA de TI bem feito é definir as regras antes de precisar usá-las. Com classificação clara de criticidade, prazos realistas, horário de cobertura explícito e consequências definidas, o SLA transforma expectativa em compromisso mensurável.
Quer um contrato de suporte com SLA real e relatórios de cumprimento?
A 8sa formaliza SLA por criticidade em todos os contratos de suporte de TI em São Paulo, incluindo redes e servidores, e entrega relatório mensal de desempenho. Solicite uma proposta.