Suporte de TI: como avaliar fornecedor e SLA real

A maioria das empresas brasileiras de pequeno e médio porte só percebe o tamanho do problema com suporte ti depois de um incidente caro: o servidor de arquivos cai numa segunda-feira, o certificado digital trava no fechamento contábil, ou o ransomware encontra a brecha que ninguém estava observando. O fornecedor responde — eventualmente. O contrato diz que o atendimento é “rápido”. E você descobre, no pior momento possível, que “rápido” nunca foi definido em nenhum documento.

Este texto entrega um padrão de avaliação de fornecedor de suporte de TI corporativo que funciona pra empresas de 10 a 250 funcionários: o que está dentro e fora do escopo, quais modelos de contrato existem no mercado, como ler um SLA sem cair em armadilha de ambiguidade, os 5 sinais clássicos de que seu suporte atual está mal dimensionado e por onde começar um diagnóstico antes de trocar de parceiro.

A intenção não é vender uma escolha de modelo, mas dar critério técnico pra você comparar três propostas lado a lado e identificar o que importa.

O que é (e o que não é) suporte de TI corporativo

Suporte de TI corporativo, no sentido contratual estrito, é a operação contínua de manter a infraestrutura tecnológica da empresa funcionando dentro de um nível de serviço previamente acordado. Isso envolve quatro frentes que costumam aparecer no mesmo contrato, mas que são tecnicamente distintas: monitoramento de ativos (servidores, links, estações), atendimento on-site para incidentes que exigem presença física, atendimento remoto para incidentes resolvíveis por sessão de acesso seguro e gestão estruturada de incidentes — abertura, classificação por criticidade, resolução, registro e revisão pós-incidente.

O que normalmente está fora do escopo de suporte e é confundido com ele: instalação de novo servidor, migração de e-mail, deploy de ERP, projeto de cabeamento, consultoria de adequação à LGPD. Esses são projetos — têm escopo, prazo e budget próprios. Confundir suporte com projeto é a primeira fonte de atrito contratual entre cliente e fornecedor de TI: a empresa acha que “está pagando suporte, então tem que fazer”, o fornecedor sabe que aquilo é projeto, e o conflito vira churn.

Boas operações de suporte distinguem com clareza o que é incidente (algo parou de funcionar como funcionava), problema (causa-raiz por trás de incidentes recorrentes), requisição (pedido novo, tipo “instala esse software”) e mudança (alteração planejada na infraestrutura). Cada categoria tem fluxo, SLA e responsável diferentes. Se o seu fornecedor atende tudo na mesma fila, sem distinção, é provável que esteja apagando incêndio em vez de operar.

Modelos de contrato de suporte ti: por hora, por chamado e SLA recorrente

O mercado brasileiro consolidou três modelos comerciais principais de suporte ti corporativo. Cada um tem viés, vantagem e armadilha distintos.

Por hora (banco de horas): você compra um pacote de horas técnicas e consome conforme demanda. Vantagem: previsibilidade orçamentária no curto prazo, simplicidade contratual. Armadilha: incentiva o fornecedor a alongar atendimentos (cada hora é receita), e desincentiva o tratamento de causa-raiz. Banco de horas funciona bem para empresas com demanda muito esporádica — alguns chamados por mês, sem dependência crítica de TI.

Por chamado (ticket avulso): você paga por incidente aberto, com valor fixo ou variável conforme criticidade. Vantagem: zero custo fixo, paga apenas o que usa. Armadilha: o fornecedor não tem skin in the game na disponibilidade contínua — só ganha quando algo quebra. É o pior modelo possível para empresas com operação dependente de TI.

SLA recorrente (mensalidade fechada com nível de serviço): valor fixo mensal cobrindo monitoramento ativo, número ilimitado de chamados dentro do escopo e SLA contratado por criticidade. Vantagem: alinha incentivo do fornecedor com o seu — quanto mais estável a operação, melhor a margem dele. Armadilha: pode virar “suporte preguiçoso” se o SLA for fraco ou se o cliente não auditar relatórios mensais. Este é o modelo dominante para PMEs com TI crítica para o negócio.

A escolha entre os três depende da criticidade da TI para a operação, do volume mensal de chamados históricos e da maturidade interna pra fiscalizar contrato. Empresa contábil em pico fiscal, escritório de advocacia com prazo processual, e-commerce com vendas 24/7: SLA recorrente ou nada. Pequena empresa com 5 funcionários e e-mail no provedor: banco de horas resolve.

Como ler um SLA: tempo de resposta vs tempo de resolução

A maior armadilha contratual em suporte de TI é confundir tempo de resposta com tempo de resolução. Os dois aparecem juntos, parecem sinônimos para quem não opera, e são fundamentalmente diferentes.

Tempo de resposta é o intervalo entre você abrir o chamado e o fornecedor confirmar que recebeu, classificou e atribuiu a um técnico. É um indicador de operação interna do fornecedor — diz que ele tem fila, mesa de serviço e capacidade de triagem. Bom SLA de resposta para incidente crítico: até 30 minutos em horário comercial.

Tempo de resolução é o intervalo entre abertura do chamado e o restabelecimento do serviço afetado. É o que importa para o seu negócio. Aqui é onde o SLA precisa ter critério de criticidade bem definido, geralmente em quatro níveis: crítico (sistema fora, paralisação total), alto (degradação grave de serviço), médio (problema que afeta usuários específicos) e baixo (cosmético ou agendável).

Um SLA decente para PME corporativa, em incidente crítico, fica entre 4 e 8 horas de resolução em horário comercial estendido (8h–20h em dias úteis), com cobertura 24×7 opcional para empresas que rodam fora desse horário. Multas contratuais por descumprimento aparecem em SLAs maduros: 5% a 15% do valor mensal por incidente crítico não resolvido no prazo, com teto. Sem multa, o SLA é sugestão.

Três pontos que costumam estar no contrato e que você deve ler com lupa antes de assinar: (1) “horário de SLA” — define se o relógio para fora do horário comercial; (2) cláusula de causa externa — fornecedores tentam excluir responsabilidade quando o incidente vem de operadora de internet, energia, etc., o que é razoável, mas precisa estar limitado a falhas comprovadas; (3) escalonamento — o que acontece se o SLA estourar; o ideal é abertura automática de incidente para o gestor de contas e relatório obrigatório de causa-raiz em 5 dias úteis.

5 sinais de que seu suporte de TI está mal dimensionado

Antes de trocar de fornecedor, vale checar se o problema é dimensionamento, não fornecedor. Cinco sinais clássicos:

1. Chamados recorrentes sem causa-raiz: o mesmo problema retorna a cada 15–30 dias, é “resolvido” rapidamente, e volta. Indica que o suporte está tratando sintoma, não causa. Bom fornecedor classifica incidentes recorrentes como problema (no sentido ITIL) e abre investigação separada de causa-raiz.
2. Downtime sem documentação: o serviço cai, volta, e o fornecedor não consegue explicar exatamente o que aconteceu. Se não há relatório pós-incidente em 5 dias úteis para qualquer indisponibilidade superior a 30 minutos, a operação não é gerenciada — é improvisada.
3. Falta de relatórios mensais: SLA bem operado produz relatório mensal com chamados abertos, fechados, no prazo, fora do prazo, principais incidentes, problemas em aberto e sugestões de mudança. Se o seu fornecedor “envia quando você pede”, a fiscalização é zero.
4. Atendimento sempre no limite do SLA: chamados resolvidos sempre com 95–99% do tempo gasto. Não é coincidência — é dimensionamento de equipe insuficiente, com priorização por proximidade do prazo. Em escala, isso quebra.
5. Dependência de uma pessoa: existe um técnico específico que “conhece a sua operação” e, quando ele sai de férias, tudo vira problema. Isso é falha estrutural do fornecedor — não há base de conhecimento, padronização de configuração nem rotação de equipe. Você está contratando uma pessoa, não uma operação.

Se três ou mais desses sinais estão presentes na sua operação atual, há base técnica para reabrir conversa com o fornecedor ou abrir RFP para alternativas.

Próximo passo: diagnosticar a operação antes de trocar de fornecedor

Trocar de fornecedor de suporte de TI sem diagnóstico prévio é receita de repetir o erro com nome diferente. Antes de pedir proposta para concorrentes, levante os números da sua operação atual: quantos chamados foram abertos nos últimos 12 meses, qual o tempo médio de resolução real (não o contratado), quantos incidentes críticos houve, qual o downtime acumulado, quais foram os 3 problemas mais recorrentes. Esses dados redimensionam expectativa de SLA e contrato.

Com isso em mãos, qualquer proposta de fornecedor passa a ser comparável: o novo SLA cobre os incidentes recorrentes que você já mapeou, o modelo comercial faz sentido pro seu volume, e o preço fica justificável tecnicamente. Sem esse diagnóstico, comparação vira leilão de menor preço — que é exatamente o que produz o suporte mal dimensionado que você quer trocar.

Um diagnóstico bem feito mapeia também os ativos invisíveis: licenças de software com vencimento próximo, contratos de telefonia que duplicam canal, equipamentos fora de garantia que rodam serviço crítico. Esses pontos costumam aparecer só quando alguém senta com a fatura na mão e cruza com o inventário real — exercício que o seu fornecedor atual deveria estar fazendo trimestralmente, mas dificilmente faz.

Por fim, vale alinhar expectativa interna antes de qualquer mudança: trocar de fornecedor de suporte ti gera curva de aprendizado de 30 a 90 dias, mesmo com transição bem planejada. Senhas, configurações, particularidades de aplicação legada e regras de firewall demoram pra migrar. Se a empresa estiver em momento crítico — fim de exercício fiscal, lançamento de produto, integração pós-aquisição — vale postergar a troca pra um período de menor pressão operacional. A pior decisão é trocar de fornecedor no meio de uma crise: você herda os incidentes pendentes, sem histórico estruturado, com equipe nova ainda mapeando o ambiente.

Próximo passo

A OpTec IT opera suporte ti corporativo com modelo de SLA recorrente, monitoramento ativo de ativos críticos e relatórios mensais auditáveis. Se você quer comparar a sua operação atual contra esse padrão, agende um diagnóstico técnico gratuito — em 60 minutos a gente mapeia chamados recorrentes, SLA real e gargalos de causa-raiz. Agendar diagnóstico técnico.