Zendesk: exemplo de trigger

Tickets assignados sem resposta do próprio assignado

Mandaram-me recentemente uma questão de Zendesk que tem a ver com Vistas e tickets já assignados a um Agente mas que ainda não têm comentários do mesmo. Vou apresentar duas soluções: uma complexa e uma simples, cada uma com as suas vantagens e desvantagens.

Descrição do problema:

Estou à procura de uma forma de ver que tickets estão assigned sem resposta alguma do assignee actual.

Ou seja: preciso de ver na pool de cada agente qual é o ticket assigned sem qualquer resposta desse mesmo agente, idealmente numa situação em que foi o agente a pegar nesse ticket ou se foi outro agente que pegou, respondeu e depois escalou para outro agente. Não consigo encontrar uma fórmula de search, já criei views com a coluna “latest update by assignee” mas esta última mesmo assim não me mostra tickets assigned sem resposta

Ou seja, como Agente de suporte, quero uma Vista/View onde aparecem todos os tickets assignados a mim mas onde ainda não dei resposta (i.e. actualizei com um comentário público).

Embora ainda não haja uma funcionalidade imediata ou eficaz de conseguir isto nas Views, há formas de conseguir algo bastante próximo (como sempre, vai depender do modelo de assignação e distribuição de tickets de cada operação de suporte).

Para este processo estarei a assumir que estamos a falar de uma View com a condição “Assignee is current user”.

Solução 1: eficaz mas difícil de escalar

Ideal para quem tenha poucos agentes e/ou não se importe de ter de criar Vistas específicas sempre que adiciona um agente à conta de Zendesk.

⚠️ Atenção: esta solução consome recursos da API da nossa conta de Zendesk (ver aqui e na documentação).

Nesta solução vamos adicionar automaticamente uma tag (etiqueta) específica ao ticket: o user ID do agente actual que deixa um comentário público. Ou seja, se o agente com user ID 123456789 deixar um comentário público num ticket, adiciona-se uma tag do estilo updated_by_user-123456789.

A solução é difícil de escalar porque teremos de criar uma Vista específica para cada agente, isto é, incluir em cada Vista a condição correspondente ao agente ao qual a mesma se destina: Tags include updated_by_user-[ID].

  1. Primeiro, criamos um webhook que adiciona tags e que chama o endpoint …/api/v2/tickets/{{ticket.id}}/tags.json.
  2. Depois, criamos o nosso trigger para executar-se quando um ticket é actualizado e o utilizador actual é um agente. Nas Acções do trigger notificamos o webhook que criámos de modo a adicionar a etiqueta “updated_by_user-{{current_user.id}}” (por exemplo). Assim, sempre que eu adicione um comentário público a um ticket, adicionar-se-á uma tag com o meu user ID. Consequentemente, todos os tickets assignados a mim e que não tenham essa tag são tickets onde ainda não enviei mensagens ao Solicitante.
  3. Para cada agente criamos uma Vista com a condição Tags contain none of the following: updated_by_user-[ID], onde em “ID” adicionamos o ID do agente em questão.

Solução 2: fácil de manter mas genérica

Ideal para quem tenha muitos agentes e/ou não queira andar a criar Vistas específicas sempre que adiciona um agente à conta de Zendesk.

Esta solução é vaga e pode ser ineficiente: tal como a solução anterior, vamos adicionar uma tag e só utilizaremos uma Vista para todos os agentes. No entanto, a tag será genérica, pelo que Vista é vaga e poderá mostrar-me, agente assignado actual, tickets já comentados por outro agente.

A solução passa por criar um trigger que adiciona uma tag sempre que um agente adiciona um comentário público. Uma vantagem é que para este trigger não precisamos de webhooks nem de recorrer à API. Segue exemplo.

Condições (“ALL”) do trigger:

Exemplo de condições de um trigger de Zendesk
Condições “ALL” do trigger

Acções do trigger:

Exemplo de acções de um trigger de Zendesk
Acção do trigger

Ou seja, um ticket que contenha a tag zd_handled vai ter pelo menos um comentário público de um agente… atenção porque pode ser qualquer agente (na prática, o primeiro a adicionar um comentário público).

Continuando, agora podemos criar a nossa Vista com as condições:

  • Assignado é o utilizador actual
  • Etiquetas não contêm zd_handled

⚠️ Problema (sobretudo se o modelo operacional permite que vários agentes participem no mesmo ticket): a Vista não me mostrará tickets assignados a mim mas que outros agentes comentaram. Por isso considero a solução ineficiente, embora fácil de escalar.

Conclusão

Nunca existe uma solução certa, apenas uma forma de fazer as coisas que pode ou não ser melhor que outra(s).

Pessoalmente, neste caso iria rever e provavelmente reestruturar o modelo operacional (incluindo Vistas de agentes) em vez de configurar tanta granularidade e preocupar-me com o facto do Assignado actual ter comentado ou não… sobretudo porque podemos criar automatizações para alertar atrasos de resposta.

Espero ter ajudado! Obrigado por lerem e continuação de bom trabalho.

Deixe um comentário

O seu endereço de email não será publicado. Campos obrigatórios marcados com *