Primeiro de tudo, hoje nós temos a possibilidade de fazer esse cálculo dentro do Cloud Chat. Dentro do Zendesk não executamos ajustes para visualizar esse dado, porém temos uma alternativa que alguns clientes utilizam e queremos compartilhar.

Existem 3 diferentes possibilidades com seus Pros e Cons

• Possibilidade 1: Cálculo utilizando a feature de "Políticas de SLA" de dentro do Zendesk

• Possibilidade 2: Cálculo do Timestamp de cada momento, utilizando Explore

• Possibilidade 3: Preencher campos customizados quando sai o atendimento e quando inicia o atendimento

A possibilidade 1 é a mais robusta, porém ela exige um plano Zendesk Professional ou Enterprise. O desafio é realizar as configurações de forma correta e criar relatórios personalizados a posteriori para analisar os dados.

A possibilidade 2 ela é mais complexa, mas também mais seamless. Ela envolve utilizar a tabela "Events" do Zendesk para capturar o Timestamp no quando troca o atendimento da Claudia para um humano (Ou último evento da Claudia em um ticket) e o Primeiro evento de um Agent dentro de um ticket. O desafio é cobrir todos os "corner cases" e utilizar muito bem da ferramenta Explore do Zendesk, que pode ser um pouco complexa.

A possibilidade 3 tem um custo a mais porque exige a contratação de uma ferramenta terceira para preencher o timestamp. Além disso, ela utiliza Endpoint de UPDATE Ticket no Zendesk, o que vai consumir do limitado Rate Limit existente do Zendesk.

Tanto a possibilidade 2 quanto a 3 existe um limitador quando é utilizado Chat. Os eventos são contabilizados de forma irregular o que pode impactar um pouco a coleta do dado de forma consistente e correta.

Como funciona a possibilidade 1

Você precisa configurar um gatilho para preencher com uma tag quando é realizado a transferência do atendimento.

Depois disso, é só configurar para a Política de SLA para iniciar a partir da inserção dessa tag ou da Alteração do Grupo da Claudia.

Com isso, você vai ter os resultados como "First Reply Time" somente a interação do usuário dentro do Explore.

Gatilho para colocar uma tag para preencher com "Atendimento não iniciado" e preencher com Timestamp

O objetivo desse gatilho é identificar quando o atendimento foi transferido para um Grupo ou Agente, iniciando o contador ao adicionar a tag (Que por sua vez, preenche o Campo Customizado). Exemplo do gatilho:

Como funciona a possibilidade 2

Primeiro você captura o Timestamp do evento que você quer.

Exemplo de como montar o Timestamp de troca de atribuído:

[TS Primeira resposta] Selecionar somente o TS de todas as respostas de Agentes

IF (

(

[Função do atualizador] = "Agent"

AND [E-mail do atualizador] != "[email protected]"

)

OR

(

[Função do atualizador] = NULL

AND [Comentário público] = TRUE

AND [E-mail do atualizador] != "[email protected]"

)

)

THEN [Atualização - Carimbo de data/hora]

ENDIF

[[Métrica] Timestamp da 1ª Resposta do Agente] Ajustar o timestamp a nível agente

DATE_FIRST_FIX([TS Primeira resposta], [ID do ticket da atualização])

Como funciona a possibilidade 3

Em resumo, nós utilizamos um Campo Customizado do tipo Número para preencher o Timestamp quando a IA realiza a transferência do atendimento com auxílio de um Gatilho

Nesse mesmo gatilho, colocamos uma tag e depois criamos outro para removê-la.

O gatilho de remoção precisa contar com um integrador No-Code ou outra ferramenta para ativar a ação somente quando a mensagem for de um agente.

Uma outra opção, caso não queira utilizar a integração No-Code, você pode somente colocar o gatilho de adicionar a Tag e alinhar o uso de uma Macro com os Agentes.

Gatilho para colocar uma tag para preencher com "Atendimento não iniciado" e preencher com Timestamp

O objetivo desse gatilho é identificar quando o atendimento foi transferido para um Grupo ou Agente, iniciando o contador ao adicionar a tag (Que por sua vez, preenche o Campo Customizado). Exemplo do gatilho:

Gatilho para remover a tag de que o atendimento foi iniciado

O objetivo desse gatilho é remover a tag de atendimento que por sua vez finaliza o contador. Exemplo de condições:

Esse segundo gatilho precisa utilizar um No-Code (ex., Make) para adicionar um filtro que hoje não existe, que é a identificação se a mensagem é proveniente de um Agente ou de um Cliente.

No nosso caso, precisamos ativar só se a mensagem for proveniente de um Agente. Exemplo de ação a ser executada com Webhook do Make e API configurados:

Exemplo de validação utilizando o Make para realizar o devido filtro:

Exemplo de configuração do request via API para o Zendesk:

Após isso você pode realizar as análises usando o Explore do Zendesk para conseguir mensurar o SLA depois do agente automatizado da Cloud Humans.