Como este tema funciona na sua empresa
SLA básico e informal: P1 (sistema down) resolvemos "rápido", P2 (funcionando lento) no mesmo dia, P3 (dúvida) quando possível. Não há documentação formal. Desafio: usuário sempre acha que tudo é urgente. Abordagem: comunicar verbalmente o que é realista, documentar em email.
SLA estruturado por prioridade (P1: 2h resposta, 4h resolução; P2: 8h resposta, 24h resolução; P3: 24h resposta, 48h resolução). Comunicado no portal de suporte. Acompanhamento mensal de aderência. Sem penalidade formal, mas trazido à atenção de liderança se baixo.
SLA rigoroso, diferenciado por serviço e prioridade. Publicado em contrato com usuários internos. Acompanhamento semanal, reportado automaticamente. Penalidade por não atingir (crédito de serviço, investimento requerido em aumento de recursos). Revisão trimestral formalizada.
SLA de suporte (Service Level Agreement) é o contrato entre time de TI e usuários que define prazos de resposta e resolução por prioridade do chamado, garantindo expectativa clara e aderência mensurável. SLA bem definido reduz frustração do usuário e melhora satisfação.
Diferença entre tempo de resposta (MTTA) e tempo de resolução (MTTR)
MTTA (Mean Time To Assign): Tempo máximo para alguém do time de suporte responder ao chamado e confirmar que recebeu. Exemplo: "P1 resposta máxima 2 horas".
MTTR (Mean Time To Resolve): Tempo máximo para resolver completamente o problema. Exemplo: "P1 resolução máxima 4 horas".
Diferença prática: Usuário abre chamado às 9h00 (sistema caído). Time confirma recebimento às 9h30 (MTTA cumprido em 30 min). Sistema volta às 11h30 (MTTR cumprido em 2h30). Ambos dentro do SLA.
Estrutura realista de SLA por prioridade
Define-se prioridade conforme impacto e urgência:
- P1 (Crítico): Sistema completamente inoperante, múltiplos usuários afetados, negócio parado. MTTA: 30-60 min. MTTR: 2-4h.
- P2 (Alto): Funcionalidade essencial degradada, equipe afetada, workaround possível. MTTA: 2-4h. MTTR: 8-24h.
- P3 (Médio): Funcionalidade não-crítica com problema, equipe consegue trabalhar mas com dificuldade. MTTA: 8-24h. MTTR: 2-5 dias.
- P4 (Baixo): Dúvida, solicitação cosméticaou de otimização. MTTA: 24-48h. MTTR: 5-10 dias.
Critério para PME: SLA deve ser alcançável com recursos atuais. SLA que ninguém cumpre destrói credibilidade.
Comunicação clara ao usuário
SLA não adianta se usuário não sabe. Comunicação deve incluir:
- Portal de suporte: Publicar SLA na primeira página (ex: "P1 = 4h, P2 = 24h").
- Abertura de chamado: Email automático confirmando recebimento e informando SLA ("Seu chamado é P2, responderemos até [data/hora]").
- Treinamento: Mostrar a usuários como classificar corretamente (reduz falsos P1).
- Feedback mensal: Publicar % de cumprimento de SLA (transparência).
- Exceções documentadas: Deixar claro quando SLA não se aplica (manutenção planejada, culpa do usuário como senha esquecida).
Acompanhamento de aderência a SLA
Métrica: % de chamados que cumpriram SLA por prioridade. Exemplo: "P1: 95% dentro do SLA, P2: 88%, P3: 92%".
Frequência: Reportar mensalmente. Gráfico deve mostrar trend (melhorando ou piorando).
Ação quando baixo (<85%): Investigar causa (falta de recurso, classificação errada, problema técnico sistemático) e tomar ação (hiring, automação, change management).
Automação: Usar help desk system (Jira Service Management, Zendesk, etc.) que calcula automaticamente.
O que fazer quando SLA é quebrado
Comunicação: Informar usuário que será atrasado, quando esperar resposta, e por quê.
Escalação: Se delay será significativo (>1h além do SLA), envolver gerência.
Registro: Documentar por que foi quebrado (overflow, dependência externa, complexidade subestimada). Usar para melhorar futuro.
Ajuste (se padrão): Se SLA é quebrado regularmente, é sinal de que é irrealista — ajustar para números atingíveis.
Sinais de que sua empresa precisa estruturar SLA de suporte
Se você se reconhece em três ou mais cenários, é hora de formalizar.
- Usuários têm expectativas caóticas sobre tempo de resolução (variam desde "5 minutos" até "próximo mês")
- Suporte não sabe informar prazo realista ao abrir chamado
- Não há métrica de quanto % de chamados é resolvido "rápido"
- SLA não é comunicado formalmente — apenas conversa informal
- Não há diferença de prioridade — tudo é tratado igual
- Usuários reclamam que certos chamados demoram muito (sem contexto se é dentro do esperado)
- Não há revisão periódica — SLA (se existe) é desatualizado
Caminhos para estruturar SLA de suporte
Criar ou melhorar SLA pode ser feito internamente ou com consultoria.
Viável quando empresa tem suporte estruturado.
- Perfil necessário: Gerente de Suporte com experiência em help desk ou analista de processos.
- Tempo estimado: 2 a 4 semanas para definir SLA, comunicar, implementar no sistema, começar acompanhamento.
- Faz sentido quando: Suporte já existe e tem visão clara de capacidade.
- Risco principal: Definir SLA irrealista (muito apertado) que ninguém cumpre.
Recomendado para estruturação de help desk do zero ou quando empresa não tem baseline.
- Tipo de fornecedor: Consultoria ITIL ou prestador de serviços gerenciados que opera help desk.
- Vantagem: Benchmark de mercado, templates prontos, garantia de realismo.
- Faz sentido quando: Empresa está crescendo e quer sair do caótico.
- Resultado típico: Em 1 mês, SLA definido, comunicado e acompanhado.
Precisa de apoio para estruturar SLA de suporte?
Se definir SLA realista e comunicar com clareza é prioridade, o oHub conecta você gratuitamente a especialistas em help desk. Em menos de 3 minutos, descreva sua situação, receba propostas, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
O que é SLA (Service Level Agreement)?
SLA é contrato entre time de TI e usuários que define prazos máximos para resposta e resolução de chamados por prioridade. Exemplo: "P1 respondemos em até 2 horas, resolvemos em até 4 horas".
Exemplos de SLA para help desk
P1 (crítico): resposta 2h, resolução 4h. P2 (alto): resposta 8h, resolução 24h. P3 (médio): resposta 24h, resolução 48h. P4 (baixo): resposta 48h, resolução 5 dias. Tempos são comerciais (dias úteis), não contínuos.
Diferença entre SLA e SLO
SLA: contrato externo (com penalidade se violado). SLO: objetivo interno (meta que time estabelece para si). Exemplo: SLA promete 99.9% uptime; SLO da empresa é 99.95% (mais rigoroso).
Como calcular SLA compliance?
% de chamados que cumpriram SLA. Exemplo: 95 de 100 chamados P2 foram resolvidos dentro de 24h = 95% de compliance. Objetivo: manter >85% consistentemente.
Penalidade por quebra de SLA: como lidar?
Para suporte interno, penalidade é rara. Ação típica: comunicar atraso ao usuário, registrar causa, usar para melhorar. Para suporte terceirizado, contrato pode ter crédito de serviço se SLA é quebrado repetidamente.
SLA por prioridade do chamado
Sim. Problema crítico (sistema down) tem SLA curto (2h). Dúvida (baixo impacto) tem SLA longo (5 dias). Classificação correta pelo usuário é essencial — treinamento reduz falsos P1.
Fontes e referências
- AXELOS. ITIL 4 Foundation — Service Level Management (SLM). ITIL Certification Documentation.
- ISO. ISO/IEC 20000-1:2018 — Information Technology — Service Management System Requirements. International Organization for Standardization.
- Gartner. IT Service Management Platforms Reviews — Metrics and SLA Best Practices. Gartner Marketplace.