Práticas recomendadas gerais de design de agentes

Este guia oferece práticas recomendadas gerais para projetar todos os tipos de agentes.

Consulte também o guia de design de agente de voz, específico para a criação de agentes de voz, e o guia de práticas recomendadas para usar o serviço do Dialogflow CX.

Recomendações gerais

Criar agentes de modo iterativo

Caso seu agente seja grande ou complexo, comece criando um diálogo que atenda apenas às solicitações de nível superior. Depois de estabelecer a estrutura básica, itere os caminhos de conversa para garantir que todas as rotas possíveis que um usuário final pode seguir foram incluídas.

À medida que o agente evolui, considere usar o recurso casos de teste para desenvolvimento orientado a testes.

Agentes pré-criados

O Dialogflow CX oferece modelos de agentes para ajudar você a começar. Os agentes pré-criados abrangem casos de uso comuns, como serviços financeiros, telecomunicações e viagens. Eles vêm com intents e entidades que englobam as consultas de usuários mais comuns. Inclua rotas e atendimento específicos à sua empresa e você criará um agente funcional rapidamente.

Integrações e conexão de serviços

Há várias maneiras de fazer a integração com agentes do Dialogflow CX. Nesta seção, você vai encontrar as práticas recomendadas para escolher como fazer a integração.

Integrações

As integrações do Dialogflow CX fornecem uma interface do usuário pronta para uso para seu agente. Se você usar uma integração, não precisará chamar diretamente a API do Dialogflow CX, porque as integrações fazem isso por você. Essas integrações podem fornecer um agente de texto que você pode incorporar no seu site, conectar com outras plataformas de mensagens ou fornecer uma interface de telefonia.

API Dialogflow CX

Se nenhuma das integrações prontas para uso for adequada ou se você quiser personalizar a interface do seu sistema, use a API Dialogflow CX diretamente. Com essa abordagem, você precisa implementar a interface do usuário do seu agente ou usar uma interface existente.

Webhooks

A menos que seu agente possa ser completamente definido com dados estáticos, é necessário usar webhooks para conectar seu serviço e fornecer um agente que possa lidar com cenários dinâmicos. Isso se aplica ao usar integrações ou a API Dialogflow CX.

Recursos do agente

Os recursos do agente do Dialogflow CX podem ser usados de várias maneiras para alcançar um resultado desejado. Nesta seção, você encontra dicas para escolher os recursos certos para os cenários adequados.

fluxos e páginas

Os fluxos e as páginas fornecem estrutura ao seu agente. Pense nas páginas como nós em uma máquina de estado e nos fluxos como grupos de páginas relacionadas. Você controla as transições entre nós com manipuladores de estado, que são chamados quando uma intent é correspondida, uma condição é atendida ou um evento é invocado.

Um agente simples pode funcionar bem com um único fluxo, mas os agentes complexos quase sempre são projetados com vários fluxos. Cada fluxo deve representar um tópico de alto nível para seu agente, e cada página associada ao fluxo ajuda a lidar com o tópico. Além disso, cada fluxo pode ter algumas configurações próprias e ser de propriedade de um subconjunto de membros da equipe, o que ajuda a dividir o trabalho ao projetar agentes grandes.

Ao projetar um agente grande e complexo, é preciso considerar os limites de"fluxos por agente" e "páginas por fluxo". Esses limites ajudam a manter o desempenho do seu agente.

Se o design do seu agente tiver muitos fluxos, combine tópicos relacionados em um único fluxo. Por exemplo, você pode combinar os seguintes tópicos em um único fluxo "Ver saldo":

• Verificar saldo da conta corrente
• Ver saldo da poupança
• Ver saldo da hipoteca
• Conferir saldo de crédito

Se o design do agente tiver muitas páginas por fluxo, combine páginas relacionadas e use muitas rotas por página.

Se você ainda estiver com dificuldade em relação aos limites de fluxo e página, talvez seja porque há muita lógica de negócios integrada ao próprio agente. Considere mover essa lógica para webhooks.

A seguir, listamos a granularidade do controle de conversa dos recursos do agente em ordem crescente de granularidade:

1. Agentes (um agente lida com todas as conversas)
2. Fluxos (um fluxo processa um ou mais tópicos de conversa relacionados)
3. Páginas (uma página processa uma ou mais conversas relacionadas)
4. Rotas (uma rota processa uma intent do usuário ou uma verificação de condição)

Parâmetros de intent x parâmetros de formulário

A principal maneira de o sistema receber dados estruturados do usuário final é com parâmetros. É possível usar parâmetros para intenções (parâmetros de intenção) ou páginas (parâmetros de formulário).

O objetivo principal de algumas páginas é coletar informações específicas do usuário final. Por exemplo, uma página pode ser projetada para coletar as dados de contato do usuário final. Nesse caso, use sempre parâmetros de formulário para coletar essas informações.

Em alguns casos, talvez você queira capturar informações do usuário final durante a transição de uma página para outra. Por exemplo, se o usuário final pedir um produto específico no início da conversa, você vai querer capturar o produto desejado ao fazer a transição para a página de pedido adequada. Nesse caso, use parâmetros de intent como parte das rotas de intent.

Há também situações em que o ideal é usar os dois tipos de parâmetros. Por exemplo, se o usuário final pedir uma camisa pequena no início da conversa, você vai querer capturar o parâmetro de tamanho desejado (pequeno) ao fazer a transição para a página de pedido de camisa. A página de pedido de camisetas pode pedir mais informações, como a cor desejada. A página de pedido de camiseta precisa ter parâmetros de formulário para tamanho e cor. Neste exemplo, o parâmetro de tamanho já foi fornecido e é propagado. Portanto, o agente vai pedir apenas a cor. No entanto, outras conversas podem seguir um caminho diferente, em que o usuário final não forneceu o tamanho desejado quando a página de pedido da camiseta foi ativada. Ao definir esse parâmetro de ambas as maneiras, seu agente fica mais flexível na extração de informações.

Observação: ao definir parâmetros com o mesmo ID ou nome de exibição em diferentes intenções ou formulários, verifique se o tipo de entidade e outras configurações são iguais para todas as definições. Se o tipo de entidade ou outras configurações de parâmetro forem diferentes, use um ID ou nome de exibição exclusivo para cada definição.

Rotas e grupos de rotas

Se você quiser fazer a transição para outra página, enfileirar uma mensagem de resposta ou chamar um webhook quando uma intent for correspondida ou uma condição for atendida, use rotas.

Se você estiver usando o mesmo conjunto de rotas em várias páginas, use grupos de rotas. Isso evita duplicações desnecessárias no design do agente.

Reutilização de intents

Se você estiver definindo várias intents com frases de treinamento semelhantes, considere reutilizar intents em várias páginas. O ideal é definir algumas intents de uso geral que são usadas em muitas páginas e outras específicas que são usadas apenas em uma página. Isso evita duplicações desnecessárias no design do agente.

Por exemplo, as intents de confirmação geralmente são definidas como intents reutilizáveis. Um intent confirmation.yes pode ter frases de treinamento como:

• sim
• sim
• yep
• ok
• sim
• pode apostar
• absolutamente
• sim, por favor

Um intent confirmation.no pode ter frases de treinamento como:

• não
• nah
• não
• de jeito nenhum
• não é para mim
• de jeito nenhum
• não, obrigado

Essas intents de confirmação reutilizáveis podem ser usadas em vários cenários para seu agente.

Em alguns casos, também é recomendável criar intents de confirmação especializadas. Por exemplo, ao confirmar um pedido, talvez você queira ter uma intent order.confirmation.yes especializada com frases de treinamento como:

• a ordem parece boa para mim
• Aceito este pedido

e um intent order.confirmation.no especializado com frases de treinamento como:

• Não quero este pedido
• Não aceito este pedido

Quando a página de confirmação do pedido está ativa, as rotas de intenção para todas as quatro intenções devem estar no escopo. Isso garante que qualquer confirmação genérica ou específica do usuário final seja processada adequadamente.

Intent negativa padrão

Preencha a intent negativa padrão com frases que seus usuários finais podem dizer, mas que não devem corresponder a nenhuma intent no agente.

Fulfillment

Há muitas opções para usar o fulfillment para responder ao usuário final. Durante uma rodada de conversa, o agente pode anexar várias mensagens à fila de resposta, e a fila concatenada é enviada ao usuário final no final da rodada de conversa. Esta seção descreve cada opção para criar as mensagens individuais.

• Fulfillment de entrada da página: esse fulfillment é chamado quando a página se torna ativa inicialmente. É útil quando você quer uma mensagem que descreva a finalidade da página, e ela só deve ser dita uma vez enquanto a página estiver ativa. Por exemplo:
  • O que você quer saber sobre sua conta corrente?
  • Que tipo de produto você quer comprar?
  • Preciso coletar algumas informações sobre a camisa que você quer pedir.
• Rotas: esse fulfillment é chamado quando uma rota de intent ou uma rota de condição com fulfillment é chamada. Isso é útil quando você quer uma mensagem que responda ao usuário final sobre a correspondência de intent, a condição satisfeita (que pode ser uma condição de conclusão do preenchimento de formulário) ou a transição. Exemplo:
  • Sim, seu plano internacional inclui o Japão. (correspondência de intenção)
  • Você quer mesmo comprar 300 camisetas? (condição de comparação atendida)
  • Ok, seu horário é para amanhã às 7h. (conclusão do preenchimento de formulário)
  • Ok, vamos falar sobre tamanduás agora. (transição)
• Manipuladores de eventos: esse fulfillment é chamado quando um evento é invocado. É útil quando você quer uma mensagem que responda ao evento. Por exemplo:
  • A ação que você está considerando comprar acabou de aumentar em 10%. (evento personalizado)
  • Pode reformular? (evento sem correspondência)
• Solicitações iniciais para formulários: esse fulfillment é chamado quando o agente preenche um formulário. Essas mensagens precisam fazer uma pergunta específica ao usuário final. Cada parâmetro de formulário tem um fulfillment de solicitação inicial próprio. Por exemplo:
  • Qual tamanho de camisa você quer?
  • Que cor de camisa você quer?
• Gerenciadores de reprompt para formulários: esse fulfillment é chamado quando o agente está preenchendo um formulário e não entende a seleção do usuário final para o parâmetro atual. Essa ação só é necessária se você quiser que uma mensagem de nova solicitação seja diferente da mensagem de solicitação inicial. Se não houver gerenciadores de nova solicitação, o agente vai usar a solicitação inicial como a mensagem de nova solicitação. Por exemplo:
  • Não entendi. Você pode informar uma cor válida para a camisa?

Nomenclatura

Esta seção oferece dicas para nomear recursos de agente.

Nomeação de intents

Se o agente tiver muitas intents, considere um esquema de nomenclatura que ajude você a mantê-las organizadas. É comum segmentar nomes de intents com pontuação, em que a especificidade aumenta da esquerda para a direita. Além disso, o nome da intent precisa refletir a intenção do usuário final de fazer uma conversa.

Há ótimas esquemas de nomenclatura. Veja alguns exemplo a seguir:

• phone-service.order.cancel
• phone-service.order.create
• phone-service.order.change
• tv-service.order.cancel
• tv-service.order.create
• tv-service.order.change
• account.balance.get
• account.balance.pay
• account.address.get
• account.address.update

Transições

As transições definidas em manipuladores de estado controlam a conversa mudando a página ativa. Nesta seção, você encontra dicas para organizar as transições do agente.

Transições sem custo financeiro

Ao definir uma rota que aciona uma transição, considere que pode haver uma rota complementar ou inversa.

Exemplo:

• Se você tiver uma rota de intent para confirmation.yes, considere definir outra rota para confirmation.no.
• Se você definir uma rota de condição com um operador booleano =, considere definir outra rota que use !=.

Como processar a entrada do usuário final

Esta seção fornece diretrizes para intents e frases de treinamento, para que seu agente possa processar e lidar de maneira ideal com a entrada do usuário final.

Definir pelo menos 20 frases de treinamento

É preciso ter pelo menos 20 frases de treinamento para cada intent. Caso contrário, o modelo de NLU pode não ter informações suficientes para corresponder adequadamente à sua intenção. Esta é uma orientação mínima. O ideal é definir mais, principalmente para intenções principais de agentes grandes, em que aproximadamente 50 é desejável.

Conheça o viés de intenção

Quando um ou mais intents têm muito mais frases de treinamento do que outros, isso faz com que o modelo de NLU favoreça os intents maiores devido a dados desequilibrados. Isso pode acontecer quando a quantidade de frases de treinamento difere em uma ordem de magnitude ou mais.

Em alguns casos, esse é o comportamento desejado, porque você pode definir algumas intents que precisam ser correspondidas com mais frequência do que outras, já que correspondem a entradas do usuário final observadas com mais frequência no tráfego ativo.

Em outros casos, esse comportamento pode ser indesejável porque você não quer um viés a favor dessas intenções maiores. Se for esse o caso, reduza o número de frases de treinamento dessas intents maiores para que tenham a mesma ordem de magnitude que outras intents. Exemplo:

Frases de treinamento do intent A	Frases de treinamento do intent B	Viés para a intent B
20	50	Não
20	200	Quase atende
20	2000	Sim

Uso de entidades e quantidade de frases de treinamento

Para todos os tipos de entidade usados em uma intent:

• Anote todos os exemplos dos tipos de entidade.
• Para cada um dos tipos de entidade, forneça pelo menos cinco frases de treinamento com exemplos anotados.
• Forneça pelo menos três vezes mais frases de treinamento do que tipos de entidade. Por exemplo, se você usar 10 tipos de entidades diferentes para anotações em um intent, é necessário ter pelo menos 30 frases de treinamento.

As frases de treinamento precisam ser naturais

As frases de treinamento precisam ser conversacionais e naturais, ou seja, corresponder ao que as pessoas realmente dizem. Sempre que possível, use como dados de treinamento as entradas do usuário final que ocorreram na produção, prestando atenção especial às mais comuns.

Variedade necessária de frases de treinamento

Inclua variações de perguntas, comandos, verbos e sinônimos de substantivos comuns para garantir que as frases englobem um amplo espectro de solicitações possíveis.

É melhor incluir algumas frases mais curtas, como "pagar minha conta", além de frases e orações mais longas, como "Acabei de receber algo pelo correio dizendo que preciso pagar o saldo da minha fatura". Não há uma proporção recomendada de frases curtas e longas, mas você deve basear isso nas entradas reais do usuário final enviadas ao seu agente em produção.

É importante definir frases de treinamento que variam em comprimento, fraseado e estrutura da frase para garantir um bom treinamento do seu agente. Não é necessário adicionar variedade por adicionar, mas é necessário fornecer variedade suficiente para que o modelo de NLU possa detectar com sucesso a intenção do usuário final em uma ampla variedade de entradas. Se você não tiver variedade suficiente, há risco de overfitting. Em outras palavras, há o risco de o modelo ficar muito vinculado aos exemplos específicos que você fornece e não generalizar o suficiente para outros exemplos.

Variedade de capitalização

A sensibilidade a maiúsculas e minúsculas varia de acordo com o modelo de NLU usado pelo seu agente.

PLN padrão

O modelo PLN padrão não diferencia maiúsculas de minúsculas. Em casos raros, talvez seja necessário adicionar frases de treinamento que variam apenas na capitalização. Isso geralmente se aplica a situações em que você espera que os usuários finais forneçam entradas de texto em letras maiúsculas.

Abordagens alternativas podem ser:

• Diminuir o limiar de classificação de ML
• Converter as entradas do usuário final em letras minúsculas antes de enviá-las ao Dialogflow CX.

PLN avançado

Ao contrário do modelo PLN padrão, o avançado diferencia maiúsculas de minúsculas. Recomendamos testar e adicionar os dados de treinamento relevantes em maiúsculas para aumentar as taxas de correspondência de intenção.

Variedade desnecessária de frases de treinamento

Evite variações triviais nas frases de treinamento, porque elas fornecem informações duplicadas ao modelo de PLN. Por exemplo, não inclua variantes que diferem apenas por:

• Uso de maiúsculas: se você estiver usando o modelo de PLN padrão, evite frases duplicadas, como "Peça um ingresso" e "peça um ingresso", exceto em casos raros. No entanto, o modelo de PLN avançado diferencia maiúsculas de minúsculas e exige mais frases de treinamento para aumentar as correspondências de intenção. Consulte a seção de variedade de capitalização para mais detalhes.
• Palavras de preenchimento: por exemplo, "ok, peça um ingresso" e "peça um ingresso".
• Pontuação: por exemplo, "você pode ajudar, por favor?" e "você pode ajudar, por favor!?"

Consistência de anotações

A parte da frase de treinamento selecionada para uma anotação precisa incluir todo o texto necessário para corresponder a uma entidade e não mais que isso. Além disso, verifique se partes semelhantes das frases de treinamento estão anotadas para toda a intent.

Por exemplo, a tabela a seguir mostra maneiras boas e ruins de fazer anotações com a entidade de sistema @sys.date:

Bom	Ruim
Partida em 7 de setembro	Partida em 7 de setembro
Saída em 4 de julho	Saindo do app em 4 de julho

Use anotações semanticamente significativas para entidades do sistema

O significado semântico de uma parte da frase de treinamento selecionada para uma anotação pode ser afetado pelo restante do texto. Exemplo:

Frase de treinamento anotada	Significado semântico do texto anotado
Tenho 7 anos	A idade de uma pessoa
O contrato é válido por 7 anos	Uma duração de tempo

Os modelos de aprendizado de máquina do Dialogflow CX consideram o significado semântico ao fazer a correspondência de entidades do sistema. O significado semântico da parte da frase de treinamento precisa corresponder ao significado semântico pretendido da entidade do sistema.

Por exemplo, não use a entidade de sistema @sys.duration para anotar o primeiro exemplo "7 anos" acima. O significado semântico de "7 anos" não corresponde a uma duração simples. Em vez disso, selecione "7" para a anotação e use a entidade de sistema @sys.number.

Definir intents para processar respostas de preenchimento de formulário que não estão em conformidade

Considere definir intents para lidar com respostas de preenchimento de formulários não compatíveis. Por exemplo, seu agente pode perguntar "Quais são as datas da sua viagem?", seguido da resposta do usuário final "Ainda não sei". Essa resposta não atende à solicitação de parâmetro do formulário, mas se o agente tiver uma rota de intent no escopo que possa corresponder a ela, ele poderá lidar bem com a situação.

Evitar @sys.any

Evite usar o tipo de entidade do sistema @sys.any. Ele só deve ser usado se você tiver esgotado completamente todas as opções, incluindo a criação de entidades personalizadas. Esse tipo de entidade é muito amplo e pode causar um comportamento indesejado.

Se você usar esse tipo de entidade, evite anotar várias partes de uma única frase de treinamento com ele, porque isso cria uma ambiguidade, e o comportamento do agente será indefinido.

É menos perigoso usar @sys.any com parâmetros de formulário, porque o agente espera informações específicas ao solicitar parâmetros de formulário.

Observação: algumas entidades do sistema não estão disponíveis quando você regionaliza a implantação do seu agente, e @sys.any às vezes é recomendado como uma solução alternativa.

As anotações precisam incluir uma variedade de valores de entidade

Ao definir frases de treinamento anotadas, use uma variedade de exemplos de valores de entidade nas frases. Não use sempre o mesmo exemplo de entidade para as anotações. O exemplo a seguir mostra anotações boas e ruins para um tipo de entidade de produto:

Bom	Ruim
Quero comprar uma camisa	Quero comprar uma camisa
Pedir um novo chapéu	Encomendar uma camiseta nova
Adicionar um relógio ao meu carrinho	Adicionar uma camisa ao meu carrinho

As entidades personalizadas precisam incluir variedade

As entidades personalizadas devem abranger uma grande diversidade de exemplos. O modelo de PLN vai oferecer variedade para as classes gramaticais, mas é necessário incluir todos os itens possíveis.

Evitar entidades que correspondem de forma agressiva

Não defina entidades que correspondam a praticamente tudo. Isso degrada o desempenho e a qualidade do ML. Quase tudo em cada frase de treinamento será avaliado como uma correspondência possível.

As entidades de mapa e lista precisam se concentrar em valores distintos

Os tipos de entidade de mapa e lista precisam ter um escopo limitado que capture valores distintos de um tipo de informação. Mantenha suas entidades focadas, curtas e simples.

Se os valores de entidade forem complicados, talvez as frases de treinamento de intent sejam mais adequadas para sua situação. Por exemplo, considere a entrada do usuário final:

• "Como posso fazer uma chamada internacional com o plano A?"
• "Uso de roaming de dados internacional com o plano B".

Não crie tipos de entidade para as ações e os planos, como estes:

Tipo de entidade de ações	Tipo de entidade "Plans"
"Como faço uma ligação internacional?"	"Plano A"
"Uso de roaming de dados internacional"	"Plano B"

Em vez disso, use frases de treinamento e correspondência de intent para detectar as ações/entidades e os planos.

Use entidades regexp para capturar identificadores que não são palavras

Ao capturar entradas do usuário final que envolvem identificadores que não são palavras, use entidades regexp. Por exemplo, para capturar IDs de produtos como "AA-256" ou "AC-436", use uma entidade de expressão regular como "[A-Z]{2}-\d{3}".

Evite aninhar entidades compostas

Não use mais de um nível de aninhamento em entidades compostas. Cada nível de aninhamento degrada a qualidade de modo significativo.

Evitar intents semelhantes

Cada intent precisa capturar a intenção do usuário final. Se você definir intents diferentes com frases de treinamento semelhantes, a correspondência poderá não ser confiável porque o modelo de NLU não consegue determinar com confiança suficiente qual intent corresponder.

Se duas frases de treinamento representam a mesma intenção, elas precisam pertencer à mesma intent. Por exemplo, "mudar a data de vencimento da fatura atual" e "mais tempo para pagar" devem pertencer à mesma intenção, porque ambos estão solicitando uma mudança na data de vencimento. No entanto, "Posso fazer uma ligação internacional com o plano A?" e "Posso usar o roaming de dados internacional com o plano A?" podem pertencer a intents diferentes, porque o usuário final quer algo diferente em cada caso.

Evitar tipos de entidade semelhantes

Evite definir vários tipos de entidades com entradas semelhantes, porque isso pode gerar ambiguidade para o modelo de NLU.

Usar eventos sem correspondência em produção para melhorar suas intents

Ao executar o agente em produção, é inevitável que algumas entradas do usuário final resultem em eventos sem correspondência. Você pode usar essas oportunidades para melhorar seu agente de uma destas três maneiras:

• Adicione a entrada do usuário final como uma frase de treinamento à intent desejada. No entanto, essa nem sempre é a melhor opção. Se você fizer isso muitas vezes para a intent, poderá ocorrer um viés de intent.
• Limpe as frases de treinamento da intent desejada para que todas reflitam a intenção com precisão. Em alguns casos, intents com frases de treinamento divergentes podem impedir a correspondência.
• Se as intents que não devem ser correspondidas à entrada do usuário final tiverem frases de treinamento que possam corresponder à entrada do usuário final, exclua essas frases de treinamento.

Evite caracteres especiais

Caracteres especiais em frases de treinamento ({, _, #, [ e assim por diante) são ignorados. Uma exceção a isso são os emoticons, que funcionam como esperado.

Evite palavras desnecessárias

As pausas discursivas são palavras que podem ser ignoradas sem prejudicar a compreensão do texto. Exemplo:

• por favor
• Você pode
• hmmm
• que tal

Não é necessário, mas não há problema em usar palavras de preenchimento nas frases de treinamento, porque elas são ignoradas pelo modelo de PLN. No entanto, não defina frases de treinamento que variam apenas por pausas discursivas.

Nunca defina entidades compostas de pausas discursivas.

Testar as configurações de ML

As configurações de ML podem ser usadas para ajustar como a entrada do usuário final é processada. Na maioria dos casos, as configurações padrão funcionam bem. No entanto, talvez seja necessário ajustar as configurações para melhorar a performance do agente.

Responder ao usuário final

Esta seção fornece diretrizes para usar o fulfillment e responder ao usuário final.

Dar boas-vindas ao usuário final

Um agente recém-criado tem uma rota de intent criada automaticamente para a intent de boas-vindas. Edite essa rota para incluir uma mensagem de atendimento que dê as boas-vindas ao usuário final. Essa mensagem precisa descrever o agente e dar ao usuário final uma ideia do que ele é capaz de fazer.

Confirmar informações do usuário final

Muitas vezes, é melhor repetir as informações fornecidas pelo usuário final nas respostas. Isso informa ao usuário final que o agente está entendendo a solicitação.

Quando uma intent é correspondida e ocorre uma transição, informe ao usuário final que a conversa está progredindo com base na solicitação dele. Exemplo:

Diálogo	Descrição
Usuário final: Tenho dúvidas sobre minha conta corrente. Agente: Ok, o que você quer saber sobre sua conta corrente?	A entrada do usuário final resultou em uma correspondência de intent, e uma rota foi seguida, incluindo uma mensagem de atendimento e uma transição para uma página que lida com perguntas sobre contas correntes. O agente confirma que o usuário final quer saber sobre a conta corrente.

Quando o preenchimento do formulário for concluído, repita os dados fornecidos pelo usuário final. Exemplo:

Diálogo	Descrição
Usuário final: Amanhã Agente: Ok, seu corte de cabelo está agendado para amanhã às 19h. Posso ajudar com mais alguma coisa?	O usuário final forneceu o parâmetro de formulário de data, que era o último parâmetro de formulário na página ativa. O agente confirmou o horário e a data de um corte de cabelo agendado.

Conduzir a conversa

O agente sempre precisa guiar a conversa com o usuário final. Isso é fácil de fazer. Basta terminar cada resposta com uma pergunta como:

• Posso ajudar com mais alguma coisa?
• O que você quer saber sobre beagles?
• Você quer cancelar ou enviar esse pedido?
• Como posso ajudar hoje?
• Você está viajando sozinho ou com alguém?

Ao definir essas perguntas, evite fazer várias perguntas como:

• Você ainda está aí? Sobre qual serviço você quer saber?
• Você ainda quer este pedido? Quer adicionar algo?

O usuário final pode responder apenas a uma das perguntas, e o agente pode não lidar com essa situação corretamente.

Tratamento de erros e entradas inesperadas do usuário final

Esta seção oferece dicas sobre como lidar com erros e entradas inesperadas do usuário final.

Criar manipuladores de eventos para eventos integrados

Crie manipuladores de eventos para os eventos integrados conforme aplicável. O processamento desses eventos é semelhante à captura de exceções na programação de software. Dependendo da situação, talvez seja necessário processar os eventos com manipuladores específicos de parâmetros, páginas ou fluxos.

Processar erros de webhook

Quando o serviço de webhook falha, é importante que o agente possa lidar com a falha de maneira adequada. Para isso, defina manipuladores de eventos para os eventos integrados específicos do webhook. Confira uma abordagem recomendada para lidar com erros de webhook:

• Não forneça um destino de transição do manipulador de estado que aciona a chamada de webhook. Caso contrário, o manipulador de eventos de erro do webhook não será invocado. Em vez disso, defina o destino da transição na resposta do webhook do serviço de webhook.

• Escolha uma página em que um contador de erros possa ser inicializado como zero. Essa página precisa estar ativa antes da página que aciona uma chamada de webhook. O fulfillment de entrada para essa página precisa inicializar o contador de erros como 0 usando uma predefinição de parâmetro de fulfillment. Exemplo:

  Parâmetro	Valor
  webhook-error-count	0

• Crie uma página de erro de webhook que processe eventos de erro de webhook:

  • O fulfillment de entrada precisa reconhecer a falha para o usuário final e incrementar um parâmetro de sessão de contador de erros usando uma predefinição de parâmetro de fulfillment. Exemplo:

    Parâmetro	Valor
    webhook-error-count	$sys.func.ADD($session.params.webhook-error-count, 1)

  • Defina uma rota condicional que tenha uma condição em que a contagem de erros seja menor que o máximo permitido. Por exemplo, $session.params.webhook-error-count <= 3. Essa rota precisa ter um fulfillment que notifique o usuário final de que o agente vai tentar de novo. Essa rota precisa ter um destino de transição definido como PREVIOUS_PAGE, ou para qualquer página que possa fazer outra tentativa de chamar o webhook.

  • Defina uma rota de condição que tenha uma condição em que a contagem de erros seja maior que o máximo permitido (por exemplo, $session.params.webhook-error-count > 3). Essa rota precisa ter um atendimento que notifique o usuário final de que o agente não vai mais tentar novamente. Essa rota precisa ter um destino de transição definido como uma página que não vai acionar novas tentativas de webhook.

• O gerenciador de eventos do webhook precisa ter um destino de transição que faça a transição para a página de erro do webhook.

Ferramentas

Esta seção oferece dicas sobre como usar ferramentas para melhorar o design do agente.

Usar a ferramenta de validação

Use sempre a ferramenta de validação para verificar seu agente. Essa ferramenta encontra alguns dos problemas descritos neste guia.

Usar o recurso de casos de teste

Sempre defina casos de teste para seu agente. Esses casos de teste ajudam a evitar regressões enquanto o agente evolui para lidar com mais cenários.