SLA de suporte de TI: o que é, exemplos e quais prazos sua empresa deve exigir

Quando um servidor para, o sistema de vendas fica indisponível ou dezenas de usuários não conseguem trabalhar, “atender o mais rápido possível” não basta. A empresa precisa saber quem será acionado, em quanto tempo o fornecedor responderá, qual prioridade o chamado receberá e como a recuperação será acompanhada.

É isso que um SLA de suporte de TI bem definido organiza. Ele transforma promessas vagas em compromissos mensuráveis e permite comparar fornecedores com critérios mais úteis do que preço ou quantidade de horas incluídas.

Mas existe um detalhe que costuma causar conflito: responder não significa resolver. Um contrato pode prometer retorno em 30 minutos e ainda deixar a empresa parada por horas se não houver meta de restabelecimento, escalonamento e comunicação.

Neste guia, você entenderá como funciona o SLA de atendimento, verá exemplos de prioridades e prazos e saberá o que exigir de uma empresa de suporte de TI.

O que é SLA de suporte de TI?

SLA é a sigla de Service Level Agreement, ou acordo de nível de serviço. No suporte de TI, o SLA define os níveis de atendimento que fornecedor e cliente concordam em cumprir.

O acordo pode fazer parte do próprio contrato de suporte de TI ou aparecer em um anexo operacional. Em ambos os casos, precisa usar critérios objetivos, como:

• serviços, usuários, equipamentos e unidades cobertos;
• canais e horários de atendimento;
• níveis de prioridade dos chamados;
• prazo para a primeira resposta;
• prazo ou objetivo para restabelecimento e resolução;
• frequência das atualizações durante um incidente;
• regras de escalonamento;
• responsabilidades do cliente e do fornecedor;
• indicadores, relatórios e consequências do descumprimento.

Segundo a Atlassian, SLAs ajudam a alinhar expectativas entre prestador e cliente e a medir o desempenho do serviço. Na prática, esse alinhamento evita que cada usuário classifique o próprio problema como urgente e que o fornecedor decida prazos caso a caso.

Um bom SLA também protege os dois lados. A empresa contratante sabe o que esperar; o fornecedor consegue dimensionar equipe, plantão, ferramentas e capacidade conforme a criticidade da operação.

Por que o SLA importa para sua empresa?

O custo de uma falha de TI não está apenas no reparo. Ele pode aparecer em vendas interrompidas, produção parada, atrasos no faturamento, usuários ociosos, perda de dados, clientes sem atendimento e risco à reputação.

Sem SLA, a gestão descobre a qualidade do suporte somente durante a crise. Com um acordo claro, consegue avaliar antes da contratação:

• se o horário de cobertura acompanha a operação;
• se sistemas críticos recebem prioridade real;
• se há equipe e escalonamento para incidentes graves;
• como o fornecedor comunicará o andamento;
• quais dados comprovarão o cumprimento dos prazos.

Por isso, empresas que dependem de tecnologia não devem aceitar expressões como “atendimento rápido”, “prioridade máxima” ou “retorno imediato” sem números, condições e responsabilidades definidos.

Qual é a diferença entre tempo de resposta e tempo de resolução?

Esta é uma das dúvidas mais importantes ao analisar um SLA.

Tempo de resposta é o período entre a abertura válida do chamado e o primeiro atendimento qualificado. Esse contato deve indicar que a solicitação foi recebida, classificada e assumida por alguém capaz de conduzir o caso. Uma mensagem automática de protocolo não deveria ser considerada resposta técnica, salvo se o contrato disser claramente o contrário.

Tempo de resolução é o período até a solução definitiva do problema. Entre esses dois momentos, pode existir ainda o tempo de restabelecimento: o prazo para recuperar a operação, mesmo que a correção permanente seja concluída depois.

Imagine que o sistema financeiro fique indisponível às 10h:

1. às 10h10, o técnico assume o chamado e inicia o diagnóstico: tempo de resposta de 10 minutos;
2. às 11h, o serviço volta por meio de uma contingência: tempo de restabelecimento de 1 hora;
3. às 15h, a causa é corrigida de forma definitiva: tempo de resolução de 5 horas.

As três métricas são úteis, mas medem coisas diferentes. Se o contrato mencionar apenas resposta, ele não define por quanto tempo a operação poderá permanecer afetada.

Também é importante registrar quando o relógio do SLA pode ser pausado. Exemplos legítimos incluem espera por autorização do cliente, acesso indisponível, janela de manutenção ou dependência de uma operadora. A pausa precisa ficar documentada no chamado, com motivo e horário. Sem essa regra, o indicador pode parecer bom enquanto problemas passam dias aguardando solução.

Como definir chamados críticos, altos, médios e baixos?

Prioridade não deve depender apenas de quem abriu o chamado ou do cargo da pessoa. O critério mais consistente combina impacto e urgência.

Impacto mede quantas pessoas, unidades ou processos foram afetados e qual prejuízo potencial existe. Urgência mede quanto tempo a empresa pode esperar antes que a consequência se torne grave.

Prioridade crítica

Incidente que interrompe a empresa, uma operação essencial ou um serviço com grande impacto, sem alternativa viável.

Exemplos:

• servidor ou ambiente de produção indisponível;
• toda a empresa sem internet;
• sistema de vendas, emissão ou atendimento completamente parado;
• suspeita de ransomware ou invasão em andamento;
• falha de infraestrutura que impede muitos usuários de trabalhar.

Prioridade alta

Problema grave que afeta um setor, sistema importante ou grupo relevante de usuários, mas não paralisa toda a organização ou possui uma contingência limitada.

Exemplos:

• filial sem acesso ao sistema central;
• departamento financeiro impossibilitado de operar;
• aplicação essencial com lentidão severa;
• falha de e-mail para um grupo de usuários;
• equipamento de rede redundante com defeito e risco de parada.

Prioridade média

Falha com impacto individual ou restrito, sem interromper um processo crítico. O usuário ainda consegue trabalhar, mesmo com perda de produtividade ou usando uma alternativa.

Exemplos:

• computador de um usuário com lentidão;
• erro em uma impressora quando existe outra disponível;
• dificuldade de acesso a uma pasta não urgente;
• problema em um software que não paralisa a atividade.

Prioridade baixa

Solicitação planejável, dúvida, instalação, melhoria ou demanda sem impacto imediato na operação.

Exemplos:

• instalação de programa não urgente;
• orientação sobre ferramenta;
• criação de relatório ou ajuste de configuração;
• movimentação de equipamento;
• melhoria que pode entrar em agenda.

Se o impacto mudar, a prioridade também deve mudar. Um problema inicialmente individual pode se tornar crítico ao atingir toda a equipe. O processo precisa permitir reclassificação com justificativa e registro no histórico.

Tabela de prazos por nível de prioridade

A tabela abaixo oferece uma referência inicial para atendimento em horário comercial. São exemplos, não uma promessa universal: os prazos reais dependem do contrato, do horário de cobertura, do porte da operação, dos sistemas envolvidos e da existência de plantão.

Prioridade	Exemplo	Resposta esperada	Objetivo de restabelecimento ou resolução
Crítica	Empresa ou servidor parado	15 a 30 minutos	Restabelecer em 2 a 4 horas
Alta	Setor ou sistema importante indisponível	Até 1 hora	Restabelecer ou resolver em 4 a 8 horas
Média	Usuário com problema sem parar a operação	Até 4 horas	Resolver em 1 a 2 dias úteis
Baixa	Instalação, orientação ou melhoria	Até 1 dia útil	Agendar conforme fila e escopo

Essas faixas precisam ser adaptadas ao risco. Uma indústria que opera 24 horas, um e-commerce ou uma clínica não devem usar o mesmo SLA de uma empresa que trabalha somente de segunda a sexta, em horário comercial.

Além do prazo, exija uma frequência de comunicação para incidentes críticos. Mesmo quando a solução depende de diagnóstico, o fornecedor pode atualizar situação, ações realizadas, responsáveis, riscos e próxima previsão a cada 30 ou 60 minutos.

Não confunda SLA curto com serviço automaticamente melhor. Responder em 15 minutos exige equipe disponível, cobertura, escalonamento e custo compatíveis. Um prazo agressivo sem capacidade operacional vira apenas cláusula comercial.

Quais prazos sua empresa deve exigir?

O prazo adequado nasce da necessidade do negócio, não de uma tabela genérica. Para defini-lo, responda:

• quais sistemas sustentam vendas, produção, atendimento e faturamento;
• quanto tempo cada processo pode ficar indisponível;
• quais horários precisam de cobertura;
• existe alternativa manual ou ambiente de contingência;
• quantos usuários seriam afetados;
• quais dependências pertencem a terceiros;
• qual perda financeira, operacional ou regulatória uma parada pode causar.

Comece pelos processos críticos e estabeleça o tempo máximo tolerável de interrupção. Depois, confirme se infraestrutura, backup, redundância e contrato tornam esse objetivo possível.

Se a empresa exige recuperação em duas horas, por exemplo, mas restaurações de backup levam oito horas, o SLA de suporte sozinho não resolverá a incompatibilidade. Continuidade depende de arquitetura, processos e testes, não apenas da velocidade do help desk.

Também diferencie três tipos de cobertura:

• horário comercial: o relógio corre apenas na janela prevista no contrato;
• horário estendido: inclui início da manhã, noite ou sábado;
• 24x7: atendimento contínuo, normalmente reservado a incidentes e serviços definidos.

“24x7” precisa significar técnico disponível e processo de escalonamento, não apenas possibilidade de enviar um chamado durante a madrugada.

O que precisa constar no contrato de suporte de TI?

Um SLA confiável não cabe em uma frase. Verifique se o contrato ou anexo descreve os seguintes pontos.

Escopo coberto

Liste usuários, unidades, dispositivos, sistemas, servidores, redes, cloud e serviços incluídos. Registre também exclusões e demandas cobradas separadamente, como projetos, cabeamento, desenvolvimento ou suporte a sistemas de terceiros.

Canais válidos

Defina onde o chamado deve ser aberto: portal, e-mail, telefone, aplicativo ou canal emergencial. Mensagens pessoais para um técnico não devem ser o único caminho, pois dificultam histórico, medição e continuidade.

Horário e calendário

Especifique dias, horários, feriados, plantão e forma de acionar suporte fora da janela normal. Informe se o SLA é contado em horas corridas ou úteis.

Matriz de prioridade

Descreva impacto, urgência e exemplos de cada nível. Defina quem pode classificar ou reclassificar chamados e como divergências serão resolvidas.

Metas separadas

Registre tempo de resposta, frequência de atualização, objetivo de restabelecimento e, quando viável, prazo de resolução. Não aceite uma única métrica para todos esses eventos.

Escalonamento

O contrato deve indicar quando o chamado passa para especialista, coordenação, fabricante, operadora ou gestão. Incidentes críticos precisam de responsáveis e comunicação claros.

Pausas e dependências

Explique em quais situações o relógio pode parar e como a pausa será comprovada. Defina tratamento de peças, fornecedores, garantias, sistemas de terceiros e autorizações pendentes.

Segurança e acesso

Inclua regras para credenciais, contas administrativas, autenticação multifator, registro de atividades, sigilo, proteção de dados e devolução de acessos no encerramento.

Indicadores e consequências

Determine relatório, periodicidade, meta de cumprimento e tratamento de desvios recorrentes. Créditos, planos de ação ou outras consequências podem existir, mas não substituem a correção da causa e a melhoria do serviço.

Antes de assinar, compare também os demais pontos apresentados em nosso guia sobre contrato de manutenção e suporte de TI.

Como acompanhar se o fornecedor cumpre o SLA?

Chamados precisam ficar em uma ferramenta que registre abertura, prioridade, primeira resposta, mudanças de status, pausas, responsáveis e encerramento. Planilhas ou conversas dispersas não oferecem rastreabilidade suficiente para uma operação recorrente.

No relatório mensal, acompanhe pelo menos:

• percentual de chamados respondidos dentro do SLA;
• percentual restabelecido ou resolvido dentro da meta;
• tempo mediano de primeira resposta;
• tempo mediano de resolução por prioridade;
• quantidade de chamados reabertos;
• chamados antigos ainda pendentes;
• incidentes recorrentes e respectivas causas;
• disponibilidade dos serviços monitorados;
• satisfação dos usuários, quando medida.

Média isolada pode esconder extremos. Dez chamados resolvidos em poucos minutos podem compensar estatisticamente um incidente crítico que ficou aberto por dias. Por isso, analise cada prioridade, violações individuais e tendência ao longo dos meses.

Também diferencie volume de qualidade. Fechar muitos chamados não significa eliminar causas. Um bom parceiro identifica recorrências, propõe ações preventivas e mostra quais problemas exigem projeto, renovação de equipamento ou mudança de processo.

Para estruturar canais, filas e histórico, veja nosso conteúdo sobre como funciona um help desk de TI.

Sinais de que o SLA atual é insuficiente

Alguns sintomas indicam que o acordo existe no papel, mas não protege a operação:

• contrato usa termos vagos e não apresenta prazos por prioridade;
• resposta automática conta como atendimento;
• não há meta de restabelecimento ou resolução;
• todo chamado é classificado como médio para evitar violação;
• usuários não recebem atualizações durante incidentes;
• suporte depende de uma única pessoa;
• chamados são encerrados sem confirmação ou voltam a acontecer;
• pausas não possuem motivo e duração registrados;
• relatórios mostram apenas quantidade total de tickets;
• violações se repetem sem análise de causa e plano de ação;
• cobertura termina antes do fim da operação da empresa;
• visitas presenciais, plantão e escalonamento não estão claros.

Se a equipe contorna o fornecedor por mensagens pessoais, precisa cobrar retorno repetidamente ou não sabe quem está cuidando do incidente, falta processo além de velocidade.

Checklist para comparar empresas de suporte

Use estas perguntas ao avaliar propostas de suporte de TI para empresas:

• O SLA está escrito no contrato?
• Resposta, restabelecimento e resolução são medidos separadamente?
• As prioridades usam critérios de impacto e urgência?
• O horário de cobertura atende a operação?
• Existe canal específico para incidentes críticos?
• Há escalonamento técnico e gerencial?
• Quem atende quando o profissional principal está ausente?
• A empresa registra todos os chamados em ferramenta própria?
• O cliente consegue acompanhar status e histórico?
• Pausas do SLA exigem justificativa?
• Visitas presenciais estão incluídas ou possuem regra definida?
• Sistemas de terceiros, operadoras e fabricantes têm tratamento previsto?
• O fornecedor monitora infraestrutura, backup e segurança ou apenas reage?
• Relatórios mostram violações, recorrências e plano de melhoria?
• Credenciais e documentação permanecem acessíveis ao cliente?
• O encerramento do contrato prevê devolução de dados, senhas e inventário?

Ao procurar uma empresa de suporte TI em Curitiba, avalie também capacidade de atendimento presencial, área de cobertura e tempo para deslocamento quando o remoto não resolve. Conheça os critérios de nossa página sobre suporte de TI em Curitiba e compare-os com o escopo recebido.

Como funciona o SLA da Mira Sistemas?

Na Mira Sistemas, o SLA é definido conforme a realidade de cada cliente. O ponto de partida é entender usuários, unidades, horários, sistemas críticos, infraestrutura, riscos e impacto de uma parada.

A partir desse diagnóstico, o contrato estabelece escopo, canais, prioridades e prazos compatíveis com a operação. Os chamados ficam organizados e acompanhados até a solução, com histórico e escalonamento. O atendimento pode combinar suporte remoto e presença local em Curitiba e região metropolitana, conforme a necessidade e o plano contratado.

Esse modelo evita prometer o mesmo prazo para empresas com perfis completamente diferentes. Uma operação pequena em horário comercial, uma empresa com várias unidades e um ambiente que não pode parar exigem coberturas, ferramentas e equipes distintas.

Além do atendimento aos usuários, a Mira pode integrar suporte, monitoramento, infraestrutura, backup, segurança e gestão contínua. Assim, o SLA não funciona isoladamente: ele faz parte de uma estratégia para reduzir falhas, organizar responsabilidades e melhorar a previsibilidade da TI.

Conheça a terceirização de TI da Mira Sistemas para entender como esse acompanhamento pode ser estruturado.

Transforme prazo em compromisso mensurável

O melhor SLA não é necessariamente o que promete o menor número. É o que combina necessidade do negócio, capacidade técnica, cobertura adequada e medição transparente.

Antes de contratar, separe resposta de resolução, defina prioridades por impacto, confirme horários, estabeleça escalonamento e exija relatórios. Esses cuidados reduzem conflitos e mostram se o fornecedor consegue sustentar a operação quando a empresa mais precisa.

Seu fornecedor demora para responder ou o contrato não define prazos claros? A Mira Sistemas oferece suporte de TI para empresas com chamados organizados, prioridades definidas e SLA compatível com a operação. Solicite uma avaliação.