Deskhero
Português
Experimente grátis

← Back to articles

As métricas essenciais de relatórios de helpdesk para gestores de suporte

As métricas essenciais de relatórios de helpdesk para gestores de suporte

As métricas que todo gerente de suporte deve reportar, em ordem de prioridade: volume de tickets, tempo até a primeira resposta (FRT), tempo de resolução (MTTR), resolução no primeiro contato (FCR), CSAT, conformidade com o SLA, idade do backlog, taxa de reabertura, taxa de escalonamento, tickets por agente, tempo médio de atendimento (AHT), custo por ticket, NPS e distribuição por canal. Comece por aí e você terá uma visão completa da saúde da sua equipe.

Veja a lista priorizada com a cadência de relatórios recomendada:

  • Volume de tickets — visão diária, tendência semanal
  • Tempo até a primeira resposta (FRT) — diariamente (alerta em tempo real se houver violação do SLA)
  • Tempo de resolução / MTTR — tendência diária, revisão semanal
  • Resolução no primeiro contato (FCR) — semanalmente
  • CSAT — pontuação semanal, tendência mensal
  • Taxa de conformidade com o SLA — indicador diário, resumo semanal
  • Idade do backlog — diariamente para tickets com mais de 48 horas
  • Taxa de reabertura — semanalmente
  • Taxa de escalonamento — semanalmente
  • Tickets por agente — verificação diária da carga de trabalho
  • Tempo médio de atendimento (AHT) — semanalmente
  • Custo por ticket — mensalmente
  • NPS — mensal ou trimestralmente
  • Distribuição por canal — semanalmente

A maioria das equipes tenta acompanhar tudo de uma vez e acaba não agindo sobre nada. Escolha as seis principais para o seu primeiro dashboard, limpe os dados e depois adicione o restante.

Principais conclusões

Relatórios confiáveis de helpdesk começam com dados limpos, uma lista curta de KPIs com metas reais e uma revisão semanal na qual alguém é responsável por cada número.

Ponto Detalhes
Separe métricas de KPIs Classifique cada métrica como “Diagnóstica” ou “KPI” antes de criar qualquer dashboard para evitar sinais mistos.
FRT e CSAT são a dupla de maior ROI Implemente primeiro o tempo até a primeira resposta e o CSAT; eles são rápidos de configurar e estão diretamente sob o controle da equipe.
Benchmarks precisam de contexto Use as faixas de metas sugeridas para os EUA (por exemplo, FRT inferior a 1 hora para e-mail e CSAT de 80% ou mais) como ponto de partida e, depois, defina metas com base na sua própria linha de base de 90 dias.
A qualidade dos dados vem antes dos dashboards Garanta que todos os registros de data e hora sejam gerados pelo servidor e que os campos sejam preenchidos por automação antes de publicar qualquer métrica.
Deskhero automatiza a instrumentação Deskhero preenche os campos dos tickets automaticamente e oferece um mapa integrado de insights dos tickets, para que dados prontos para relatórios estejam disponíveis desde o primeiro ticket.

Índice

Qual é a diferença entre uma métrica de helpdesk e um KPI?

Todo número produzido pelo seu sistema de tickets é uma métrica. Um KPI é uma métrica pela qual você decidiu responsabilizar a equipe, com uma meta e uma consequência caso ela seja descumprida. Essa distinção é importante porque misturar os dois em um único relatório gera confusão sobre o que é informativo e o que é um padrão de desempenho.

Uma métrica se torna um KPI quando três condições são verdadeiras: ela tem impacto direto no negócio (o CSAT está ligado à retenção), é estável o suficiente para apresentar uma tendência significativa ao longo de semanas e alguém da equipe pode efetivamente alterá-la por meio de suas decisões. O volume de tickets, por exemplo, quase sempre é uma métrica diagnóstica. Ele informa o nível de ocupação, mas nenhum agente consegue reduzir a demanda recebida simplesmente trabalhando mais. O CSAT, por outro lado, é candidato a KPI porque agentes e gerentes podem influenciá-lo por meio da qualidade, velocidade e precisão das respostas.

Na prática, a divisão fica assim:

  • Métricas diagnósticas (contexto, não metas): volume de tickets, distribuição por canal, quantidade de escalonamentos, AHT
  • Candidatos a KPI (defina uma meta e acompanhe semanalmente): FRT, MTTR, FCR, CSAT, conformidade com o SLA, taxa de reabertura, custo por ticket

Um erro comum é combinar métricas de volume e qualidade no mesmo gráfico sem normalização. Um agente que atende 80 tickets por dia quase sempre apresentará um CSAT menor do que alguém que atende 30, não porque seja pior, mas porque um volume alto reduz a qualidade das respostas. Informe os tickets por agente junto com o CSAT para que os números contem a história completa.

Dica profissional: Ao configurar os relatórios pela primeira vez, classifique cada métrica do seu dashboard como “Diagnóstica” ou “KPI” no cabeçalho da coluna ou no título do widget. Isso obriga a equipe a concordar previamente sobre o que é uma meta e o que é apenas contexto, além de impedir que os gerentes tratem um número diagnóstico como uma avaliação de desempenho.

As principais métricas de relatórios de helpdesk, agrupadas por finalidade

As 17 métricas de helpdesk acompanhadas com mais frequência se dividem em quatro grupos naturais: produtividade, eficiência, experiência do cliente e confiabilidade/finanças. Cada grupo abaixo inclui a fórmula, um exemplo calculado, uma faixa de benchmark com foco nos EUA e a ação a tomar quando o número mudar.

Diagrama de métricas de helpdesk categorizadas por finalidade

Métricas de produtividade

Volume de tickets Definição: Total de tickets criados em um período. Fórmula: Contagem de tickets com created_at dentro da janela de relatório. Exemplo: 340 tickets de segunda a sexta-feira = 68 por dia. Benchmark: Varia conforme o tamanho da equipe; acompanhe a mudança semana a semana, não o número absoluto. Se houver um pico: Verifique se há um incidente no produto, uma campanha de marketing ou um fator sazonal antes de aumentar o quadro de funcionários. Tipo: Apenas diagnóstica.

Tickets por agente Definição: Carga média diária de tickets por agente ativo. Fórmula: Total de tickets atribuídos ÷ número de agentes ativos no período. Exemplo: 340 tickets ÷ 5 agentes = 68 tickets por agente por semana. Benchmark: 40–80 tickets por agente por dia é uma faixa comum para suporte por e-mail; o chat ao vivo reduz esse número significativamente. Se aumentar: Redistribua as atribuições ou inicie uma revisão de contratação; a sobrecarga sustentada prevê queda do CSAT em 2–4 semanas. Tipo: Diagnóstica.

Distribuição por canal Definição: Percentual de tickets recebidos por cada canal (e-mail, chat, telefone, formulário, redes sociais). Fórmula: (Tickets do canal X ÷ total de tickets) × 100.

Benchmark: Não há uma meta universal; use-a para alinhar a equipe e as regras de SLA à combinação real de canais. Se a participação do chat crescer: Revise o AHT e a equipe para sessões simultâneas. Tipo: Diagnóstica.

Métricas de eficiência

Tempo até a primeira resposta (FRT) Definição: Tempo entre a criação do ticket e a primeira resposta do agente. Fórmula: first_response_at − created_at (apenas no horário comercial para a maioria dos SLAs). Exemplo: Ticket criado às 9h e primeira resposta às 9h47 = FRT de 47 minutos. Benchmark: Menos de 1 hora para e-mail é uma meta amplamente citada nos EUA; menos de 5 minutos para chat ao vivo. Se o FRT aumentar: Verifique o direcionamento da fila, a disponibilidade dos agentes e se o reconhecimento automático está mascarando um atraso real. Tipo: Candidato a KPI.

Mãos ajustando um botão de controle do tempo de resposta

Tempo médio de atendimento (AHT) Definição: Tempo médio que um agente dedica ativamente a um ticket, da abertura ao encerramento. Fórmula: Tempo total de atendimento de todos os tickets ÷ número de tickets encerrados. Exemplo: 850 minutos de atendimento ÷ 17 tickets = AHT de 50 minutos. Benchmark: Altamente dependente do contexto; um AHT de 10 minutos para redefinições de senha e de 90 minutos para disputas de cobrança podem estar ambos corretos. Se o AHT aumentar: Audite as categorias de tickets que consomem mais tempo e crie artigos na base de conhecimento para elas. Tipo: Diagnóstica (use como KPI apenas para categorias específicas de tickets, não para toda a fila).

Tempo de resolução / MTTR Definição: Tempo médio para resolver, desde a criação do ticket até o encerramento. Fórmula: Soma de (resolved_at − created_at) para todos os tickets encerrados ÷ quantidade de tickets encerrados. Exemplo: 5 tickets resolvidos em 2h, 4h, 6h, 3h e 5h = 20h no total ÷ 5 = MTTR de 4 horas. Benchmark: Menos de 24 horas para prioridade padrão; menos de 4 horas para alta prioridade é uma meta comum de service desk nos EUA. Se o MTTR aumentar: Segmente por prioridade e categoria. Um único tipo de ticket frequentemente eleva a média; corrigir essa categoria melhora o número geral. Tipo: Candidato a KPI.

Resolução no primeiro contato (FCR) Definição: Percentual de tickets resolvidos sem contato posterior ou reabertura. Fórmula: (Tickets resolvidos no primeiro contato ÷ total de tickets) × 100.

Se o FCR cair: Revise as categorias de tickets mais reabertas e atualize os scripts dos agentes ou o conteúdo da base de conhecimento. Tipo: Candidato a KPI.

Métricas de experiência do cliente

CSAT (Customer Satisfaction Score) Definição: Percentual de clientes que avaliam positivamente sua experiência de suporte (normalmente 4–5 em uma escala de 5 pontos). Fórmula: (Respostas positivas ÷ total de respostas) × 100.

O design da pesquisa importa: Pesquisas de CSAT bem elaboradas, enviadas até 30 minutos após o encerramento do ticket, produzem feedback de maior qualidade e mais acionável do que pesquisas enviadas dias depois. Se o CSAT cair: Analise os comentários textuais, segmente por agente e categoria e procure padrões antes de tirar conclusões. Tipo: Candidato a KPI.

NPS (Net Promoter Score) Definição: Probabilidade de os clientes recomendarem seu suporte, em uma escala de 0–10. Promotores (9–10) menos Detratores (0–6) = NPS. Fórmula: (% de Promotores − % de Detratores).

Benchmark: Um NPS positivo (acima de 0) é o mínimo; acima de +30 é considerado bom para suporte B2B. Se o NPS cair: O NPS é um indicador atrasado, portanto combine-o com CSAT e taxa de reabertura para encontrar o fator operacional. Tipo: Candidato a KPI (cadência mensal ou trimestral).

Taxa de reabertura Definição: Percentual de tickets resolvidos que são reabertos pelo cliente. Fórmula: (Tickets reabertos ÷ total de tickets resolvidos) × 100.

Se a taxa de reabertura aumentar: Verifique se os agentes estão encerrando tickets prematuramente para atingir as metas de tempo de resolução. Tipo: Candidato a KPI.

Métricas de confiabilidade e SLA

Taxa de conformidade com o SLA Definição: Percentual de tickets resolvidos ou respondidos dentro da janela de SLA acordada. Fórmula: (Tickets dentro do SLA ÷ total de tickets) × 100.

Se a conformidade cair: Identifique qual nível de prioridade está violando o SLA e se a violação ocorre no FRT ou no MTTR. Tipo: Candidato a KPI.

Idade do backlog Definição: Distribuição dos tickets abertos conforme o tempo que permanecem sem resolução. Fórmula: Para cada ticket aberto: registro de data e hora atual − created_at. Apresente como um histograma (0–24h, 24–48h, 48–72h, 72h+). Exemplo: 12 tickets com mais de 72 horas = um backlog que exige triagem imediata. Benchmark: O objetivo é ter zero tickets mais antigos que o seu nível mais alto de SLA; qualquer ticket com mais de 72 horas deve gerar uma revisão manual. Se o backlog crescer: Divida a fila por faixas de idade e atribua primeiro os tickets mais antigos, independentemente do rótulo de prioridade. Tipo: Candidato a KPI (acompanhamento diário).

Taxa de escalonamento Definição: Percentual de tickets escalonados para um nível superior ou especialista. Fórmula: (Tickets escalonados ÷ total de tickets) × 100.

Se a taxa de escalonamento aumentar: Segmente por categoria de ticket e agente. Uma única categoria responsável pela maioria dos escalonamentos geralmente indica uma lacuna na base de conhecimento. Tipo: Diagnóstica (pode se tornar um KPI se os programas de treinamento estiverem vinculados a ela).

Métricas financeiras

Custo por ticket Definição: Custo total do suporte dividido pelo total de tickets tratados no período. Fórmula: (Custo total do suporte: salários + ferramentas + despesas gerais) ÷ total de tickets. Exemplo: Custo mensal de suporte de $25.000 ÷ 1.400 tickets = $17,86 por ticket. Benchmark: As faixas variam muito conforme o setor e o canal; acompanhe sua própria tendência em vez de uma meta absoluta. Se o custo por ticket aumentar: Verifique se o volume de tickets caiu (os custos fixos foram distribuídos por menos tickets) ou se o AHT aumentou. Tipo: Candidato a KPI (mensal).

Estatística em destaque: Pesquisas da Forrester identificam consistentemente a mensuração da experiência do cliente como uma das principais prioridades de investimento, observando que organizações que medem a experiência de forma consistente estão mais bem posicionadas para melhorar a retenção e a receita — o que constitui o argumento de negócio para tratar CSAT e NPS como KPIs verdadeiros, não como complementos opcionais.

Como definir metas e benchmarks realistas para sua equipe

Listas de benchmarks são um ponto de partida, não uma linha de chegada. Uma meta de MTTR de 24 horas é razoável para uma equipe de cinco pessoas que lida com 200 tickets por semana. Ela está quase certamente errada para um service desk corporativo com 50 pessoas que processa 10.000 tickets em quatro níveis de prioridade. A metodologia abaixo oferece uma forma repetível de definir metas adequadas ao seu contexto real.

  1. Estabeleça uma linha de base. Extraia 90 dias de dados históricos para cada métrica. Calcule a mediana (não a média — os valores discrepantes distorcem as médias). Essa mediana representa seu nível atual de desempenho.
  2. Compare com seus pares. Use pesquisas do setor e compilações de KPIs de TI para encontrar a faixa de equipes do seu porte e segmento. Posicione sua linha de base dentro dessa faixa.
  3. Defina uma meta de melhoria de 90 dias. Busque uma melhoria de 10–15% no seu KPI mais fraco, não um salto para o nível dos melhores. Metas agressivas que nunca são atingidas desmotivam as equipes mais rapidamente do que a ausência total de metas.
  4. Aplique ajustes sazonais. Se o volume de tickets aumenta 40% no quarto trimestre, sua meta de MTTR para novembro e dezembro deve refletir essa realidade, não a linha de base do segundo trimestre.
  5. Crie uma faixa de confiança, não um único número. Em vez de “o CSAT deve ser 85%”, escreva “meta de CSAT: 83–87%”. Uma faixa reconhece o ruído da medição e evita pânico por causa da queda de uma única semana.

Seguir um processo repetível de coleta–limpeza–análise–ação é o que transforma dados de helpdesk em crescimento mensurável para o negócio, em vez de um dashboard que ninguém consulta.

Métrica Faixa de meta sugerida para os EUA Cadência de relatórios
Tempo até a primeira resposta (e-mail) Menos de 1 hora Diária
Tempo até a primeira resposta (chat) Menos de 5 minutos Tempo real
MTTR (prioridade padrão) Menos de 24 horas Diária
MTTR (alta prioridade) Menos de 4 horas Alerta em tempo real
Resolução no primeiro contato 80% Semanal
CSAT 80%+ Pontuação semanal
Conformidade com o SLA 90% Indicador diário
Backlog (tickets com mais de 72h) 0 Diária
Taxa de reabertura Menos de 5% Semanal
Custo por ticket Acompanhar tendência Mensal

A redução do churn está relacionada ao CSAT e ao FCR. Essa perspectiva faz com que os relatórios sejam levados a sério pela liderança executiva.*

Quando usar médias móveis em vez de metas de período contra período: use uma média móvel de 28 dias para CSAT e NPS, porque os tamanhos das amostras semanais geralmente são pequenos demais para ter relevância estatística. Use período contra período (esta semana versus a semana passada, este mês versus o mês passado) para FRT e MTTR, nos quais você quer identificar rapidamente mudanças operacionais.

Como criar dashboards que cada público realmente usará

Um dashboard que ninguém consulta é pior do que não ter dashboard, porque cria a ilusão de mensuração sem oferecer o benefício dela. A solução é mapear os públicos: cada grupo recebe apenas as métricas sobre as quais pode agir.

Mapeamento de público para métricas

Agentes precisam de uma visão pessoal: seu próprio FRT, quantidade de tickets abertos, tickets resolvidos hoje e alertas de violação do SLA na sua fila. Nada além disso. Mostrar aos agentes a média de CSAT da equipe sem contexto apenas gera ansiedade.

Mãos gerenciando itens do espaço de trabalho e um cronômetro

Líderes de equipe precisam da visão operacional: distribuição do FRT (não apenas a média), MTTR por categoria, conformidade com o SLA por nível de prioridade, taxa de reabertura e um ranking de tickets por agente. O ranking só é útil quando acompanhado do CSAT por agente, para que carga de trabalho e qualidade permaneçam visíveis juntas.

Gerentes de suporte precisam de linhas de tendência e relatórios de exceção: tendência semanal do CSAT, mapa de calor da idade do backlog, taxa de escalonamento por categoria, custo por ticket mês a mês e tendência do FCR. Os modelos de dashboard de suporte ao cliente que funcionam melhor para gerentes combinam um scorecard geral com capacidade de detalhamento por categoria e agente.

Executivos precisam de um resumo de uma página: pontuação e tendência do CSAT, taxa de conformidade com o SLA, custo por ticket e um único número de NPS. Eles não precisam do volume de tickets, a menos que esteja relacionado a um evento de negócio. Limite a visão executiva a quatro ou cinco números no máximo.

  • Volume de tickets ao longo do tempo: gráfico de linhas, granularidade diária, janela de 30 dias
  • Indicador de conformidade com o SLA: mostrador ou cartão percentual, atualizado a cada hora
  • Histograma da distribuição do FRT: mostra a dispersão, não apenas a média — uma mediana de 45 minutos com percentil 90 de 4 horas conta uma história muito diferente de uma mediana de 45 minutos com percentil 90 de 55 minutos
  • Linha de tendência do MTTR: média móvel de 28 dias, segmentada por prioridade
  • Tendência do CSAT e comentários textuais: linha da pontuação mais um feed das avaliações negativas mais recentes
  • Mapa de calor do backlog por idade: linhas por categoria, colunas por faixa de idade (0–24h, 24–48h, 48–72h, 72h+)
  • Ranking de tickets por agente: acompanhado do CSAT por agente na mesma visão

Cadência dos relatórios

  • Dashboards em tempo real: FRT, conformidade com o SLA, quantidade de tickets abertos — sempre ativos para agentes e líderes
  • Visões diárias: resumo enviado por e-mail com o volume, FRT e eventuais violações do SLA do dia anterior — para líderes de equipe
  • Revisões semanais: CSAT, FCR, taxa de reabertura, taxa de escalonamento e tendência do MTTR — para gerentes em uma reunião recorrente
  • Resumos executivos mensais: CSAT, NPS, custo por ticket, conformidade com o SLA e um parágrafo explicando o que mudou e por quê

Reserve as revisões semanais para análise de tendências, não para apagar incêndios.

Como acertar seus dados antes de gerar relatórios

As métricas são tão confiáveis quanto os dados por trás delas. Um tempo até a primeira resposta calculado a partir de registros de data e hora editados por agentes, em vez de eventos registrados pelo servidor, não é uma medição — é um palpite. Corrija a instrumentação antes de criar o dashboard.

Esquema mínimo de ticket

Todo ticket precisa ter estes campos preenchidos na criação ou no encerramento, não manualmente pelos agentes:

  • created_at — registro de data e hora do servidor, nunca editável
  • first_response_at — registro de data e hora do servidor da primeira resposta enviada pelo agente (não um reconhecimento automático)
  • resolved_at — registro de data e hora do servidor da mudança de status para “resolvido”
  • assignee_id — identificador do agente
  • channel — e-mail, chat, formulário, telefone, redes sociais
  • sla_type — qual nível de SLA se aplica
  • priority — baixa, normal, alta, urgente
  • tags — taxonomia de categorias (veja abaixo)
  • escalation_flag — booleano, definido por automação quando o ticket passa para um nível superior
  • reopened_count — número inteiro, incrementado por automação quando um ticket encerrado recebe uma nova resposta
  • cost_center — departamento ou linha de produto, para segmentação do custo por ticket

Se algum desses campos estiver ausente ou for preenchido manualmente pelos agentes, suas métricas sofrerão desvios. O processo de mapeamento de e-mail para ticket é onde a maioria desses campos deve ser definida automaticamente, não depois do fato.

Tags e taxonomia

Use uma lista de seleção controlada para as tags, não texto livre. Tags em texto livre produzem 40 variações de “dúvida sobre cobrança” em um mês. Uma taxonomia controlada com cinco a dez categorias principais e dois níveis de subcategoria é suficiente para a maioria das equipes. Sempre que possível, automatize a atribuição de tags usando palavras-chave do assunto e regras de domínio do remetente.

Integrações e extensões de marketplace podem adicionar telemetria de relatórios e preenchimento automatizado de campos, reduzindo significativamente os desvios causados pela inserção manual — o princípio se aplica independentemente da plataforma utilizada.

Lista de verificação da instrumentação

  • [ ] Todos os registros de data e hora são gerados pelo servidor, não editáveis pelos agentes
  • [ ] A normalização do fuso horário é aplicada (armazene tudo em UTC e converta para exibição)
  • [ ] Respostas de reconhecimento automático são excluídas do cálculo do FRT
  • [ ] O horário comercial está configurado corretamente nas regras de SLA
  • [ ] A sinalização de escalonamento é definida por automação, não por uma caixa de seleção do agente
  • [ ] A contagem de reaberturas é incrementada automaticamente quando chega uma resposta a um ticket encerrado
  • [ ] O campo de canal é preenchido pelas regras de roteamento, não por seleção manual

Dica profissional: *Faça uma auditoria da qualidade dos dados dos seus últimos 30 dias de tickets antes de publicar qualquer dashboard. Extraia o percentual de tickets com first_response_at nulo ou resolved_at nulo.

Armadilhas de relatórios que tornam suas métricas enganosas

Os relatórios de helpdesk mais perigosos são aqueles que parecem organizados, mas medem a coisa errada. Estes são os erros que produzem consistentemente decisões operacionais ruins.

  • Acompanhar a contagem bruta de tickets como métrica de desempenho. O volume informa a demanda, não o desempenho. Uma equipe que encerra 500 tickets por semana não é necessariamente melhor do que uma que encerra 200 — se a equipe de 500 tickets tiver CSAT de 60% e taxa de reabertura de 15%, ela está resolvendo tickets sem realmente solucionar os problemas. Sempre combine volume com métricas de qualidade.

  • Calcular a média dos tempos de resposta sem observar a distribuição. Um FRT médio de 2 horas parece aceitável até você descobrir que 30% dos tickets aguardam mais de 8 horas. Informe o percentil 90 do FRT junto com a mediana. Essa única mudança revela se você tem um problema sistêmico ou alguns tickets discrepantes puxando a média para cima.

  • Dar ênfase excessiva à produtividade dos agentes em detrimento do CSAT. Rankings baseados exclusivamente em tickets encerrados incentivam os agentes a encerrar tickets rapidamente, não necessariamente bem. Uma equipe que implementou um ranking de “tickets encerrados por dia” viu a taxa de reabertura subir de 4% para 11% em seis semanas, porque os agentes marcavam os tickets como resolvidos antes de os clientes confirmarem que o problema havia sido corrigido. Combine toda métrica de produtividade com uma métrica de qualidade.

  • Misturar tickets escalonados às métricas do fluxo normal. Tickets escalonados têm complexidade e tempos de atendimento fundamentalmente diferentes. Incluí-los na média geral do MTTR aumenta o número e faz o desempenho do nível padrão parecer pior do que realmente é. Separe os tickets escalonados em uma coorte própria de relatórios.

  • Ignorar completamente a taxa de reabertura. A taxa de reabertura é um dos sinais mais claros da qualidade da resolução, e muitas equipes nunca a acompanham. Uma taxa crescente de reabertura frequentemente prevê uma queda do CSAT em duas ou três semanas, dando tempo para intervir antes que os clientes comecem a abandonar a empresa.

  • Tratar o NPS como uma métrica operacional em tempo real. O NPS é um sinal estratégico, não um número diário. Equipes que verificam o NPS semanalmente e reagem a oscilações de uma única semana desperdiçam energia com ruído estatístico. Use o NPS trimestralmente e combine-o com o CSAT para obter a visão operacional.

Um modelo de dashboard pronto para uso que você pode copiar hoje

O esquema abaixo fornece os nomes exatos das colunas para uma planilha ou exportação SQL, além de consultas de exemplo para os cálculos mais comuns. Ele corresponde diretamente ao esquema de tickets da seção sobre qualidade dos dados acima.

Esquema e fórmulas da planilha

Nome da coluna Fórmula / origem Observações
ticket_id Gerado pelo sistema Chave primária
created_at Registro de data e hora do servidor UTC
first_response_at Registro de data e hora do servidor Excluir reconhecimentos automáticos
resolved_at Registro de data e hora do servidor UTC
frt_minutes (first_response_at − created_at) em minutos Apenas no horário comercial
mttr_hours (resolved_at − created_at) em horas Apenas no horário comercial
fcr_flag 1 se reopened_count = 0, caso contrário 0 Booleano
aht_minutes Tempo de atendimento registrado pelo sistema Não é tempo de relógio
cost_per_ticket monthly_support_cost ÷ tickets_in_month Recalcular mensalmente
csat_score Resposta da pesquisa (1–5) Vincular por ticket_id
sla_met 1 se resolvido dentro da janela de SLA, caso contrário 0 Booleano
channel Regra de roteamento Lista de seleção controlada
escalation_flag Booleano definido por automação Não é uma caixa de seleção do agente
reopened_count Número inteiro incrementado automaticamente Aciona a sinalização de FCR

Trechos de SQL de exemplo

FRT por ticket (horário comercial, em minutos):

SELECT ticket_id,
       DATEDIFF(MINUTE, created_at, first_response_at) AS frt_minutes
FROM tickets
WHERE first_response_at IS NOT NULL;

Tickets por agente por dia:

SELECT assignee_id,
       CAST(created_at AS DATE) AS ticket_date,
       COUNT(*) AS tickets_assigned
FROM tickets
GROUP BY assignee_id, CAST(created_at AS DATE)
ORDER BY ticket_date DESC, tickets_assigned DESC;

Taxa de FCR para um período:

SELECT
  SUM(CASE WHEN reopened_count = 0 THEN 1 ELSE 0 END) * 100.0 / COUNT(*) AS fcr_rate
FROM tickets
WHERE resolved_at BETWEEN '2026-01-01' AND '2026-01-31';

Layout das abas do dashboard

  1. Aba do agente: FRT pessoal, tickets abertos, tickets resolvidos hoje, alertas de violação do SLA — widgets: cartões numéricos + banner de alerta
  2. Aba do gerente: histograma da distribuição do FRT, linha de tendência do MTTR, tendência do CSAT + feed de comentários textuais, indicador de conformidade com o SLA, mapa de calor da idade do backlog, ranking de tickets por agente acompanhado do CSAT por agente
  3. Aba executiva: cartão da pontuação de CSAT, número do NPS, taxa de conformidade com o SLA, tendência do custo por ticket — quatro widgets, sem detalhamento

Dica profissional: Versione seu modelo de dashboard incluindo uma data no nome do arquivo (por exemplo, support_dashboard_v2_2026-02.xlsx) e mantenha a versão anterior por um trimestre. Quando uma meta de métrica mudar, você precisará do modelo antigo para explicar por que a tendência histórica parece diferente da nova linha de base.

Onde os relatórios realmente geram retorno

As equipes que mais aproveitam as métricas de relatórios de helpdesk não são aquelas com os dashboards mais sofisticados. São as que escolhem duas ou três métricas, limpam os dados e as revisam em uma reunião semanal recorrente na qual alguém é responsável pelo número.

FRT e CSAT juntos são a dupla de maior ROI para a maioria das equipes pequenas e médias. O FRT é fácil de instrumentar, simples de entender e está diretamente sob o controle do agente. O CSAT fecha o ciclo ao mostrar se a velocidade resultou em uma boa experiência. A idade do backlog é a terceira métrica que vale a pena acompanhar obsessivamente no início, porque um backlog crescente é o primeiro sinal de alerta de que uma equipe está ficando para trás, antes que qualquer outra métrica mostre isso.

A mudança cultural que potencializa tudo isso é simples: pare de revisar métricas em um relatório e comece a revisá-las em uma conversa. Um número em um slide não muda nada. Um líder de equipe perguntando “por que nosso FRT aumentou na terça-feira à tarde?” e obtendo uma resposta real — uma interrupção no produto, uma configuração incorreta de roteamento, dois agentes doentes — é o que transforma mensuração em melhoria. A pesquisa da Forrester sobre prioridades de investimento em CX reforça isso: a mensuração consistente combinada ao acompanhamento organizacional é o que diferencia as equipes que melhoram a retenção das equipes que apenas a acompanham.

Deskhero oferece dados prontos para relatórios desde o primeiro dia

Se sua equipe exporta CSVs manualmente, reúne planilhas ou descobre que metade dos campos first_response_at está nula, o problema geralmente é a plataforma, não o processo. Essa é a situação em que migrar para um helpdesk desenvolvido especificamente para essa finalidade se paga rapidamente.

Deskhero

Deskhero transforma qualquer caixa de entrada do Gmail ou Microsoft 365 em uma fila compartilhada de tickets em poucos minutos, com registros de data e hora do servidor, campos definidos por automação e um mapa integrado de insights dos tickets que alimenta as métricas deste guia sem inserção manual de dados. A IA redige respostas com base na sua base de conhecimento aprovada, preenche tags automaticamente a partir das regras de roteamento e registra todas as ações automatizadas para manter sua trilha de auditoria limpa. O estudo de caso da eM Client documenta o tipo de ganho de eficiência que as equipes obtêm quando a plataforma cuida da instrumentação automaticamente. Um teste gratuito de 30 dias não exige cartão de crédito — comece por ele, importe o esquema de planilha deste guia e você terá um dashboard funcional antes do fim do período de teste.

Fontes

As referências a seguir foram usadas na preparação deste guia. Consulte o material da Forrester para entender o argumento de negócio por trás da mensuração de CX, o guia de design de pesquisas para a instrumentação de CSAT/NPS e o guia de dados e crescimento para a metodologia de coleta–limpeza–análise–ação.

Perguntas frequentes

Quais são as principais métricas para relatórios de service desk?

As principais métricas de service desk são tempo até a primeira resposta, tempo de resolução (MTTR), resolução no primeiro contato, CSAT, taxa de conformidade com o SLA, idade do backlog, taxa de reabertura, taxa de escalonamento, tickets por agente e custo por ticket. Se estiver começando a criar relatórios do zero, comece pelo FRT e pelo CSAT.

Quais são bons KPIs para um helpdesk de TI?

Combine-os com métricas departamentais de TI, como disponibilidade e satisfação dos funcionários, para obter o contexto completo, conforme recomendam as estruturas de KPIs de TI.

Com que frequência devo enviar pesquisas de CSAT?

Envie uma pesquisa de CSAT até 30 minutos após o encerramento do ticket para obter as maiores taxas de resposta e o feedback mais preciso. Um design eficaz mantém a pesquisa com uma ou duas perguntas e sempre acompanha a taxa de resposta junto com a pontuação — uma taxa de resposta baixa torna pouco confiável até mesmo uma pontuação alta de CSAT.

O que é uma boa taxa de resolução no primeiro contato?

Calcule-a como o percentual de tickets resolvidos sem contato posterior ou reabertura e segmente por categoria de ticket para descobrir onde a qualidade da resolução é mais fraca.

Como calcular o custo por ticket?

Divida os custos totais de suporte (salários, ferramentas e despesas gerais) de um período pelo número total de tickets tratados nesse mesmo período. Por exemplo, $25.000 em custos mensais divididos por 1.400 tickets equivalem a $17,86 por ticket. Acompanhe a tendência mês a mês em vez de compará-la a um número absoluto, pois o custo por ticket varia significativamente conforme o setor, a combinação de canais e o tamanho da equipe.