Tags no Zendesk: como montar relatórios e onde eles falham

Quem administra um Zendesk acaba, cedo ou tarde, montando relatórios com as tags do Zendesk no Explore. É o jeito mais barato de contar assunto: a tag já está no ticket, o Zendesk Explore já sabe ler, e em meia hora sai um gráfico de “tickets por motivo” para a reunião de segunda. Funciona bem até alguém perguntar por que o número de “cobranca_duplicada” caiu pela metade num mês em que o financeiro jura que o problema piorou.

Este texto é para esse dia: como as tags viram relatório e onde esse relatório engana. Uma parte é limite do produto. A maior parte vem de como a tag nasce.

Como as tags do Zendesk chegam ao relatório #

Tag digitada pelo agente, macro e gatilho todo mundo conhece. Os caminhos que confundem o relatório são outros.

O primeiro são os campos suspensos. Cada opção de um campo drop-down tem uma tag associada: escolher a opção grava a tag no ticket, e a tag presente seleciona a opção, segundo a própria Zendesk. Aquele campo “Motivo do contato” que o time preenche também aparece como tag. Isso tem um efeito colateral pouco comentado: o ticket de follow-up, aberto a partir de um ticket fechado, herda os campos e as tags do original. Se o cliente volta para falar de outra coisa e ninguém troca o campo, o assunto antigo ganha mais um ticket.

Depois vêm as tags de usuário e de organização. Com a opção de tags em usuários e organizações ativa, o Zendesk copia essas tags para os tickets daquele cliente. Se a conta de uma empresa tem a tag “vip”, todo ticket dela nasce com “vip”. Ajuda no roteamento e suja um relatório que deveria ser sobre assunto.

Há ainda a marcação automática, desligada por padrão, que compara a descrição dos tickets vindos de clientes com as tags já usadas e acrescenta as que batem. Ticket aberto por agente fica de fora. E o Explore não conta palavras, só ranqueia as tags que já existem.

O relatório básico e as fórmulas que salvam #

O ponto de partida é a contagem de tickets com “Ticket tags” nas linhas (Reporting with tags lista os outros atributos de tag).

Antes de olhar qualquer tag, acerte o denominador. Filtre tickets resolvidos e fechados, que não mudam mais de tag, separe por canal se chat e e-mail seguem processos diferentes e tire da conta o que nunca foi atendimento, como notificação automática e resposta de férias. Muito relatório de motivos poluído melhora só com isso.

Daí em diante, quase tudo passa por fórmulas:

• INCLUDES_ANY e INCLUDES_ALL contam tickets que têm uma entre várias tags, ou todas elas ao mesmo tempo.
• NOT INCLUDES_ANY é o caminho para excluir uma tag, porque o filtro do Explore não exclui tags.

Cuidado com o painel de filtros: selecionar várias tags ali multiplica os valores da métrica. Para olhar mais de uma tag, use a fórmula.

Macros como sensor #

O Explore não reporta uso de macro. A saída que a Zendesk sugere é fazer a macro adicionar uma tag quando é aplicada e contar essa tag (receita de macros com tags). Use, que funciona. Só lembre que ela mede o uso da macro, não o assunto do ticket. Se a macro “Segunda via de boleto” é aplicada em tudo que parece pagamento porque é a resposta mais rápida, o relatório vai mostrar muita segunda via de boleto.

Onde os relatórios com tags no Zendesk falham #

Há dois limites técnicos: a sincronização com o Explore pode levar até uma hora, e cada tag é guardada até 255 caracteres. Nenhum dos dois vai estragar sua reunião de segunda. O que estraga é outra coisa.

A soma das linhas não bate com o total #

Com “Ticket tags” nas linhas, o ticket aparece em cada linha de tag que carrega. Um ticket com “vip”, “cobranca_duplicada”, “macro_estorno” e “reaberto” está em quatro linhas, e quem soma a coluna para saber quanto cada motivo pesa está somando coisas que não se somam.

O contorno é um atributo calculado que escolhe um motivo só por ticket:

IF (INCLUDES_ANY([Ticket tags], "cobranca_duplicada", "estorno")) THEN "Cobrança"
ELIF (INCLUDES_ANY([Ticket tags], "entrega_atrasada")) THEN "Entrega"
ELSE "Sem motivo" ENDIF

A ordem dos IFs decide quem vence: um ticket com “estorno” e “entrega_atrasada” cai em Cobrança porque essa linha vem primeiro. A soma passa a fechar, mas a prioridade entre assuntos fica guardada numa fórmula que só uma pessoa abre. Escreva essa ordem onde o time leia.

Três tickets, um problema #

Pense no cliente que abre três tickets sobre a mesma cobrança duplicada. O primeiro cai com um agente novo, que marca “financeiro”. O segundo vai para alguém que usa a macro de estorno. O terceiro é fechado às 17h50 de sexta sem tag nenhuma. O relatório mostra três assuntos, ou dois, dependendo de como você montou a fórmula. O cliente teve um só.

Ninguém faz isso por preguiça. Classificar é a primeira tarefa que some quando a fila aperta, e cada pessoa aprende a marcar olhando o colega do lado. Tratamos disso com mais calma em por que as tags do helpdesk não bastam.

O passado não se corrige #

Renomear uma tag tem remédio. Se “prob_pagto” virou “problema_pagamento”, um atributo calculado com INCLUDES_ANY das duas costura a série e o gráfico nem percebe a troca.

Dividir é outra história. Quando o time decide que “problema_pagamento” era largo demais e cria “pix_falhou”, “boleto_nao_compensou” e “cartao_recusado”, não existe fórmula que redistribua o passado. A Zendesk permite remover uma tag em lote dos tickets que ainda não estão fechados, mas tickets fechados não podem ter tags apagadas. Janeiro fica com a tag larga para sempre, e a comparação com junho vira nota de rodapé no slide.

O assunto que ninguém previu #

As tags de assunto são uma lista que alguém escreveu antes de saber o que ia chegar. Quando surge uma mudança de regra de frete ou uma falha num meio de pagamento, o assunto novo entra no relatório como “outros” ou se espalha pelas tags vizinhas. Você só descobre lendo tickets, e aí a pergunta “desde quando isso acontece?” fica sem resposta no Explore.

O que fazer com o que você já tem #

As tags continuam úteis para a operação: roteamento, SLA por segmento, gatilho de pesquisa, marcação de VIP. Ali a regra é clara e gatilho resolve.

Para saber por que o cliente entra em contato, faríamos o seguinte antes de confiar no número.

Tire o assunto da tag livre. Crie um campo drop-down de motivo, marque como obrigatório para resolver o ticket e inclua uma opção “Outros” explícita. O agente continua escolhendo, só que numa lista fechada, e o ticket não fecha em branco. Como cada opção grava uma tag, os relatórios que você já montou seguem funcionando.

Todo mês, leia uma amostra de cada motivo grande, nem que sejam vinte tickets. Anote o motivo que você daria a cada um e compare com o que está marcado. Se discordar em mais de um a cada cinco, não leve aquela linha para a diretoria. O limiar é opinião nossa, sem estatística por trás.

E acompanhe o volume de “Outros” e de tickets sem motivo como um dos seus indicadores de atendimento. Se ele sobe, o relatório está enxergando menos, mesmo com os números parecendo estáveis.

Com isso o relatório fica honesto sobre o que enxerga. Mas continua dependendo de alguém marcar certo com três clientes esperando no chat.

Uma classificação que vem do conteúdo #

O Módulo Echo, da plataforma Kairos, parte do outro lado: do conteúdo da conversa. Ele se conecta ao Zendesk por OAuth, importa os atendimentos finalizados (mensagens, histórico de CSAT e campos personalizados) e descobre os tópicos a partir do que o cliente e o agente escreveram. Cada tópico chega como proposta, com volume e tickets de exemplo, e só passa a valer quando alguém do time aprova.

Um ticket pode ter vários tópicos, com um deles marcado como primário, então a conta de quanto cada assunto pesa não depende de uma fórmula montada à mão no relatório. Os tickets sem tópico alimentam propostas de tópicos novos, que o time aprova ou rejeita, e é por aí que o assunto imprevisto aparece.

As tags continuam no Zendesk, e o Echo não as converte em tópicos. O caminho da conexão à aprovação está em como funciona. E se o seu relatório de tags existe para responder o que mais gera contato, o post sobre motivos de contato trata dessa pergunta de frente.