Suporte de TI: como medir e exigir tempo de resposta — Duk

Por que o tempo de resposta do suporte de TI define a operação

Em ambientes corporativos dependentes de tecnologia, cada minuto de indisponibilidade tem custo direto. Estudos do Gartner estimam que o downtime médio custa entre R$ 30 mil e R$ 50 mil por hora para empresas de médio porte no Brasil — e isso sem contar o impacto reputacional, a perda de produtividade das equipes paradas e o retrabalho posterior. Quando um sistema crítico cai, não é só o problema técnico que pesa: é o tempo que o fornecedor de TI leva para reconhecer, diagnosticar e resolver a ocorrência.

O tempo de resposta — ou response time — é a métrica mais básica de qualquade em suporte, mas também a mais mal compreendida. Muitos contratos vendem "suporte 24/7" como diferencial, quando na prática o 24/7 significa apenas que alguém vai atender o chamado — não que alguém vai resolvê-lo. A diferença entre atendimento e resolução é onde mora a dor de 8 em cada 10 clientes corporativos que procuram uma nova parceria de TI.

Este guia mostra como medir, exigir e contratar o tempo de resposta correto para o seu cenário, quais métricas realmente importam no SLA, e como evitar cláusulas vazias que prometem muito e entregam pouco.

As 4 métricas essenciais de SLA de suporte de TI

Um SLA (Service Level Agreement) bem construído não se limita a prometer "resposta rápida". Ele define, em números, o que é aceitável e o que é falha contratual. As quatro métricas que realmente importam são:

• TTA (Time To Acknowledge) — tempo entre a abertura do chamado e o primeiro reconhecimento humano. Benchmark saudável: até 5 minutos para chamados críticos, até 15 minutos para prioridade média.
• TTR (Time To Respond) — tempo até que um técnico qualificado inicie o diagnóstico. Não confundir com TTA: aqui já começa trabalho real. Benchmark: até 15 minutos para críticos.
• MTTR (Mean Time To Resolve) — tempo médio total entre abertura e resolução. É a métrica que mais impacta o negócio. Benchmark para chamados críticos: até 4 horas. Para não-críticos: até 24 horas úteis.
• FCR (First Contact Resolution) — percentual de chamados resolvidos no primeiro contato, sem escalonamento. Benchmark saudável: acima de 70%.

Exigir essas quatro métricas no contrato é diferente de exigir "atendimento 24 horas". Um provedor pode ter atendimento 24h com TTR de 4 horas — o que, para uma operação com ERP crítico, significa 4 horas de prejuízo por chamado. Já um provedor com TTR de 5 minutos e MTTR de 40 minutos entrega um nível de serviço completamente diferente, mesmo que ambos vendam o mesmo "suporte 24/7".

A classificação de severidade também precisa estar explícita. Um bom SLA define pelo menos três níveis: P1 (crítico — sistema fora), P2 (degradado — impacto parcial) e P3 (não-crítico — dúvida ou ajuste). Cada nível tem seu próprio TTA, TTR e MTTR.

Como medir na prática: indicadores, ferramentas e evidências

De nada adianta exigir SLA se não houver como medir. O erro mais comum em contratos de suporte é aceitar relatórios produzidos pelo próprio fornecedor sem validação independente. É o equivalente a deixar o aluno corrigir a própria prova.

Para medir corretamente, o cliente precisa de acesso ao sistema de tickets do fornecedor (ou a um portal compartilhado) com visibilidade em tempo real de:

1. Timestamp exato da abertura de cada chamado (data, hora, minuto, segundo).
2. Timestamp do primeiro contato humano (não contar respostas automáticas).
3. Timestamp do início do diagnóstico técnico.
4. Timestamp de cada mudança de status (em análise, aguardando cliente, em resolução, resolvido).
5. Timestamp do fechamento e confirmação do usuário final.

Com esses pontos, é possível calcular mensalmente o cumprimento do SLA e identificar desvios. Ferramentas como Zoho Desk, Freshservice, ServiceNow e Jira Service Management produzem esses relatórios nativamente. Se o fornecedor não usa uma dessas plataformas — ou não dá acesso de leitura ao cliente — é sinal vermelho.

"Um SLA que o cliente não consegue auditar de forma independente não é um SLA. É uma promessa." — Princípio básico de ITSM segundo o framework ITIL 4.

Além das métricas quantitativas, avalie também a qualidade qualitativa do atendimento. Pesquisa NPS pós-chamado, registro de chamados reabertos dentro de 7 dias e histórico de escalonamento são indicadores que complementam o número bruto de SLA.

Cláusulas contratuais que você deve exigir (e as armadilhas para evitar)

A maior parte dos contratos de suporte de TI que chegam à mesa de negociação vem com linguagem favorável ao fornecedor. Três armadilhas clássicas merecem atenção redobrada:

• "Melhor esforço" — expressão que anula qualquer SLA. Se o contrato diz "o fornecedor envidará melhores esforços para responder em até X minutos", não há compromisso real. Troque por "o fornecedor se compromete a responder em até X minutos, sob pena de..."
• Janela de apuração elástica — alguns contratos medem SLA em média trimestral ou semestral, o que permite meses ruins compensados por meses bons. Exija apuração mensal, com multa por descumprimento mensal.
• Exclusões vagas — cláusulas como "o SLA não se aplica em casos de força maior" precisam ser detalhadas. Queda de internet do próprio cliente é exclusão legítima; falha no data center do fornecedor não é.

Cláusulas que você deve exigir no contrato:

• Multa por descumprimento de SLA (5% a 15% da mensalidade por ocorrência, dependendo da severidade).
• Direito a auditoria do sistema de tickets (leitura).
• Relatório mensal automatizado com todas as métricas acordadas.
• Cláusula de rescisão sem multa em caso de descumprimento recorrente (ex: 3 meses consecutivos abaixo do SLA).
• Definição clara dos canais de abertura (portal, e-mail, WhatsApp, telefone) e o TTA específico de cada canal.

Um ponto pouco discutido: o horário de cobertura técnica versus horário comercial. Muitos fornecedores oferecem "N1 em horário comercial e plantão 24/7". Isso significa que fora do expediente só haverá técnico de plantão para emergências P1 — chamados P2 e P3 ficam esperando o próximo dia útil. Para empresas com operação em múltiplos fusos ou e-commerce, isso pode ser inaceitável.

Benchmarks de mercado: o que é rápido, o que é lento, o que é inaceitável

Para contextualizar os números, veja a distribuição típica do mercado brasileiro de suporte de TI corporativo (dados consolidados de pesquisas ABES e HDI Brasil 2024-2025):

• Excelente: TTA abaixo de 5min, MTTR P1 abaixo de 2h, FCR acima de 80%. Menos de 10% dos provedores entregam esse nível consistentemente.
• Bom: TTA de 5 a 15min, MTTR P1 de 2 a 4h, FCR de 70% a 80%. Representa cerca de 25% do mercado.
• Mediano: TTA de 15 a 30min, MTTR P1 de 4 a 8h, FCR de 50% a 70%. Cerca de 45% do mercado.
• Abaixo do aceitável: TTA acima de 30min, MTTR P1 acima de 8h, FCR abaixo de 50%. Cerca de 20% do mercado — infelizmente ainda cobrando preços de mercado.

Se o seu fornecedor atual está na faixa "mediano" ou "abaixo do aceitável", há espaço real para exigir melhoria ou trocar. O custo de migração de provedor raramente supera o custo do downtime acumulado por um mau SLA.

"A diferença entre um chamado resolvido em 15 minutos e um chamado resolvido em 4 horas não é de grau — é de categoria. Na prática, o primeiro preserva a operação; o segundo apenas limita o dano." — Relatório HDI Brasil, 2024.

Outro benchmark importante: o índice de chamados reabertos. Um chamado fechado que volta em 7 dias é sinal de resolução superficial. Saudável: abaixo de 5%. Acima de 10% indica problema sistêmico no processo de diagnóstico do fornecedor.

Como a Duk estrutura SLA e tempo de resposta

A Duk Informática & Cloud opera há mais de 18 anos atendendo mais de 550 empresas, com SLA médio de primeira resposta de 3,7 minutos — bem abaixo do benchmark "excelente" do mercado. Isso é possível porque a estrutura foi desenhada em três camadas que trabalham em paralelo, não em fila:

• Camada 1 — Triagem inteligente: chamados entram por portal, e-mail ou WhatsApp e são classificados automaticamente por severidade. P1 dispara alerta imediato no grupo de plantão.
• Camada 2 — N1 especializado: equipe treinada em resolução rápida de 80% dos casos comuns (senha, acesso, Microsoft 365, impressão, VPN). FCR da Duk está em 78%.
• Camada 3 — Engenharia e especialistas: para casos complexos, escalonamento automático para arquitetos cloud, especialistas em segurança e engenheiros de infraestrutura — sem fila, sem "aguarde retorno".

Como Microsoft Gold Partner, a Duk tem canal direto de escalonamento com a Microsoft para incidentes de Azure, Microsoft 365 e Exchange, o que reduz drasticamente o MTTR em casos que dependem do fabricante. O cliente tem acesso ao portal de tickets em tempo real, recebe relatório mensal automatizado e tem cláusula contratual de multa por descumprimento de SLA.

Se você está avaliando trocar de fornecedor ou formalizar pela primeira vez um contrato de suporte com SLA sério, vale uma conversa para entender o cenário da sua operação e propor um contrato sob medida — com métricas que você consegue auditar e cobrar.

Fale com um especialista Duk agora: wa.me/5511957024493 — atendimento em minutos, não em dias.