Como Criar um Relatório de Tickets de Suporte: Passo a Passo

Um relatório de tickets de suporte é, na maior parte, um problema de definições. Tickets criados, tickets resolvidos, tempo de primeira resposta e tempo de resolução parecem autoexplicativos. Cada um deles tem mais de um significado oficial dentro do mesmo help desk.

Defina as regras de contagem e o relatório se fará sozinho. Pule essa etapa e duas pessoas honestas extrairão a mesma exportação e discordarão por horas.

Este guia aborda o que deve constar no relatório, os quatro pontos onde as definições se dividem e como criá-lo a partir de uma exportação de tickets.

O que deve constar em um relatório de tickets de suporte

O volume por si só não diz quase nada. A organização é o que torna os números confiáveis para leitura.

Elemento	Por que está lá
Tickets criados no período	O lado da demanda
Tickets resolvidos no período	O lado da oferta, sob uma regra de status definida
Backlog no final do período	Tudo o que não foi resolvido ou fechado
Tempo de primeira resposta	Sob um cronômetro definido e uma definição estabelecida
Tempo de resolução	Primeira ou total, nomeada explicitamente
Tickets reabertos	O sinal de qualidade que os outros números ocultam
Tickets sem resposta	Onde o processo falhou completamente
Uma base de data e escopo definidos	Quais canais, marcas e filas estão incluídos

Duas linhas têm mais peso do que o tamanho sugere. Tickets reabertos e sem resposta são os pontos onde um relatório deixa de ser apenas um placar e se torna útil.

O Zendesk publica as fórmulas subjacentes, o que torna as definições verificáveis em vez de uma questão de opinião. Sua referência de métricas e atributos detalha cada uma delas.

Comece pelo mais simples. Tickets resolvidos é "o número de tickets resolvidos ou fechados", de modo que a métrica abrange dois status em vez de um.

O "tempo de primeira resposta" tem duas definições oficiais

Esta é a bifurcação que causa mais divergências, e o próprio fornecedor alerta diretamente sobre isso.

A documentação de SLA do Zendesk diz isso em uma única linha: "Não confunda o tempo de resposta de SLA com a métrica nativa de tempo de resposta do Zendesk."

A métrica nativa é rigorosa sobre quem responde. O Zendesk afirma que "o tempo de primeira resposta é calculado exclusivamente com base nas respostas dos agentes". Ações automatizadas e relacionadas a bots "não são consideradas no cálculo do tempo de primeira resposta".

A métrica de SLA não é. Nela, o tempo de primeira resposta é "o tempo entre a criação do ticket e o primeiro comentário público de um agente (ou resposta automática)". O Zendesk acrescenta que "as métricas de tempo de resposta são cumpridas se você configurar um gatilho para responder automaticamente com um comentário público".

Leia as duas juntas e a consequência será evidente. Uma resposta automática pode cumprir sua meta de SLA enquanto o tempo de primeira resposta nativo continua correndo.

Portanto, um relatório que mostra 98% de cumprimento de SLA e uma mediana de tempo de primeira resposta de quatro horas não está se contradizendo. Ele está relatando duas coisas diferentes, ambas de forma correta.

Há duas exceções menores que vale a pena conhecer. No caso em que um agente cria o ticket e o primeiro comentário é público, a referência de métricas de duração diz que o segundo carimbo de data/hora "muda para o segundo comentário público do agente".

E tickets compartilhados não contam. O Zendesk observa que quando um agente comenta publicamente a partir de outra conta usando o compartilhamento de tickets, "isso não conta para o tempo de primeira resposta da sua conta".

O "tempo de resolução" também tem duas definições

A mesma divisão ocorre nas métricas de resolução, e aqui ambas as versões vêm por padrão.

O tempo de primeira resolução é a "duração entre a criação do ticket e sua primeira resolução", terminando na "primeira vez que o status do ticket é definido como resolvido".

O tempo de resolução total é a "duração entre a criação do ticket e sua resolução mais recente". Ele termina na "última vez que o status do ticket foi definido como resolvido".

Para um ticket resolvido apenas uma vez, os dois são idênticos. Para um ticket resolvido, reaberto e resolvido novamente, eles divergem pelo tempo que a segunda rodada levou.

É exatamente por isso que os tickets reabertos devem constar no relatório. O Zendesk os define como tickets "reabertos após terem sido resolvidos" e observa que a métrica "não inclui tickets resolvidos e reabertos durante a mesma atualização".

Há um efeito de segunda ordem que as pessoas não percebem. A média diária de tickets resolvidos os contabiliza "apenas se estiverem atualmente resolvidos ou fechados". Portanto, um ticket reaberto hoje sai silenciosamente da contagem de resolvidos do mês passado.

Portanto, um relatório gerado em junho não será igual se for gerado novamente em agosto. Nada quebrou; o status subjacente mudou.

Mais duas métricas separam o tempo de espera do tempo de trabalho. O tempo de espera do solicitante é o tempo combinado nos status novo, aberto e em espera, e o tempo de espera do agente é o tempo combinado em pendente.

Essa dupla responde à pergunta que uma média de resolução não consegue responder. Tempos de resolução longos causados pela espera pelo cliente são um problema diferente de tempos de resolução longos causados pelo tamanho da fila.

Horas corridas ou horas úteis

Cada número de resposta e resolução existe em dois cronômetros, e escolher um deles não é opcional.

O Zendesk armazena ambos. Após a primeira resposta pública, "o sistema calcula o tempo de primeira resposta em horas corridas e horas úteis". Ambas as métricas "são armazenadas com os dados do ticket".

O padrão que você vê não é neutro. O Zendesk observa que os relatórios pré-criados do Explore "exibem informações em horas corridas". As métricas de horas úteis "estão disponíveis e podem ser usadas em seus próprios relatórios".

Uma equipe que trabalha das nove às cinco parecerá lenta no relatório padrão. Um ticket que chega às 18h de sexta-feira acumula cerca de 63 horas corridas antes de segunda-feira de manhã, e quase zero horas úteis.

Canais de conversa em tempo real trazem mais uma complicação. A métrica de tempo de primeira resposta (seg) para mensagens e chat "ignora suas configurações de horário comercial de mensagens e horário de funcionamento do chat em tempo real".

E os SLAs de tempo de resposta do chat são opcionais. O Zendesk afirma que os SLAs de tempo de resposta para chat em tempo real "são desativados por padrão", portanto, sua ausência é um estado de configuração e não um desempenho perfeito.

Como fazer isso manualmente

Opção 1: Uma aba por família de métricas

Exporte a lista de tickets com os campos de métricas e, em seguida, divida o volume, o tempo de resposta e o tempo de resolução em abas separadas antes de resumir qualquer coisa.

Mantenha as colunas de horas corridas e horas úteis lado a lado, em vez de escolher apenas uma no momento da exportação. Certamente lhe pedirão a outra depois.

Calcule medianas em vez de médias para as métricas de tempo. Alguns poucos tickets deixados abertos durante um feriado arrastarão a média para um patamar onde nenhum ticket real realmente se encontra.

O limite é que uma planilha não consegue ver o histórico de status. Você obtém o estado atual de cada ticket, portanto, o comportamento de reabertura precisa vir da contagem de reabertos, e não de uma reconstrução.

Opção 2: Uma aba de definições, escrita primeiro

Registre a definição do tempo de resposta, o cronômetro, a métrica de resolução, a regra de status para resolvido, os canais no escopo e a base de data.

Em seguida, registre o que o relatório não afirma. Deixar claro por escrito que o cumprimento do SLA e o tempo de primeira resposta nativo medem coisas diferentes evita que um colega bem-intencionado os cite como se fossem o mesmo número.

O limite é o de sempre. Documentar uma regra não a aplica na prática, e no próximo trimestre alguém reconstruirá a tabela dinâmica de cabeça.

Opção 3: Segmente antes de calcular a média

Divida por canal antes de calcular qualquer métrica de tempo. Tickets de e-mail, chat e telefone têm dinâmicas diferentes, e uma mediana unificada não descreve nenhum deles de verdade.

Em seguida, exclua ou sinalize os tickets que distorcem os dados. Tickets aguardando a resposta do cliente por semanas devem ficar em sua própria linha, e não dentro da média de resolução.

Mostre o que você excluiu e quantos eram. Um leitor que não consegue ver o filtro presumirá que ele não existia.

A limitação é que a segmentação multiplica o trabalho. Três canais vezes dois cronômetros vezes duas métricas de resolução resultam em doze números para gerenciar.

O limite compartilhado. Todas as três opções pressupõem que a exportação cubra um único intervalo de datas em uma única base de data para cada fila. Intervalos mistos entre abas é o erro silencioso mais comum neste relatório.

O onde o caminho manual desacelera

O primeiro relatório de tickets de suporte leva uma tarde. O quarto leva mais tempo, porque o help desk mudou nesse meio tempo.

Um novo canal é ativado, fazendo com que a mediana unificada mude por motivos não relacionados ao desempenho. O horário comercial é editado para uma nova região, e todos os dados históricos de horas úteis mudam junto.

Em seguida, surge o efeito de reabertura. Os números do trimestre passado não batem mais, e explicar o porquê leva mais tempo do que reconstruir o relatório.

Há um quarto custo que só aparece sob pressão. Alguém pergunta se o suporte ficou mais rápido neste trimestre. Uma resposta honesta exige que o cronômetro, a definição e o mix de canais sejam estabelecidos primeiro.

Para o lado da satisfação desse mesmo cenário, consulte nosso guia sobre como criar um relatório de NPS. Se o volume em si for o problema, nosso passo a passo sobre como criar um agente de IA para suporte ao cliente pré-vendas aborda o lado do desvio de chamados.

Como criá-lo com o Powerdrill Bloom

Passo 1: Faça o upload da sua exportação de tickets

Faça o upload da exportação de tickets, ou das exportações de tickets e SLA juntas. O Powerdrill Bloom analisa as colunas ao recebê-las, de modo que carimbos de data/hora em branco, formatos de data mistos e tickets sem uma primeira resposta aparecem antes que qualquer mediana seja calculada.

Passo 2: Descreva o relatório em linguagem natural

Declare as definições em vez de reconstruí-las. Nomeie a definição do tempo de resposta, o cronômetro, qual métrica de resolução você deseja, a regra de status para resolvido e os canais no escopo.

Em seguida, faça as perguntas que identificam os erros. Pergunte quantos tickets não têm nenhuma resposta de agente. Pergunte quais tickets foram reabertos. Peça medianas por canal em vez de um único número unificado.

Passo 3: Exporte o gráfico, relatório ou apresentação

Extraia a tabela de métricas por canal ou um gráfico de criados versus resolvidos com o backlog ao fundo. Slides que trazem as definições ao lado dos números são gerados na mesma execução.

Erros comuns

Citar o cumprimento de SLA como tempo de primeira resposta. Um aceita uma resposta automática e o outro exclui totalmente ações automatizadas.

Comparar horas corridas com horas úteis. O relatório padrão fornece a primeira opção, e sua meta provavelmente foi definida com base na segunda.

Usar a média para tempos de resposta e resolução. Alguns tickets abandonados movem a média para um patamar que nenhum ticket real ocupa.

Misturar canais. As medianas de chat e e-mail diferem por natureza, e a mistura oculta ambas.

Relatar o tempo de resolução sem dizer qual deles. O tempo de primeira resolução e o de resolução total são métricas armazenadas separadamente, não variações de arredondamento.

Tratar a contagem de resolvidos como definitiva. As contagens de resolvidos incluem apenas tickets atualmente resolvidos ou fechados, de modo que as reaberturas alteram o passado.

Deixar de fora os tickets sem resposta. Eles são definidos como tickets com menos de uma resposta de agente e representam a falha mais clara que o relatório pode evidenciar.

Conclusão

Nomeie a definição de resposta, nomeie o cronômetro, escolha a primeira resolução ou a total, defina a regra de status, segmente por canal e mostre os tickets reabertos e sem resposta. Isso produz um relatório de tickets de suporte sobre o qual alguém realmente pode agir.

O que o relatório talvez não faça é se comparar perfeitamente com os números de outra empresa. As definições são configuráveis, portanto, um benchmark que você leu em algum lugar quase certamente foi medido de forma diferente.

Em tempo, acompanhe-o em relação ao seu próprio histórico, sob um conjunto fixo de regras. Essa é a versão que realmente diz se algo melhorou de fato.

Se reconstruir isso todo mês consome um dia inteiro, experimente o Powerdrill Bloom na sua exportação de tickets. Veja também a página do gerador de relatórios de IA e o resumidor de voz do cliente.

Perguntas frequentes

Por que o meu cumprimento de SLA não corresponde ao meu tempo de primeira resposta?

Eles medem eventos diferentes. O tempo de primeira resposta do SLA do Zendesk pode ser cumprido por uma resposta automática, enquanto a métrica nativa de tempo de primeira resposta exclui totalmente ações automatizadas e de bots.

Devo relatar o tempo de primeira resolução ou o tempo de resolução total?

Relate aquele que você nomear. O tempo de primeira resolução termina na primeira vez que um ticket é definido como resolvido. O tempo de resolução total termina na última, de modo que os tickets reabertos separam os dois.

As métricas de suporte são medidas em horas corridas ou úteis?

Ambas são armazenadas. Os relatórios pré-criados do Explore do Zendesk exibem horas corridas, e as métricas de horas úteis estão disponíveis para relatórios que você mesmo criar.

Por que a contagem de resolvidos do trimestre passado mudou?

As contagens de resolvidos incluem tickets que estão atualmente resolvidos ou fechados. Um ticket reaberto após o término do período sai da contagem daquele período.

Posso comparar meu tempo de resolução com um benchmark do setor?

Apenas superficialmente. As definições, o cronômetro e o mix de canais são todos configuráveis, de modo que um número publicado provavelmente foi medido sob regras diferentes das suas.