Como este tema funciona na sua empresa
Help desk é 1–2 pessoas, tracking básico (planilha de tickets, tempo médio). CSAT informal (pergunta rápida). SLA não formalizado. Foco: quanto demoramos a responder, os usuários estão satisfeitos? Métricas: volume de tickets, tempo médio, satisfação simples.
Help desk estruturado com 3–5 pessoas, ferramenta de ticketing, SLA por tipo de ticket, CSAT por técnico, taxa de reaberturas. Separação L1/L2/L3. KPIs acompanhados mensalmente. Foco: qualidade + velocidade, não apenas volume.
Help desk em escala (20+ pessoas), múltiplos shifts, SLA rigoroso, primeira resolução como KPI chave, satisfaction score segmentado por equipe. Análise preditiva (qual tipo de ticket vai problemas?). Chatbot para L0. Foco: eficiência em escala sem comprometer qualidade.
KPIs de help desk e suporte medem eficiência e qualidade do atendimento de TI. Diferem de KPIs operacionais porque focam em experiência do usuário interno — velocidade, qualidade, satisfação — não em disponibilidade técnica.
O erro clássico: otimizar para velocidade, piora qualidade
Armadilha comum: medir apenas tempo de resolução leva a incentivo perverso — técnico resolve "rápido" deixando problema meio resolvido. Usuário abre novo ticket uma semana depois. No fim, gasto mais tempo.
Cenário de fracasso
"Equipe de help desk foi medida por 'tickets resolvidos por dia'. Técnicos passaram a resolver rápido demais, sem verificar se problema realmente se foi. Taxa de reaberturas subiu de 5% para 15%. Cada ticket reabre custando mais tempo. No fim, produtividade caiu."
Cenário de sucesso
"KPI não é apenas velocidade — é velocidade + qualidade (taxa de reaberturas) + satisfação. Técnico que resolve rápido bem é recompensado. Técnico que resolve rápido mal é identificado (reaberturas) e treinado. Equilíbrio natural emerge."
Lição
Nunca meça uma dimensão isoladamente. Qualidade sempre envolve trade-off com velocidade. Meça ambas.
Os 5 grupos de KPIs de help desk
Grupo 1: Velocidade (tempo de resposta)
Mede rapidez de atendimento.
TTFR (Time To First Response) — tempo até primeira resposta
O que mede: Tempo entre ticket abrir e técnico responder (não resolver, apenas responder).
Meta realista: Crítico < 1 hora, normal < 4 horas, low < 1 dia.
Por que importa: Usuário quer saber rápido que alguém viu. Resposta rápida (mesmo que "estou investigando") já reduz ansiedade.
MTTR (Mean Time To Resolve) — tempo médio de resolução
O que mede: Tempo entre abertura de ticket e fechamento efetivo (problema resolvido, não reabre).
Meta realista: Crítico < 4 horas, normal < 8 horas, low < 2 dias.
Importante: Inclui tempo de decisão, teste, implementação, não apenas trabalho técnico. Usuário abre 9h, técnico resolve 16h = 7 horas MTTR, mesmo que trabalho técnico foi apenas 30 minutos.
Grupo 2: Qualidade (resolver bem)
Mede se resolveu realmente.
Taxa de reaberturas (reopening rate)
O que mede: % de tickets que foram reaberots (usuário voltou porque problema não foi resolvido).
Meta realista: < 5% é boa, < 10% é aceitável, > 15% indica qualidade ruim.
Cálculo: Se 100 tickets foram fechados e 5 foram reaberots, reopening rate = 5%.
Por que importa: Indicador real de qualidade. Técnico que "resolve rápido" mas reabre muito não está sendo eficiente — gasta mais tempo total.
FCR (First Contact Resolution) — primeira resolução
O que mede: % de tickets resolvidos na primeira iteração (sem necessidade de escalação ou follow-up).
Meta realista: 50–60% é bom para help desk. 70%+ é excelente.
Cálculo: Se 100 tickets chegaram ao L1, 60 foram resolvidos em L1 e 40 escalados para L2 = FCR 60%.
Por que importa: FCR alto reduz escalação, economiza tempo de especialista.
Grupo 3: Satisfação (experiência do usuário)
Mede percepção do usuário.
CSAT (Customer Satisfaction) — satisfação transacional
O que mede: Satisfação do usuário com atendimento específico (ticket X).
Pergunta típica: "Satisfeito com como seu problema foi resolvido?" Escala 1–5 ou sim/não.
Meta realista: 75%+ de satisfação é bom, 80%+ é excelente.
Por que importa: Satisfação transacional indica se essa interação foi bem. Importante após cada ticket.
NPS (Net Promoter Score) — lealdade ao suporte
O que mede: Probabilidade de usuário recomendar suporte de TI (relacional, não transacional).
Pergunta: "Quanto você recomendaria o suporte de TI para colega (0–10)?" 9–10 = promotor, 7–8 = passivo, 0–6 = detrator. NPS = % promotores - % detratores.
Meta realista: NPS > 30 é bom, > 50 é excelente.
Por que importa: Indicador de lealdade — se usuário não recomenda (NPS baixo), há problema estrutural no suporte, não apenas em um ticket.
Grupo 4: Produtividade (volume e eficiência)
Mede quanto trabalho está sendo feito.
Tickets resolvidos por pessoa por dia
O que mede: Produtividade média de técnico.
Meta realista: L1 (help desk): 8–12 tickets/dia. L2 (especialista): 2–4 tickets/dia (mais complexo).
Cuidado: Não use como métrica isolada — direciona a "resolver rápido". Combina com qualidade (reaberturas).
SLA compliance — cumprimento de SLA
O que mede: % de tickets resolvidos dentro do prazo prometido (SLA).
Exemplo: Se SLA é "crítico em 4 horas" e de 20 críticos, 18 foram resolvidos em < 4 horas = SLA compliance 90%.
Meta realista: > 95% é bom, < 80% é problema.
Grupo 5: Cobertura (alocação de recursos)
Mede como recursos estão distribuídos.
% de tickets resolvidos em L1
O que mede: Quantos tickets help desk consegue resolver sem escalar para especialista.
Meta realista: 50–70% em L1. Acima de 70% sinaliza que L2 não está ocupado. Abaixo de 40% sinaliza que L1 está muito simples ou L2 é gargalo.
Tempo de especialista (L2/L3)
O que mede: % do tempo que especialista dedica a escalações vs. outras responsabilidades (projetos, manutenção).
Meta realista: 30–40% suporte é aceitável para especialista. Acima de 60% significa especialista virou help desk, projetos não saem.
Ticket distribution (tipo de problema)
O que mede: Breakdown de tickets por tipo — acesso (30%), hardware (20%), software (40%), outros (10%).
Por que importa: Mostra onde estão os problemas. 40% software? Talvez aquele software precisa de training ou tem bug. 30% acesso? Talvez permissões estão bagunçadas.
SLA vs. SLO: qual medir?
SLA (Service Level Agreement)
Contrato formal — "promessas TI faz para negócio". Exemplo: "ajudará responder crítico em 1h, normal em 4h, low em 1 dia". Se não cumprir, há penalidade (crédito, multa).
SLO (Service Level Objective)
Objetivo interno — "o que TI quer alcançar". Pode ser mais rigoroso que SLA. Exemplo: SLA diz "1h crítico", SLO interno é "30 minutos crítico" (almeja melhor).
Qual medir
Acompanhe SLA (compliance com promessa), mas aponte SLO (evolução desejada). Se SLA compliance está 92% e SLO é 95%, há gap a fechar.
Segmentação: crítico vs. normal vs. low
Tickets não são iguais. Crítico (production caiu) merece resposta diferente de low (mouse travado).
Critérios de severidade (customizar ao contexto)
- Crítico: Impacta negócio imediatamente — e-mail fora, banco de dados fora, múltiplos usuários afetados
- Normal: Impacta operação, mas usuário consegue workaround — aplicação lenta, impressora não funciona
- Low: Incômodo, sem impacto imediato — permissão de pasta, sugestão de software, dúvida
SLA por severidade
- Crítico: Resposta < 30 min, resolução < 4h
- Normal: Resposta < 4h, resolução < 8h
- Low: Resposta < 1 dia, resolução < 3 dias
Ajuste à realidade — se crítico é 5% dos tickets, 30min é ok. Se crítico é 40% dos tickets, 30min é impossível (não há recursos).
Análise de causa raiz: por que tickets reabre?
Métrica importante mas frequentemente ignorada: investigar padrões de reaberturas.
Exemplo
Taxa de reaberturas sobe de 5% para 12%. Investigação mostra: 70% das reaberturas são de uma única aplicação, "Contabilidade X". Causa raiz: nova versão da aplicação tem bug em relatório de impostos. Uma linha de código errada causando 70% das reaberturas.
Ação: corrigir bug da aplicação (responsabilidade de desenvolvimento), não fazer mais help desk.
Padrões a procurar
- Reaberturas concentradas em uma pessoa/departamento (cultural, treina-los)
- Reaberturas da mesma aplicação (bug ou design ruim)
- Reaberturas de mesmo tipo de problema (problema estrutural, não operacional)
- Reaberturas que aparecem semanas depois (problema não foi resolvido, apenas aderido)
Sinais de que sua empresa precisa estruturar KPIs de help desk
Se você se reconhece em dois ou mais cenários abaixo, é hora:
- Você não consegue responder quanto tempo demora resolver um problema em média
- Satisfação do usuário com TI não é medida — você "acha que está bom"
- Tickets reabrerem frequentemente sem você saber por quê
- Você não tem SLA formalizado ou não sabe se está cumprindo
- Help desk é medido apenas por "quantidade de tickets resolvidos"
- Você não consegue diferenciar performance de técnico (quem é melhor?)
- Escalação L1 ? L2 é frequente sem você entender por quê
Caminhos para estruturar KPIs de help desk
Seu gestor de help desk estrutura SLA, define como coletar dados (ferramenta de ticketing ou planilha), implementa CSAT simples (pesquisa pós-ticket), apresenta mensalmente.
- Perfil necessário: Gestor de help desk ou coordenador de suporte, familiar com operação
- Tempo estimado: 2–4 semanas para desenhar SLA, 2–4 semanas para implementar coleta e alertas
- Faz sentido quando: Você tem gestor competente, operação já tem alguma estrutura, quer custo baixo
- Risco principal: KPIs ficam desalinhados com realidade (SLA impossível de cumprir), coleta imprecisa (métrica fica irrelevante)
Consultoria de help desk ou fornecedor de plataforma (Zendesk, ServiceNow, TOPdesk) desenha KPIs, implementa em ferramenta, treina equipe.
- Tipo de fornecedor: Consultoria de gestão de suporte, plataforma de helpdesk com implementação, especialista em ITSM
- Vantagem: SLA realista e alinhado a benchmark, implementação rápida, coleta automática, treinamento
- Faz sentido quando: Você quer implementação robusta, quer benchmark de mercado, tem orçamento para ferramenta
- Resultado típico: SLA desenhado em 1–2 semanas, ferramenta implementada em 2–4 semanas, primeiros KPIs apresentados em 6 semanas
Precisa estruturar KPIs de help desk e melhorar qualidade de suporte?
Se gestão de help desk é prioridade, oHub conecta você gratuitamente com especialistas em ITSM, help desk, e plataformas de suporte. Você descreve o desafio, recebe propostas, e decide sem compromisso em menos de 3 minutos.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Quais são os KPIs principais de help desk?
Cinco essenciais: TTFR (tempo até primeira resposta), MTTR (tempo médio de resolução), taxa de reaberturas, CSAT (satisfação), FCR (primeira resolução). Combine velocidade + qualidade + satisfação — não meça uma só dimensão.
Como medir qualidade de atendimento de TI?
Use três métricas complementares: taxa de reaberturas (problema realmente foi resolvido?), CSAT (usuário está satisfeito?), NPS (usuário recomenda suporte?). Uma boa resolução rápida mal resulta em CSAT baixo e reaberturas.
Como não confundir velocidade com qualidade em suporte?
Meça ambas simultaneamente. Velocidade isolada incentiva "resolver rápido, mal resolvido". Qualidade isolada incentiva "investigar para sempre". Combine: velocidade com qualidade (reaberturas), satisfação, SLA. Equilíbrio natural emerge.
Qual é um tempo de atendimento "bom" em suporte?
Depende de severidade. Crítico: resposta < 1h, resolução < 4h. Normal: resposta < 4h, resolução < 8h. Low: resposta < 1 dia, resolução < 3 dias. Customize ao seu contexto e recursos disponíveis — SLA impossível desmotiva.
Como reportar performance de help desk?
Dashboard mensal: TTFR médio, MTTR médio, taxa de reaberturas, CSAT, SLA compliance, volume de tickets (e tendência). Comparar com mês anterior. Destaque padrões — aplicação X tem muitos tickets? Investigar por quê.