Você pode programar relatórios do painel fora do Explore para entregá-los em PDF para a sua equipe. Ou você pode extrair os números manualmente mês a mês e colocá-los em uma planilha. Também é possível criar relatórios no Explore para esses mesmos números. O fato de esses métodos mostrarem resultados diferentes pode parecer confuso. Então, por que os números não estão batendo?
À medida que você investiga essas discrepâncias, o ponto-chave a ser lembrado é que os arquivos PDFs e as planilhas são estáticos, enquanto o Explore é dinâmico.
Este artigo contém os seguintes tópicos:
Motivos que levam à alteração nos resultados
Por exemplo, digamos que em 1 de agosto você exportou dados do mês inteiro de julho e os colocou em uma planilha. Em setembro, você roda outro relatório no Explore com os mesmos dados e ele mostra números diferentes para o mês de julho.
| Coluna de julho, exportação em agosto: | Coluna de julho, relatório no Explore em setembro: |
 |
 |
Leia os itens a seguir para obter respostas a estas perguntas:
Por que há divergência nos tickets criados?
Quando você apaga tickets, o número total de tickets criados pode diminuir.
Os tickets apagados são removidos do conjunto de dados Tickets. Então, se você marcar os tickets como spam ou apagá-los, esses tickets serão removidos da contagem geral. Consequentemente, há também uma alteração no número de tickets criados.
No exemplo anterior, o número de tickets criados caiu de 705 para 693. Isso sugere que 12 tickets foram apagados entre o período de exportação de dados em agosto e de execução do relatório no Explore em setembro.
Por outro lado, o número total de tickets criados pode subir se você está recuperando tickets apagados.
Para analisar a quantidade de tickets apagados e recuperados, use as métricas Exclusões e Recuperações no conjunto de dados Updates history.
Para as Exclusões, você não consegue ver os detalhes como a ID do ticket ou outros atributos (porque os tickets foram apagados), mas você consegue ver estas informações:
- Quando os tickets foram apagados, usando o atributo Atualização - Carimbo de data/hora
- Quem apagou os tickets, usando o atributo Nome do atualizador
Para as Recuperações, você consegue ver informações semelhantes sobre quando aconteceu e quem realizou a ação e também pode ver outros atributos do ticket, como a ID do ticket (porque o ticket voltou a existir).
Por que há divergência nos tickets resolvidos?
Normalmente, você analisa os tickets criados pelo atributo Criação do ticket - data e os resolvidos pelo atributo Resolução do ticket - data. No entanto, em algumas situações esses números podem oscilar com base em determinados eventos.
Quando você analisa os tickets resolvidos pela data da resolução, esses números são afetados pela métrica Reaberturas (disponível nos conjuntos de dados Tickets e Updates history). Esse número muda se os tickets forem reabertos entre o momento em que os dados são exportados e o momento em que o relatório é executado no Explore. Uma reabertura pode remover completamente um ticket dessa métrica (porque ele não está mais resolvido) ou movê-lo de um período para outro (se a última resolução estiver em um período diferente do primeiro).
Quando você analisa os tickets resolvidos pela data da criação, esses números são afetados pelas resoluções ao longo do tempo. Se dez tickets foram criados na segunda-feira e dois resolvidos no mesmo dia, a exportação exibirá dois tickets resolvidos para a segunda-feira. Se outros três forem resolvidos na terça-feira, o relatório e a próxima exportação mostrarão que cinco tickets resolvidos foram criados na segunda-feira.
A métrica Tickets resolvidos no conjunto de dados Updates history vê apenas a última resolução dos tickets resolvidos atualmente. Para ver isso, analise a fórmula da métrica, especificamente estas duas condições destacadas em negrito:
IF ([Changes - Field name]="status"
AND [Changes - Previous value]!="solved"
AND ([Changes - New value]="solved" OR [Changes - New value]="closed")
AND ([Ticket status - Unsorted] = "Solved" OR [Ticket status - Unsorted] = "Closed")
AND [Update - Timestamp]=[Ticket solved - Timestamp])
THEN [Update ID]
ENDIF
Se você deseja monitorar todas as resoluções, é possível criar uma métrica calculada padrão que elimina essas duas condições para o status e a data atuais, gerando a fórmula a seguir:
IF ([Changes - Field name]="status"
AND [Changes - Previous value]!="solved"
AND ([Changes - New value]="solved" OR [Changes - New value]="closed"))
THEN [Update ID]
ENDIF
Por que há divergência nos tickets em uma determinada categoria?
O conjunto de dados Tickets analisa o estado atual dos tickets, incluindo status, grupo, atribuído, prioridade, campos personalizados e muito mais. Isso significa que, se um campo for alterado entre o momento em que os dados são exportados e o momento em que você executa um relatório no Explore, é provável que os resultados sofram alterações.
Nas capturas de tela do exemplo anterior, observe que a exportação de agosto mostra dez blips e 61 bugs. Contudo, no relatório de setembro, o Explore mostra dois blips e 69 bugs. Isso indica que oito tickets mudaram de categoria, de blip para bug, entre o momento da exportação e a execução do relatório.
Esse tipo de mudança também pode alterar os filtros do relatório. Por exemplo, digamos que você tenha um relatório filtrado para mostrar apenas os tickets do Grupo A. Se um ticket for movido do Grupo A para outro grupo entre o momento da exportação e do relatório, esse ticket não aparecerá mais no relatório.
O inverso também acontece para tickets que foram originalmente atribuídos para o Grupo B e depois reatribuídos para o Grupo A. Por causa do filtro, mais tickets aparecerão no relatório do que antes.
Atenção aos números
Ao analisar as discrepâncias entre os relatórios do Explore e as exportações, fique atento aos números reais. Considere o seguinte:
- Se um resultado muda de 20 tickets para 21, o aumento é de 1. Isso pode parecer uma variação pequena. Contudo, esse número representa uma mudança de 5%.
- Se outro resultado muda de 1998 para 2100, a diferença é de 102. Isso pode parecer uma variação significativa. Contudo, esse número também representa uma mudança de 5%.
Quando o assunto é variância, analise a porcentagem e o número bruto. Isso pode ajudá-lo a discernir o que é material ou não.
Pense em quantos agentes você tem. Se você tem 200 agentes e um resultado de mudança a 102, isso indica que aproximadamente metade de seus agentes, em média, alterou esse campo em um ticket entre o momento da exportação dos dados e da execução do relatório no Explore.
Lembre-se de que você pode analisar esses resultados no conjunto de dados Updates history. Use o atributo Nome do atualizador para filtrar um relatório mostrando o atributo relevante [Alterações - nome do campo] e o resultado anterior ou o novo que você não entendeu.
É comum ver uma ampla distribuição de alterações, por exemplo, 100 agentes fazendo aproximadamente uma alteração de campo no período.
No entanto, pode haver um ou dois agentes alterando os resultados de campo com mais frequência. Talvez eles sejam gerentes organizando os membros da equipe deles. Ou talvez eles sejam novos e não tenham entendido inicialmente como aplicar o campo, nesse caso, sugerimos que eles passem por mais treinamento.
Uso de agregadores corretos
Por fim, ao analisar as durações, é sempre bom ter em mente "a quantidade versus a qualidade".
Por padrão, o Explore usa o agregador da mediana (MED) para métricas como tempo da primeira resposta e tempo de resolução. No entanto, você pode ter alguns atribuídos ou grupos que lidam com uma quantidade muito pequena de tickets e de uma maneira muito diferente de seus agentes habituais. Talvez eles sejam da equipe do financeiro ou de segurança que não recebem tickets com muita frequência e que não têm as mesmas expectativas de tempos de resposta.
O uso do agregador MED nas métricas de duração ajudará você a se proteger desses valores atípicos. Se você usar o agregador de média (AVG), essa proteção será reduzida. Por exemplo, digamos que a equipe do financeiro esteja trabalhando no ticket de um cliente por seis meses enquanto o resto da equipe está resolvendo tickets rotineiros em uma semana. O valor atípico da equipe do financeiro afeta de forma significativa sua idade dos tickets não resolvidos, principalmente se você estiver usando o agregador AVG.
Quando a equipe financeira realmente resolver esse ticket, o tempo de resolução referente ao período também poderá ser afetado de forma significativa, de novo, principalmente se você estiver usando o AVG.
Conclusão
Os números que mudam com o decorrer do tempo podem parecer algo confuso. Sabemos isso. Principalmente, se a solicitação desses números partiu do seu chefe. No entanto, há muitas variáveis que justificam as alterações.
Se você está preocupado, observe os problemas levantados anteriormente e pense de que forma eles podem afetar a situação. Se ainda está com dúvidas, consulte a documentação do Explore ou a comunidade para obter ajuda ou entre em contato com o Suporte ao cliente Zendesk.