Olá, tudo bem?

Sim, você faze com Registro de Eventos. No bloco seguinte ao bloco de atendimento humano (aquele configurado nas condições de saída do bloco de atendimento humano), faça um tratamento na variável input.content, nas ações de entrada. Ela irá te retornar todas as informações sobre o ticket, incluindo o ID único, o Id sequencial e o status (se foi fechado por atendente, usuário ou abandonado).

Você pode fazer um Registro de Eventos condicional, usando input.content@id caso input.content@status seja diferente de ClosedAttendant, por exemplo.

{


   "id":"5f5723bb-cd73-4c6b-8cf6-0172e688bb42",


   "sequentialId":2,


   "ownerIdentity":"[email protected]",


   "customerIdentity":"270mn.io",


   "customerDomain":"0mn.io",


   "agentIdentity":"someemail",


   "provider":"Lime",


   "status":"ClosedAttendant",


   "storageDate":"2020-06-24T13:33:40.030Z",


   "openDate":"2020-06-24T13:33:46.410Z",


   "closeDate":"2020-06-24T13:33:52.046Z",


   "statusDate":"2020-06-24T13:33:52.046Z",


   "externalId":"5f5723bb-cd73-4c6b-8cf6-0172e688bb42",


   "rating":0,


   "team":"Default",


   "unreadMessages":0,


   "closed":true,


   "closedBy":"someemail",


   "tags":r


      "#software"


   ]


}

Só pra garantir, você está ciente de essas métricas são exclusivamente geradas via API?

Um ticket só pode ser cancelado/fechado por um cliente através de uma requisição à API do BLiP, pois essa funcionalidade não está presente nativamente no Desk. Portanto, caso você não tenha feito ou permitido que seu cliente faça essa requisição, as métricas Perdidos e Abandonados ficarão zeradas nos relatórios.

Fonte: Descrição das métricas do BLiP Desk

Opa,

Maravilha, só surgiu uma dúvida aqui agora. Por exemplo, se o meu router e todos os meus bots tem um timeout de 10 horas, e um cliente entra no atendimento humano somente na nona hora, o serviço do bot vai ser reiniciado depois de uma hora ou depois de 10 horas no atendimento (total de 19 horas utilizando o serviço)?

Estou finalizando esses tickets pela API mas quero captar essas métricas.

Boa tarde, Bruno!

Não consegui entender sua explicação e como aplicar no sistema.


No bloco “Atendimento Humano” é para criar uma nova condição de saída (aba "condição de saída desse mesmo bloco)… ok. Mas tenho que colocar um “ir para”, mas para onde? Tenho que criar um novo bloco para fazer esse registro de evento?

O cenário é que eu preciso que o ticket gerado seja dado como abandonado se o cliente fechar a janela do navegador enquanto o mesmo aguardava para ser atendido, ou seja, o ticket ainda não foi associado (atendido) por um atendente. Ele ficou na fila aguardando e não foi atendido. Preciso disso para que entre nas métricas de abandono.

Entendi o texto " Um ticket só pode ser cancelado/fechado por um cliente através de uma requisição à API do BLiP, pois essa funcionalidade não está presente nativamente no Desk. Portanto, caso você não tenha feito ou permitido que seu cliente faça essa requisição, as métricas Perdidos e Abandonados ficarão zeradas nos relatórios.", mas ainda nao consegui ver como que habilita isso para que a métrica seja computada no sistema e assim nos relatórios.

Poderia me ajudar?


Obrigado!

É contado por tempo de inatividade, ou seja, 10 horas após a última mensagem enviada pelo usuário. Se ele retornar após 9 horas e 58 minutos, as 10 horas serão “resetadas”.

Não precisa criar um novo bloco, necessariamente, basta tratar as informações vindas na input.content nas ações de entrada do bloco seguinte ao atendimento humano.

Infelizmente é um pouco difícil determinar (mesmo via código) quando o navegador foi fechado, para que você tenha esse controle tão preciso. Imagino que você esteja usando o BLiP Chat. Para este caso, talvez seja melhor você criar uma TAG no atendimento, onde, quando o atendente envia uma mensagem e o usuário não responde, ele finaliza o ticket com essa TAG e você lança um registro de eventos baseado nisso.

Se você usar o BLiP Chat Widget pode ser mais fácil, pois dá pra controlar o trigger de quando a janela do bot foi fechada. Aí você fecharia (via API) o ticket do usuário.

Boa tarde, Bruno!

Entendi… o cenário ideal é que o sistema já fizesse isso. Existem N cenários que iria gerar um abandono. Internet caiu, computador desligou e etc. Imagino que se o sistema tivesse internamente tipo um timer em que faz um ping e espera a resposta (servidor com o blip chat widget) já seria possível o próprio sistema identificar que o usuário não está mais com o chat aberto e dar como abandono/perdido dependendo do status em que o chat está (se já foi atendido ou não pelo operador ou se está aguardando na fila de atendimento).

Usar uma tag (mas aí o operador já deu aceite no chat) também não é viável. Uma vez atendido foi atendido… e ficar a cargo do operador usar uma tag que faz o chat ficar como abandonado… não é bom.