A diferença entre responder e resolver: por que ela importa mais do que o tempo de atendimento
O equívoco mais comum na gestão de help desk é medir apenas o tempo de resposta e concluir que o suporte está funcionando. Tempo de resposta é o prazo entre a abertura do chamado e o primeiro contato do técnico com o usuário. Tempo de resolução é o prazo entre a abertura do chamado e a eliminação definitiva do problema. São métricas completamente diferentes e revelam coisas completamente diferentes sobre a qualidade do suporte.
| Dimensão |
SLA de resposta |
SLA de resolução |
| O que mede |
Quanto tempo para o técnico confirmar que recebeu o chamado |
Quanto tempo para o problema deixar de existir |
| Sinal de SLA verde |
O técnico respondeu no prazo |
O problema foi resolvido no prazo |
| O que pode estar escondido |
SLA verde com problema ainda aberto. O técnico respondeu mas não resolveu |
Nada: o SLA de resolução verde confirma que o problema deixou de existir dentro do prazo |
| Quem costuma medir |
Maioria dos contratos de help desk básico |
Contratos de gestão completa e service desk estruturado |
| Experiência do colaborador |
“Me responderam rápido mas continuo sem conseguir trabalhar” |
“Abri o chamado e o problema foi resolvido dentro do prazo” |
O sinal mais perigoso: SLA verde com taxa de reabertura alta
Quando os chamados são fechados rapidamente mas o mesmo problema volta uma ou duas semanas depois, o SLA de resposta está sendo cumprido mas a causa raiz não está sendo tratada. A taxa de reabertura alta ao lado de SLA de resposta verde é o sinal mais claro de um suporte que “fecha tickets” em vez de resolver problemas. O gestor que olha apenas para o tempo de resposta vai concluir que o suporte está ótimo enquanto a equipe se debate com os mesmos incêndios semana após semana.
Os 6 sinais de que o suporte de TI está funcionando no modo bombeiro
Modo bombeiro é quando o suporte existe para apagar incêndios, não para evitar que comecem. É o estado mais comum e mais caro de operar, porque cada problema custa mais tempo e energia do que custaria se fosse prevenido ou resolvido definitivamente na primeira vez que apareceu.
1
Os mesmos problemas aparecem repetidamente sem solução definitiva
A impressora do financeiro trava toda segunda-feira. O e-mail de um colaborador específico tem erros de sincronização todo mês. A VPN cai nos picos de uso. Cada ocorrência gera um chamado, o chamado é resolvido pontualmente e fecha. A causa raiz nunca é investigada porque o suporte está sempre correndo para o próximo incêndio.
2
Os chamados chegam por WhatsApp, e-mail e corredor sem registro central
Sem sistema de tickets, o suporte não tem histórico, não tem SLA mensurável, não tem visão de volume por categoria e não tem como provar para a gestão que está sobrecarregado ou que certos problemas são recorrentes. O WhatsApp do técnico é o help desk da empresa, e isso significa que tudo depende de uma única pessoa.
3
O gestor só fica sabendo de problemas quando eles já causaram impacto
Sem monitoramento proativo e sem relatório periódico, o gestor de TI ou o CFO descobre que o servidor ficou sobrecarregado quando o sistema começa a travar para os colaboradores. O suporte age depois do impacto, não antes.
4
A prioridade de atendimento é quem grita mais alto, não quem tem impacto maior
Sem critério formal de priorização, o suporte atende primeiro quem é mais persistente ou tem mais hierarquia. O servidor de arquivos de toda a empresa compete com o notebook do diretor que “está lento” pela atenção do mesmo técnico, sem nenhum critério objetivo de qual é mais urgente.
5
Não existe relatório mensal de performance do suporte
Sem dados, não há como saber se o suporte está melhorando ou piorando, qual categoria de problema gera mais volume, qual período do mês tem mais chamados ou se a equipe está subdimensionada para a demanda. A gestão de TI é feita por percepção, não por dado.
6
O único técnico é o gargalo de tudo: ausência, férias ou sobrecarga param o suporte
Quando toda a operação de suporte depende de uma única pessoa, qualquer ausência cria crise. Não há cobertura em férias, não há segundo nível para chamados complexos e não há distribuição de carga. O analista está sempre sobrecarregado e a qualidade do atendimento degrada ao longo do tempo sem que nenhum número revele isso.
Os 5 KPIs que todo gestor deveria cobrar do suporte de TI
O HDI Brasil recomenda entre 5 e 7 KPIs por processo como referência de foco adequado. Mais do que isso dilui a atenção. Menos do que isso deixa pontos cegos. Estes são os 5 indicadores essenciais para gestão de help desk corporativo, com o que cada um revela e o que fazer quando está fora do padrão.
1
FCR — First Call Resolution (Taxa de resolução no primeiro contato)
O KPI mais importante
O que mede
Percentual de chamados resolvidos no primeiro contato, sem necessidade de reabertura ou escalonamento. FCR alta indica boa base de conhecimento, técnicos bem treinados e processos eficientes.
Como calcular
(Chamados resolvidos no 1º contato / Total de chamados) × 100
Referência de mercado
Acima de 70%: bom desempenho
50% a 70%: atenção
Abaixo de 50%: base de conhecimento deficiente ou equipe mal treinada
FCR baixa raramente é problema de esforço: é falta de informação no momento do atendimento. Base de conhecimento integrada resolve.
2
MTTR — Mean Time to Resolution (Tempo médio de resolução)
O que mede
Tempo médio entre a abertura do chamado e a eliminação definitiva do problema. É o indicador mais monitorado porque impacta diretamente a produtividade dos colaboradores e a disponibilidade dos sistemas.
Como calcular
Soma do tempo de resolução de todos os chamados / Número de chamados
Referência de mercado (Brasil 2026)
Crítico: até 4 horas
Alto: até 8 horas
Médio: até 24 horas
Baixo: até 48 horas
MTTR que sobe sem explicação geralmente revela gargalo em uma etapa específica do processo. O SLO por etapa revela onde.
3
Taxa de cumprimento de SLA (SLA Compliance)
O que mede
Percentual de chamados atendidos e resolvidos dentro dos prazos acordados no SLA. É o número que vai para o relatório executivo e para o gestor não técnico. Abaixo de 90% é sinal de que os prazos estão subdimensionados ou a equipe está sobrecarregada.
Como calcular
(Chamados resolvidos no prazo / Total de chamados) × 100
Referência de mercado
Acima de 95%: excelente
90% a 95%: aceitável com monitoramento
Abaixo de 90%: investigar causas imediatamente
Atenção: SLA compliance alto com taxa de reabertura alta é o falso positivo mais perigoso. O chamado fecha no prazo mas o problema volta.
4
Taxa de reabertura de chamados
O que mede
Percentual de chamados fechados que foram reabertos pelo mesmo motivo em até 7 dias. Taxa alta revela soluções paliativas (o problema foi “tampado” sem tratar a causa raiz), pressão para fechar tickets rapidamente ou comunicação inadequada da solução ao usuário.
Como calcular
(Chamados reabertos / Total de chamados fechados) × 100
Referência de mercado
Abaixo de 5%: bom desempenho
5% a 10%: atenção à qualidade das resoluções
Acima de 10%: o suporte está fechando tickets, não resolvendo problemas
Correlacione com os tipos de chamado: se a reabertura está concentrada em um tipo específico, o problema é de processo ou de capacitação técnica naquela área.
5
CSAT — Customer Satisfaction Score (Satisfação do usuário)
O que mede
A percepção do colaborador sobre a qualidade do atendimento recebido, coletada por pesquisa curta (1 a 2 perguntas) após o encerramento do chamado. É o termômetro mais honesto: um SLA verde com CSAT baixo revela que os números estão bons mas a experiência não está.
Como coletar
Pesquisa automática enviada ao usuário imediatamente após o fechamento do chamado. Escala de 1 a 5 ou escala de satisfação (Insatisfeito / Neutro / Satisfeito).
Referência de mercado
Acima de 4,2 (escala 1-5): excelente
3,5 a 4,2: satisfatório
Abaixo de 3,5: investigar comunicação e qualidade de resolução
CSAT baixo com MTTR bom indica problema de comunicação ou expectativa: o técnico resolveu rápido mas não explicou o que fez ou o usuário não percebeu que estava resolvido.
Benchmarks de mercado: como comparar os números da sua empresa
Benchmarks são referências, não metas absolutas. O que é bom para uma empresa de 300 colaboradores com operação 24/7 pode ser diferente do que é adequado para uma PME de 50 pessoas com horário comercial. Use os números abaixo como ponto de partida para a conversa com sua equipe ou fornecedor, não como alvos rígidos.
| KPI |
Excelente |
Satisfatório |
Atenção |
O que investigar em “Atenção” |
| FCR |
Acima de 70% |
50% a 70% |
Abaixo de 50% |
Ausência de base de conhecimento, técnicos sem treinamento adequado, chamados abertos com informação insuficiente |
| MTTR (chamado crítico) |
Abaixo de 2h |
2h a 4h |
Acima de 4h |
Equipe sem cobertura 24/7 para críticos, dependência de fornecedor externo lento, processos de escalada mal definidos |
| SLA Compliance |
Acima de 95% |
90% a 95% |
Abaixo de 90% |
Equipe subdimensionada, SLAs irrealistas, volume de chamados crescendo sem reforço de equipe |
| Taxa de reabertura |
Abaixo de 3% |
3% a 8% |
Acima de 8% |
Pressão para fechar tickets rápido, soluções paliativas, falta de comunicação da solução ao usuário |
| CSAT (escala 1-5) |
Acima de 4,2 |
3,5 a 4,2 |
Abaixo de 3,5 |
Comunicação inadequada, expectativas mal alinhadas, técnico resolve mas não explica o que fez |
| Referências baseadas em HDI Brasil, MetricNet e SQM Group. Os valores são referências de mercado, não metas universais. A meta ideal depende do porte, da maturidade e do perfil de chamados de cada empresa. |
Níveis de suporte: N1, N2 e N3 e o que cada um resolve
O modelo de suporte em níveis é o padrão da indústria para organizar a triagem, o escalonamento e a especialização do atendimento. Cada nível resolve uma camada de complexidade diferente e tem perfil de profissional diferente. Entender os níveis ajuda o gestor a dimensionar a equipe e a diagnosticar onde os gargalos estão.
| Nível |
Exemplos de chamados |
Perfil do atendente |
Quando escalar |
% do volume típico |
| N1 |
Reset de senha, configuração de e-mail, instalação de impressora, dúvidas de uso de software (Word, Excel, Teams), problemas básicos de conectividade |
Técnico júnior ou atendente de service desk com base de conhecimento robusta. Em 2026: pode ser chatbot ou IA para chamados de autoatendimento |
Quando o problema não está na base de conhecimento ou exige acesso administrativo ao sistema |
60% a 70% dos chamados |
| N2 |
Problemas de rede interna, configuração de servidor, erros de sistema operacional, troubleshooting de VPN, integração entre aplicações, problemas de desempenho de máquina |
Analista pleno com conhecimento técnico mais profundo em infraestrutura, redes e sistemas operacionais |
Quando envolve arquitetura de sistema, banco de dados ou problema com fornecedor de software específico |
20% a 30% dos chamados |
| N3 |
Incidentes de segurança, falhas de servidor crítico, problemas de arquitetura de rede, integração de sistemas complexos, problemas com fornecedor de software que exigem escalada ao suporte do fabricante |
Especialista sênior ou fabricante do software. Em outsourcing: equipe multidisciplinar do parceiro |
N3 é o nível final. Sem resolução: envolve fabricante ou mudança de arquitetura |
5% a 10% dos chamados |
Como estruturar um help desk do zero ou reestruturar um que não funciona
Estruturar um help desk do zero ou reestruturar um que opera no modo bombeiro segue uma sequência lógica de seis etapas. Pular qualquer uma delas cria o mesmo problema em outro lugar.
As 6 etapas para estruturar um help desk eficiente
|
1
|
Mapeie a demanda atual: volume, categoria e gargalos
Antes de definir qualquer SLA ou contratar qualquer ferramenta, entenda o que está chegando. Extraia das últimas 4 semanas: volume de chamados, categorias mais frequentes, tempo médio de resolução atual e problemas que aparecem repetidamente. Esse diagnóstico é o único dado confiável para dimensionar equipe, definir SLAs realistas e identificar onde a base de conhecimento faz mais falta.
|
|
2
|
Defina o catálogo de serviços e os critérios de prioridade
Liste quais tipos de chamado o help desk atende, o que não atende (e para onde vai o que não atende) e como cada tipo é classificado por criticidade. A classificação por criticidade deve ser objetiva: “crítico” é o que para a operação de mais de 5 pessoas; “alto” é o que para uma pessoa por mais de 1 hora. Critérios subjetivos (“urgente” definido pelo usuário) criam caos de priorização.
|
|
3
|
Defina o SLA por criticidade com base na capacidade real da equipe
SLA definido sem base histórica de atendimento é promessa que a equipe não consegue cumprir. Use o diagnóstico da etapa 1 para calibrar os prazos: se o MTTR atual para chamados críticos é 6 horas, definir SLA de 1 hora sem mudança de processo ou equipe vai gerar SLA violation constante. A meta deve ser alcançável agora e melhorada gradualmente.
|
|
4
|
Implante o sistema de tickets e elimine canais informais
Todo chamado que chega por WhatsApp, e-mail direto ou corredor precisa ser convertido em ticket com registro, SLA e responsável. Isso é resistido culturalmente mas é a mudança de maior impacto: sem registro central, não há dado, não há SLA mensurável e não há base de conhecimento. A ferramenta não precisa ser cara: o que importa é que seja usada de forma consistente.
|
|
5
|
Construa a base de conhecimento com os problemas mais frequentes
Identifique no diagnóstico os 20 tipos de chamado que representam 80% do volume e documente a solução passo a passo para cada um. A base de conhecimento reduz o tempo de resolução de chamados de N1, aumenta o FCR e possibilita o autoatendimento para os problemas mais simples, liberando a equipe para os chamados complexos.
|
|
6
|
Implante o relatório mensal de KPIs e revise continuamente
O relatório mensal com FCR, MTTR, SLA compliance, taxa de reabertura e CSAT é o mecanismo que transforma o help desk de reativo em gerenciado. Revise mensalmente os números, identifique tendências e ajuste o processo. Um help desk que não mede não melhora, independentemente do esforço da equipe.
|
Ferramentas de help desk para PMEs: o que avaliar antes de escolher
A ferramenta de help desk é a infraestrutura que torna tudo o que foi descrito acima possível: registro de chamados, controle de SLA, base de conhecimento, relatórios e pesquisa de satisfação. Para PMEs, a escolha certa é a que a equipe vai usar, não a mais sofisticada.
| Critério |
O que verificar |
Sinal de atenção |
| SLA configurável |
A ferramenta permite configurar SLAs diferentes por tipo de chamado e criticidade, com alertas automáticos ao técnico quando o prazo está próximo |
SLA fixo e único para todos os tipos de chamado |
| Relatórios e KPIs |
Dashboard com FCR, MTTR, SLA compliance, taxa de reabertura e CSAT por período, por técnico e por categoria |
Apenas relatório de volume de chamados. Sem indicadores de qualidade |
| Base de conhecimento |
Possibilidade de criar artigos de solução acessíveis ao técnico durante o atendimento e ao usuário antes de abrir chamado (autoatendimento) |
Ferramenta sem base de conhecimento integrada ao fluxo de atendimento |
| Pesquisa de satisfação (CSAT) |
Envio automático de pesquisa ao usuário ao fechar o chamado, com resultado consolidado no relatório de gestão |
CSAT só disponível em plano avançado caro, fora do alcance de PME |
| Canais de abertura |
Aceita chamados por e-mail, portal web e, preferencialmente, integração com Teams ou Slack, para não criar fricção na adoção |
Apenas portal web próprio sem integração: baixa adoção, usuários voltam para o WhatsApp |
Próximo Passo
Você sabe qual é o FCR, o MTTR e a taxa de reabertura do suporte de TI da sua empresa hoje?
A Mobit oferece gestão de TI com relatório mensal de indicadores, SLA garantido e visibilidade completa de performance. Seu suporte de TI deixa de ser uma caixa preta e passa a ser uma área mensurável.
Quero suporte de TI com SLA e indicadores reais →
Diagnóstico gratuito. Sem compromisso.
Perguntas frequentes sobre help desk e suporte técnico para empresas
O que é help desk corporativo e como funciona? ▼
Help desk corporativo é o processo estruturado pelo qual a área de TI recebe, prioriza, registra, resolve e encerra chamados técnicos abertos pelos colaboradores, com prazos definidos em SLA. Funciona por meio de um sistema de tickets onde cada chamado recebe uma prioridade (crítico, alto, médio, baixo) conforme o impacto na operação, um responsável pelo atendimento e um prazo formal de resolução. O técnico resolve remotamente ou presencialmente conforme o tipo de problema, registra a solução e fecha o chamado, que é avaliado pelo usuário via pesquisa de satisfação. Um help desk bem estruturado gera relatório mensal com os indicadores de desempenho: FCR, MTTR, SLA compliance, taxa de reabertura e CSAT, permitindo ao gestor avaliar a qualidade do suporte com dados objetivos.
O que é FCR (First Call Resolution) no suporte de TI? ▼
FCR (First Call Resolution) é o percentual de chamados de suporte resolvidos no primeiro contato, sem necessidade de reabertura ou escalonamento para um nível superior. É considerado o KPI mais importante do help desk porque reflete simultaneamente a eficiência da equipe, a qualidade da base de conhecimento e a adequação dos processos de atendimento. Uma FCR alta, acima de 70%, indica que os técnicos têm acesso à informação certa no momento do atendimento e estão resolvendo os problemas de forma completa na primeira tentativa. Uma FCR baixa, abaixo de 50%, raramente é problema de esforço da equipe: o mais comum é falta de base de conhecimento integrada ao sistema de chamados, o que faz o técnico diagnosticar mais devagar e às vezes resolver parcialmente. Como calcular: (chamados resolvidos no primeiro contato / total de chamados) × 100.
Qual a diferença entre help desk e service desk? ▼
Help desk é o nível mais básico de suporte técnico: atende chamados pontuais, resolve problemas imediatos e tem foco na resolução técnica do incidente. Service desk é uma evolução do help desk com escopo mais amplo e alinhamento estratégico ao negócio: além de resolver incidentes, gerencia o ciclo de vida completo de requisições de serviço, mudanças e comunicações, opera dentro de um framework de ITSM (como o ITIL), fornece o Ponto Único de Contato (SPOC) entre TI e o restante da empresa, e entrega dados estruturados de desempenho para a gestão tomar decisões. Na prática para PMEs, a distinção mais relevante é a de maturidade operacional: um help desk que opera com sistema de tickets, SLA definido, relatórios mensais e pesquisa de satisfação já entrega grande parte do que um service desk formal oferece, sem necessitar de toda a estrutura metodológica do ITIL.
Qual é o SLA padrão para chamados críticos de TI? ▼
No mercado brasileiro de TI em 2026, o padrão de mercado para SLA de chamados críticos, aqueles que param a operação de um setor inteiro ou de sistemas essenciais, é resposta em até 30 minutos a 1 hora e resolução em até 4 horas, com cobertura 24/7. Para chamados de alta prioridade, que impactam um colaborador individualmente de forma significativa, o padrão é resposta em até 2 horas e resolução em até 8 horas. Para chamados de prioridade média, resposta em até 4 horas e resolução em até 24 horas. Para chamados de baixa prioridade, resposta em até 8 horas e resolução em até 48 horas. Esses são valores de referência do padrão ouro do mercado. Para PMEs iniciando a estruturação do help desk, o mais importante é que os SLAs definidos sejam alcançáveis com a equipe atual e sejam evoluídos gradualmente, não que partam de metas ideais que nenhum processo consegue cumprir.
Como a Mobit estrutura o help desk e suporte técnico para empresas? ▼
A Mobit oferece suporte técnico gerenciado como parte da solução integrada de gestão de TI, com sistema de tickets, SLA definido por criticidade, atendimento remoto e presencial, base de conhecimento e relatório mensal de performance. O processo começa com um diagnóstico do ambiente atual: volume de chamados, categorias mais frequentes, MTTR atual e principais gargalos. Com base nesse diagnóstico, a Mobit define o SLA calibrado para a realidade da empresa, implanta o sistema de tickets com os fluxos de atendimento e escalonamento, e inicia o atendimento com cobertura estendida ou 24/7 conforme o contrato. Mensalmente, a empresa recebe relatório com FCR, MTTR, SLA compliance, taxa de reabertura e CSAT, permitindo ao gestor acompanhar a evolução da qualidade do suporte com dados objetivos. O modelo elimina o help desk informal por WhatsApp e o ponto único de falha do analista único, entregando continuidade de serviço independentemente de férias, afastamentos ou turnover.
Deixe um comentário