Olá pessoal!! Como vocês estão?
To passando por aqui para passar algumas dicas que irão auxiliar na construção de um contato inteligente que tenha um atendimento personalizado pelo blip!
Aqui vamos falar sobre a estrutura roteadora, mas também teremos dicas valiosas para a construção de um único bot que já possua o atendimento.
Por isso, se você ainda não sabe como funciona e o que é um roteador, confira esse super material que o @BrunoC fez.
Com isso, vamos imaginar um cenário:
Temos um roteador e dois bot’s builder (um para receber o usuário e outro para realizar o atendimento)
Esse roteador terá ambos os builders como serviços
Nosso atendimento deverá possuir diferentes filas que serão definidas a partir do fluxo que o usuário seguiu
Com isso, lembre-se que as configurações referentes ao atendimento devem ser feitas no bot builder que será realizado o atendimento. No nosso caso, o bot Bia - [Human Service] que é nosso bot de atendimento e por isso é a partir dele que devemos acessar a aba de Atendimento do portal.
Nossa estrutura ficou assim:
Ao construir um contato inteligente que possua essa estrutura, muitas vezes nos deparamos com alguns problemas que vou tentar esclarecer por aqui:
1°) O usuário não é encaminhado para a fila correta e estou utilizando informações do contato:
Considerando que o extras ou o campo do contato seja atualizado corretamente, certifique-se que sempre antes de realizar o atendimento você atualize o campo avaliado para o contato do serviço de atendimento. Muitas vezes, o que ocorre é que o usuário no router possui o campo atualizado e no bot de atendimento não…
Para ficar mais claro, quando um usuário está interagindo com um contato na estrutura roteadora, cada bot irá possuir o seu respectivo contato dentro do blip, isso porque o contato é uma representação única daquele usuário no contexto específico daquele bot.
O caso abaixo evidencia o problema, mostrando que o contato no router possui o extras Time e o contato no bot de atendimento não.
Router:
Bot de atendimento:
Quando isso acontece, possivelmente você está utilizando o comando MergeContact em nome do router e não do bot de atendimento. No caso, eu fiz esse exemplo utilizando o próprio comando do blip, com o contexto do roteador ativo (fazendo com que as ações do bot sejam em nome do router).
2°) O usuário é encaminhado corretamente apenas no primeiro atendimento:
Normalmente a causa raiz desse cenário é a mesma do anterior, mas como o primeiro atendimento do usuário funciona é mais difícil diagnosticar.
Como funciona o processo de criação dos contatos? À medida que o usuário interage com o bot, apenas na sua primeira mensagem com o serviço irá criar um um contato no blip e os contatos dos serviços são criados com base no contato do router em caso do contexto de router ativo.
3°) Quero segmentar o atendimento por canal:
Caso seja do seu interesse, ter filas de atendimento diferenciadas pelo canal que o usuário está se comunicando, considere utilizar uma variável imutável para identificar este canal.
Para isso, considere utilizar o identity do usuário principal (atrelado ao router), que no caso de um bot com contexto do roteador ativo, irá corresponder ao contact.identity.
Esse campo do usuário é o seu identificador dentro do contato inteligente que se comunica com o canal trabalhado e por isso não é alterado e sempre terá a informação do canal que o usuário está comunicando. Um ponto negativo é que esse campo não é muito intuitivo, visto que é necessário analisar o domínio que o identity está atrelado.
Ex.:
Ao iniciar uma conversa pelo router, temos o nosso contato atrelado ao canal criado corretamente e é possível visualizar pelos logs do nosso bot ou pela própria aba de contatos.
Ao entrar no contato, conseguimos o seu identity pela url:
É possível perceber que o contato criado [email protected], é do domínio 0mn.io, que se refere ao canal Blipchat. No caso de outros canais, teremos outros domínios, como por exemplo, o canal Whatsapp possui o domínio wa.gw.msging.net.
Com isso, seria possível utilizar um script que diz qual o canal que o usuário se encontra:
const run = (contactIdentity) => {
const contactDomain = contactIdentity.split("@")[1];
switch (contactDomain) {
case "wa.gw.msging.net":
return "Whatsapp";
case "0mn.io":
return "Blipchat";
default:
return "Other";
}
}
Lembrando que esse script recebe contact.identity como variável de entrada.
Sobre o campo source
- Algumas pessoas consideram utilizar o campo source para trabalhar a interação do contato com base no canal que o usuário está comunicando. Esse campo, ajuda muito nesse propósito, porém, caso você utilize alguma ferramenta externa que manipule os dados dos contatos, você pode acidentalmente deletar esse campo e ele não será mais setado, visto que sua criação, até a data deste guia, ocorre somente na primeira interação do usuário.
Sobre o tunnel
- O tunnel permite o roteamento de mensagens entre diferentes bots do blip e quando criados a partir de um único canal de comunicação, são criados a partir do estado do identificador de origem criado na primeira interação do contato com o canal (quando compartilhado o contexto), que é o
contact.identityoutunnel.originator. Dica: é possível descobrir o identificador do usuário dado um router, utilizando o comando tunnel info.
Esse comando utiliza como Authorization a chave do bot router que você sabe que o contato interagiu e o tunnel trabalhado:
{
"id": "{{$guid}}",
"to": "[email protected]",
"method": "get",
"uri": "/tunnels/{{guid}}@tunnel.msging.net"
}
Essas eram as dicas que eu tinha para hoje 🤗
Muito obrigado por fazer parte da comunidade! Se você estiver com dúvida em como utilizar o blip, tenha certeza que aqui é o lugar para compartilharmos conhecimento a respeito da plataforma!
Até a próxima!
