Autorefresh dos atendimentos no BliP Desk

Olá @Bruno_Gabriel

Acredito que para essa implementação você tenha usando um serviço (endpoint) da API do Blip abaixo:

• Assign a ticket to an agent

👉 Há cerca de um mês (+/-), conversei sobre esse cenário com o time que cuida do Desk e existe um motivo para tal: quando fazendo o uso deste serviço, ao atribuir o tíquete diretamente ao atendente, é similar a ideia de que está ocorrendo “diretamente” no banco de dados. Porém, hoje isso não reflete no front-end do Desk, sendo necessário atualizar (F5) a página. Isso leva a outra situação: ao atualizar, o atendente volta no estado de offline e necessita ficar online novamente.

💭 Esse cenário acima ocorreu, porque o cliente que estava em implementação precisava de um comportamento similar, mas esbarramos neste cenário. Assim, as soluções de contorno identificadas naquela época foram:

• utilizar o serviço acima e, quando ocorre de ser aberto um tíquete desta forma, o serviço do lado cliente alertava, a partir do envio de um e-mail usando a ideia do artigo no Help Center - Como enviar e-mail pelo bot através do Builder - e também disponível na doc. da API (Send e-mail). Assim, quando chegava o e-mail, isso ajudava o atendente a saber que um novo tíquete foi criado e que seria necessário, ainda, atualizar a página + ficar online novamente

• outro caminho, porém considerado um pouco mais custoso pelo tamanho da operação do cliente, foi criar filas de atendimento no módulo de Atendimento > Gerenciamento de filas no chatbot onde está o bloco (estado) de Atendimento Humano. Uma fila para cada atendente, onde as regras correspondiam, respectivamente, ao e-mail do agente (como no exemplo abaixo). Assim, ao transbordar para o atendente, dispensava-se a necessidade de atualizar a página, porém o custo assumido era gerenciar as filas quando da entrada ou saída de um atendente, seja através do Portal ou usando os serviços da API do Blip para (1) adicionar um agente, (2) criar uma nova regras de atendimento e, ao contrário, (3) deletar um atendente e (4) deletar uma regra
  

  

🚩 Do meu lado, particularmente, eu ainda prefiro seguir com a primeira solução de contorno por ter um custo menor, apesar de não ser uma solução redonda, com duas ações manuais. Talvez outras pessoas da comunidade tenham outros caminhos que podem ser ainda melhores do que os dois pontos apresentados acima.

Romulo, tudo bem?

Acho que vou adicionar somente o alerta via e-mail mesmo. Eu acabei fazendo essa solução por que não queria criar um fila para cada atendente, além do mais quebra com minhas métricas de setor via NPS.

Pena que acaba não tendo como atualizar o front junto com o back.