Como criar blocos no Builder

Um fluxo de conversa no Builder é composto por diversos blocos, que representam o estado atual de um cliente durante a sua interação com o bot. Existem três tipos de blocos. Veja quais são eles!

1. Blocos de Controle (Início e Exceção)

Os blocos de controle representam estados específicos no fluxo de conversa de um bot. Os dois blocos de controle marcam o Início da conversa entre o cliente e o bot (antes da primeira interação) e qualquer Exceção (ou problema) não tratada pelo fluxo, respectivamente.

Início

A conversa do seu bot sempre começa através de uma entrada do usuário. Por isso, o único conteúdo existente no bloco de controle Início é uma Entrada de usuário. Apesar de não ser possível alterar nenhum conteúdo neste bloco, as condições de saída e ações podem ser totalmente customizadas.

Exceção

Qualquer condição não tratada, em qualquer ponto da conversa do bot, redireciona o usuário para o bloco Exceção. Qualquer informação de conteúdo, condições de saída e ações podem ser customizadas neste bloco.

Todo novo bloco do Builder possui uma condição de saída padrão, previamente configurada, para o bloco Exceção. Apesar disso, é possível modificar esse comportamento conforme a necessidade do usuário.

Algumas considerações importantes:

• Os blocos de controle não podem ser renomeados ou deletados;
• É possível referenciar os blocos de controle em qualquer outro bloco de forma transparente.

2. Blocos de Conteúdo

Além de representar os possíveis estados de um cliente no fluxo da conversa os blocos de conteúdo são responsáveis por outras três funções: envio (e recebimento) de conteúdos, escolha de condições de saída e a execução de ações.

Conteúdo

Sempre que um usuário alcança um determinado estado (um bloco), todo o conteúdo disponível nele é enviado para o cliente. Esses conteúdos representam os cards suportados nos principais aplicativos de mensagem do mercado.

Além dos tradicionais conteúdos estáticos — texto, digitando, imagem, áudio, menu, carrousel e quick reply, por exemplo — existem outros dois tipos de conteúdos especiais:

Conteúdo HTTP

Em algumas situações específicas, pode ser necessário enviar um conteúdo que varia de acordo com uma ou mais condições. Imagine, por exemplo, que o bot de um e-commerce precisa enviar um carrousel com todas as opções de produto de uma determinada categoria. Para construir o carrousel, é necessário analisar várias informações, como quais produtos estão disponíveis, seu preço e a quantidade disponível em estoque. Somente após essa análise é possível montar e enviar o conteúdo para um usuário.

Pensando nisso, o Builder criou o Conteúdo HTTP. Através dele, é possível definir o endpoint de uma aplicação responsável por construir o conteúdo de acordo com as regras específicas de cada bot.

O único compromisso da aplicação responsável por construir o conteúdo é retornar um objeto JSON referente ao tipo escolhido de acordo com a especificação definida na documentação do BliP.

*Atualmente, é possível criar Menus, Quick Replies e Carrousel através do Conteúdo HTTP.

Entrada do usuário

Além de enviar conteúdos, o bot pode precisar solicitar alguma entrada de dados para o usuário. Para isso, existe o conteúdo Entrada do usuário, com o qual é possível parar a execução da máquina de estados e aguardar por alguma informação que deverá ser enviada pelo cliente. É através da Entrada do usuário que todas as mensagens enviadas pelos clientes são recebidas pelo bot.

Observações:

• um bloco pode conter 0 (zero) ou 1 (uma) Entrada do usuário;
• caso um bloco não possua Entrada do usuário, o processamento da máquina de estados levará o cliente para o bloco que contenha.

Condições de Saída

Para que seja possível condicionar a mudança de estado do usuário, o Builder disponibiliza o recurso de condição de saída. Através dessa funcionalidade, é possível definir regras para a transição entre os blocos.

Essas regras podem levar em consideração: o valor de variáveis, a entrada de dados feita pelos clientes, além de intenções e entidades analisadas no modelo de IA do bot. Para cada regra, deve ser definido um bloco alvo para o qual o usuário será enviado caso a condição seja satisfeita.

Observações:

• as condições de saída de um bloco do Builder são processadas sequencialmente (uma após a outra) até que uma condição verdadeira seja alcançada. Ou seja, é preciso cadastrar as condições ordenadas a partir das mais específicas até a mais genérica;
• por padrão, todo bloco possui uma condição de saída padrão (Fallback) pré-configurada. Apesar de ser possível alterar a saída padrão de qualquer bloco, não é possível removê-la.

Ações

A terceira e última função de um bloco é executar ações de entrada e saída. Uma ação representa uma tarefa que deve ser executada antes do envio dos conteúdos de um bloco (ação de entrada), ou uma tarefa que deve ser executada após o envio dos conteúdos e antes da transição entre o estado atual e o próximo (ação de saída).

As ações representam o principal ponto de flexibilidade do Builder do BLiP. Através de uma ação, é possível utilizar qualquer funcionalidade do BLiP — como as diversas extensões da plataforma, por exemplo ( — além de realizar requisições para qualquer API pública na web.

Observações:

• as ações do Builder são processadas sequencialmente (uma após a outra) até que todas sejam executadas;
• ações inválidas, como uma requisição HTTP inválida, podem bloquear a execução do fluxo de conversa de um usuário. Fique atento quando cadastrar uma ação em seu bloco.

3. Blocos de atendimento

Um bloco de atendimento representa o estado em que um usuário deixa de ser atendido pelo bot e passa a ser atendido por um atendente humano. Assim, cada bloco de atendimento no fluxo do bot representa um ponto em que os clientes são transbordados para o atendimento humano.

Assim como nos blocos de conteúdo, a tela de edição dos blocos de atendimento também possui três abas: Conteúdo, Condições de saída e Ações.

Entretanto, apenas a seção de Condições de saída pode ser editada nesse bloco. Através dela, é possível configurar a mudança de estado do cliente, durante a finalização do atendimento. Assim, o usuário que tem seu atendimento humano finalizado é redirecionado para um novo estado.