Fulfillments

No turno de conversas do agente, ele precisa responder ao usuário final com uma resposta a uma pergunta, uma consulta de informações ou o encerramento da sessão. O agente também pode precisar entrar em contato com seu serviço para gerar respostas dinâmicas ou realizar ações por uma volta. O fulfillment é usado para fazer tudo isso.

Um fulfillment pode conter:

• Mensagens de resposta estática.
• Chamadas de webhook para respostas dinâmicas e/ou para realizar ações.
• Predefinições de parâmetros para definir ou substituir valores de parâmetros.

Durante a rodada de um agente, é possível (e às vezes desejável) chamar vários fulfillments, e cada um deles pode gerar uma mensagem de resposta. O Dialogflow mantém essas respostas em uma fila de respostas. Depois que a rodada do agente terminar, o Dialogflow enviará as respostas ordenadas ao usuário final.

O fulfillment de ES é limitado à conexão de um serviço de webhook. O escopo do fulfillment foi aumentado para o CX. Por isso, ele agora abrange todos os tipos de prompts e respostas.

Casos de uso de fulfillment

O fulfillment é usado em qualquer lugar em que uma mensagem de resposta é necessária:

• Fulfillment de entrada de página
• Rotas
• Manipuladores de eventos
• Solicitações iniciais para formulários
• Gerenciadores de prompts para formulários

Para cada um desses casos de uso, o console abrirá um painel de edição de fulfillment.

Mensagens de resposta estática (opções de diálogo)

As mensagens de resposta estática são respostas do agente que você define no momento do projeto. Você as define ao criar o fulfillment. No ambiente de execução, essas respostas são adicionadas à fila de respostas.

Há vários tipos de mensagens de resposta, que são descritos nas subseções a seguir. Ao usar o console, um painel de fulfillment tem um cartão inicial de mensagem de resposta de texto, mas é possível clicar em Adicionar opção de caixa de diálogo para adicionar mais cartões para outros tipos de mensagens de resposta.

Texto

As mensagens de resposta de texto enviam a caixa de diálogo para o usuário final. Se as chamadas de API de intent de detecção ou de integração usarem a síntese de fala, esse texto será usado para gerar conteúdo de áudio. Nesse caso, o texto fornecido pode usar a Linguagem de marcação de sintetização de voz (SSML, na sigla em inglês).

É possível definir vários cartões de resposta de texto e várias respostas de texto dentro de cada cartão. Se você definir vários cartões, eles serão concatenados para uma única resposta no ambiente de execução. Se você definir várias respostas dentro de um cartão, uma das mensagens no cartão será escolhida aleatoriamente no tempo de execução.

Essas mensagens de texto podem conter referências de parâmetro e funções do sistema in-line.

Payload personalizado

Algumas integrações são compatíveis com uma resposta de payload personalizada para lidar com respostas avançadas. Esses payloads personalizados são fornecidos em um formato JSON definido na documentação de integração. Por exemplo, consulte o formato de payload personalizado do Dialogflow Messenger.

É possível incluir referências de parâmetros no seu JSON de payload personalizado. Eles precisam ser tratados como valores de string JSON. Portanto, coloque-os entre aspas duplas. Exemplo:

{
  "someField": "$session.params.date"
}

Também é possível enviar um payload personalizado para as integrações que você desenvolve. Por não ser processado pelo Dialogflow, ele precisará ser manipulado na sua própria lógica de negócios.

Consulte também a seção modelos de payload personalizados abaixo.

Transferência de agente ao vivo

Essa resposta sinaliza ao autor da chamada da API de intent de detecção que a conversa precisa ser enviada a um agente humano. O Dialogflow só usa esse sinal para identificar conversas entregues para fins de medição, sem alterar o estado da sessão. Seu sistema ou integração pode usar esse sinal para executar as ações necessárias para entregar a conversa. O Dialogflow não impõe nenhuma estrutura nesses dados. Assim, é possível escolher qualquer estrutura que se encaixe no seu sistema.

Metadados de conversação bem-sucedida

Essa resposta sinaliza ao autor da chamada da API de intent de detecção que a conversa com o agente do Dialogflow foi bem-sucedida. O Dialogflow usa esse sinal apenas para identificar conversas que foram bem-sucedidas para fins de medição e não muda o estado da sessão de forma alguma. O sistema ou a integração pode usar esse sinal para realizar as ações necessárias. O Dialogflow não impõe nenhuma estrutura nesses dados. Assim, é possível escolher qualquer estrutura que se encaixe no seu sistema.

Ouvir áudio pré-gravado

Essa resposta reproduz um arquivo de áudio para integrações compatíveis com esse recurso.

Os requisitos de formato do arquivo de áudio podem variar de acordo com a integração. Por exemplo, consulte os requisitos para o gateway de telefone do Dialogflow CX.

Para integrações de telefonia de parceiros, o URL do arquivo de áudio precisa ser acessível pelo parceiro. Um URL disponível publicamente, como um arquivo público no Cloud Storage, está sempre acessível pelo parceiro. O parceiro também pode conceder acesso restrito aos arquivos de áudio. Consulte a documentação do parceiro para mais detalhes.

Texto de saída de áudio

Essa resposta é semelhante à resposta de texto, mas só é aplicável à síntese de fala. Se o agente processar sessões de texto e voz, use respostas de texto e texto de áudio exclusivos para criar uma experiência do usuário diferente no texto. Voz. Se o texto de saída de áudio for fornecido para uma sessão de voz, as respostas de texto simples serão ignoradas.

Se o agente processar sessões de texto e voz, e você quiser as mesmas mensagens de resposta, basta usar respostas de texto para sessões de texto e de voz.

O texto de áudio de saída é concatenado de forma semelhante às respostas de texto. Se as respostas de texto de áudio de saída forem uma mistura de texto e SSML, o resultado concatenado será tratado como SSML. O ideal é que o designer do agente use texto ou SSML de maneira consistente.

Resposta condicional

Esse tipo de resposta é usado para respostas condicionais. Este é o formato geral:

if [condition]
  [response]
elif [condition]
  [response]
elif [condition]
  [response]
else
  [response]
endif

onde:

• [condition] é o mesmo formato usado para condições de rota.
• [response] é uma resposta de texto.
• Os blocos elif e else são opcionais

Exemplo:

if $session.params.user-age >= 21
  Ok, you may enter.
else
  Sorry, you cannot enter.
endif

Tanto [condition] quanto [response] podem usar funções in-line do sistema para gerar valores dinâmicos durante as conversas. Para saber mais, verifique as referências de funções do sistema e condições de rota.

Para agentes multilíngues, [condition] é comum para todos os idiomas, enquanto [response] é específico de um idioma. Quando você altera [condition] para um idioma no console, essa parte é atualizada em todos os idiomas do agente e, que se torna uma nova condição, [response] é apagado para todos os idiomas diferente do idioma selecionado ao atualizar o [condition].

Chamada de transferência de telefonia

Observação: no momento, a transferência de chamadas está disponível apenas para o Dialogflow Phone Gateway.

Para algumas integrações de telefonia, é possível especificar um número de telefone dos EUA para transferência de chamadas. No ambiente de execução, quando o agente virtual do Dialogflow chama um fulfillment com a transferência de chamada, a chamada é transferida para o número especificado, e o processamento do agente virtual é suspenso.

Mensagens de resposta específicas do canal

Ao definir o fulfillment, é possível criar mensagens de resposta específicas do canal. Assim, você pode criar respostas segmentadas para chat por texto, voz, SMS, integrações específicas compatíveis com canais, entre outros. Todas as mensagens de resposta que não são específicas de um canal são chamadas de mensagens de resposta padrão.

No momento da execução, o Dialogflow vai selecionar a mensagem de resposta padrão ou uma mensagem de resposta específica do canal quando uma solicitação de detecção de intent especificar um canal. Como prática recomendada, você precisa definir mensagens de resposta padrão, mesmo que esteja usando mensagens de resposta específicas do canal. As mensagens de resposta padrão podem atuar como substitutas quando o sistema não fornece um canal válido.

O nome do canal é um campo personalizado que pode ser definido para qualquer texto. Se você estiver usando a API Dialogflow diretamente para chamadas de ambiente de execução, poderá usar qualquer nome de canal que quiser. Se estiver usando uma integração atual, use os nomes dos canais que a integração reconhece.

Definir mensagens de resposta específicas do canal no momento do design

Para fornecer mensagens de resposta específicas do canal para fulfillment ao usar o console:

• Clique em Adicionar canal depois de adicionar mensagens de resposta padrão. A interface do usuário permite que você adicione mensagens de resposta específicas do canal. Clique em Adicionar canal novamente.

Para fornecer mensagens de resposta específicas do canal para fulfillment ao usar a API:

• Defina o campo Fulfillment.messages[i].channel para o canal desejado para cada mensagem de resposta. Se esse campo não for definido, a resposta será uma mensagem de resposta padrão.

Como usar mensagens de resposta específicas do canal no momento da execução

Observação: se você estiver usando uma integração que ofereça suporte aos canais, a implementação da integração seguirá as etapas abaixo.

Para receber uma mensagem de resposta específica do canal, o canal precisa ser especificado na mensagem de solicitação de intent de detecção. Consulte o campo queryParams.channel no método detectIntent do tipo Sessions. Acessar a referência da API Session

Selecione um protocolo e uma versão para a referência de sessão:

Protocolo	V3	V3beta1
REST	Recurso da sessão	Recurso da sessão
RPC (remote procedure call)	Interface da sessão	Interface da sessão
C++	SessionsClient	Indisponível
C#	SessionsClient	Indisponível
Go	SessionsClient	Indisponível
Java	SessionsClient	SessionsClient
Node.js	SessionsClient	SessionsClient
PHP	Indisponível	Indisponível
Python	SessionsClient	SessionsClient
Ruby	Indisponível	Indisponível

Fechar

Se nenhum canal for definido em uma solicitação ou nenhum canal correspondente for encontrado no fulfillment, a mensagem de resposta padrão será retornada pelo Dialogflow.

Modelos de payload personalizados

Se você usa payloads personalizados com frequência, opte pelos modelos de payload personalizado. Às vezes, os payloads personalizados são grandes e complexos, então o uso de modelos pode facilitar o processo de criação do agente.

É possível fornecer esses modelos nas configurações do agente, o que os torna disponíveis para seleção sempre que você criar um fulfillment para seu agente.

Por exemplo, o payload JSON para os botões "sim" e "não" pode ser definido como modelos de payload personalizados. Ao criar o fulfillment que exija esses botões, você só precisa selecionar o modelo ao criar o fulfillment.

Quando você seleciona um modelo para um payload personalizado do fulfillment, o conteúdo do modelo é inserido no payload. Depois, você pode editar o payload conforme necessário.

Se você alterar um modelo, a alteração não será propagada automaticamente a todos os payloads de fulfillment em que foi referenciado.

Para criar um modelo de payload personalizado, consulte as configurações gerais do agente.

Para selecionar um modelo de payload personalizado ao criar um fulfillment, clique em Selecionar modelo ao criar um payload personalizado do fulfillment.

Chamadas de webhook

Quando um fulfillment é chamado e tem um webhook, o agente envia uma solicitação ao webhook. O webhook pode realizar as ações necessárias no seu serviço, fornecer uma mensagem de resposta dinâmica, modificar os valores dos parâmetros e alterar a página atual.

Veja a seguir as configurações do webhook para fulfillment:

Termo	Definição
Ativar webhook	Isso ativa o webhook para o fulfillment.
Webhook	Selecione o recurso do webhook.
Tag	A tag de texto fornecida aqui será preenchida no campo WebhookRequest.fulfillmentInfo.tag da solicitação do webhook enviada ao serviço do webhook. Isso pode ser usado para controlar o comportamento do webhook de uma forma específica para o fulfillment.

Predefinições de parâmetros

É possível usar um fulfillment para fornecer predefinições que definem ou modifiquem os valores de parâmetros atuais. Essas predefinições serão aplicadas antes de resolver mensagens de resposta estática ou chamar um webhook.

Você também pode usar funções do sistema para predefinir o parâmetro para um valor gerado dinamicamente.

Estes são alguns exemplos:

• Como definir um parâmetro now para o horário atual:

  Parâmetro	Valor
  now	$sys.func.NOW()

• Incrementar um parâmetro atual counter em 1:

  Parâmetro	Valor
  Contador	$sys.func.ADD($session.params.counter, 1)

• Definir um parâmetro new-cost para o valor de parâmetro other-cost, mantendo o valor completo do objeto composto:

  Parâmetro	Valor
  custo novo	$sys.func.IDENTITY($session.params.other-cost)

Configurações avançadas de fala

Essas configurações de fala podem substituir a mesma configurações de fala na página ,Configurações da fala do fluxo eConfigurações de fala do agente de dados.

Fila de resposta

Durante a rodada de um agente, é possível (e às vezes desejável) chamar vários fulfillments, e cada um deles pode gerar uma mensagem de resposta. O Dialogflow mantém essas respostas em uma fila de respostas.

Resposta parcial para a API Streaming

Visualização

Este produto ou recurso é coberto pelos Termos de ofertas pré-GA dos Termos de Serviço do Google Cloud. Os produtos e recursos pré-GA podem ter suporte limitado, e as mudanças neles podem não ser compatíveis com outras versões pré-GA. Para mais informações, consulte as descrições da fase de lançamento.

Por padrão, o Dialogflow só envia as respostas ordenadas ao usuário final quando a vez do agente terminar. Também é possível ativar a opção Retornar resposta parcial no fulfillment para retornar respostas na fila como uma resposta parcial ao usar as APIs de streaming. Consulte Ciclo de vida de uma página para mais detalhes.

Por exemplo, se o webhook provavelmente for executado por muito tempo, adicione uma resposta estática no fulfillment e ative a resposta parcial. Isso faz o Dialogflow limpar a fila de respostas e enviar todas as mensagens como uma resposta parcial antes de chamar o webhook.

No momento, a resposta parcial não é aceita para os recursos a seguir, mas será aceita mais tarde:

• Entradas de áudio no simulador.
• As integrações de telefonia de parceiros podem ou não oferecer suporte a respostas parciais no momento. Consulte a documentação do parceiro para verificar.

Para testar esse recurso no simulador, é necessário ativar a resposta parcial.

No exemplo a seguir, considere que o webhook leva cinco segundos para ser concluído e você não ativa a resposta parcial. A vez de conversar com o agente do Dialogflow não é concluída até que o webhook seja concluído. Durante essa sequência de cinco segundos, as respostas são colocadas na fila enquanto aguardam o webhook e não são retornadas ao usuário final até que a conversão seja concluída. Isso leva a uma experiência negativa do usuário.

Se você ativar a resposta parcial no primeiro fulfillment, o Dialogflow retornará a primeira mensagem rapidamente e chamará o webhook. Depois que o webhook é concluído, o Dialogflow retorna a resposta final. Nesse caso, a experiência do usuário final é aprimorada porque é esperado que ele aguarde um curto período. Além disso, a chamada do webhook está sendo executada simultaneamente com a resposta enviada ao usuário final.

Linguagem de marcação de síntese de voz (SSML)

É possível usar a Linguagem de marcação de síntese de fala (SSML, na sigla em inglês) em campos de texto de saída de texto de áudio. Isso permite personalizar a resposta de áudio fornecendo detalhes sobre pausas e formatação de áudio para acrônimos, datas, horas, abreviações ou texto que precisam ser censurados.

Para detalhes sobre a sintaxe, consulte a documentação da Conversão de texto em voz SSML.

Observação: um campo de fulfillment não pode ter mais de um par de tags <speak></speak>.