Fulfillments

Pour le tour de conversation d'un agent, il doit répondre à l'utilisateur final en lui fournissant une réponse à une question, une requête d'informations ou une cessation de session. Votre agent peut également avoir besoin de contacter votre service pour générer des réponses dynamiques ou prendre des mesures pour un tour. Le fulfillment permet d'effectuer toutes ces opérations.

Un fulfillment peut contenir l'un des éléments suivants :

• Messages de réponse statiques
• Appels webhook pour les réponses dynamiques et/ou pour effectuer des actions
• Préréglages de paramètres pour définir ou remplacer les valeurs de paramètres

Lors du tour d'un agent, il est possible (et parfois souhaitable) d'appeler plusieurs fulfillments, chacun pouvant générer un message de réponse. Dialogflow conserve ces réponses dans une file d'attente de réponses. Une fois le tour de l'agent terminé, Dialogflow envoie les réponses triées à l'utilisateur final.

Le fulfillment ES est limité à la connexion d'un service de webhook. Le champ d'application du fulfillment a été étendu pour CX. Il couvre désormais tous les types d'invites et de réponses.

Cas d'utilisation du fulfillment

Le fulfillment est utilisé partout où un message de réponse est nécessaire :

• Fulfillment d'entrée de page
• Routes
• Gestionnaires d'événements
• Invites initiales pour formulaires
• Gestionnaires de nouvelles invites de formulaires

Pour chacun de ces cas d'utilisation, la console ouvre un panneau de modification de fulfillment.

Messages de réponse statiques (options de dialogue)

Les messages de réponse statique sont des réponses d'agent que vous définissez au moment de la conception. Ces réponses doivent être définies lors de la création d'un fulfillment. Au moment de l'exécution, ces réponses sont ajoutées à la file d'attente de réponse.

Il existe plusieurs types de messages de réponse qui sont décrits dans les sous-sections ci-dessous. Dans la console, le panneau de fulfillment comprend une fiche de message de réponse textuelle initiale. Vous pouvez ensuite cliquer sur Ajouter une option de dialogue pour ajouter d'autres fiches pour les autres types de messages de réponse.

Texte

Les messages de réponse textuelle envoient un dialogue sous forme de texte à l'utilisateur final. Si vos appels d'API de détection d'intent ou votre intégration utilisent la synthèse vocale, ce texte sera utilisé pour générer du contenu audio. Dans ce cas, le texte fourni peut éventuellement utiliser le langage de balisage de synthèse vocale (SSML).

Vous pouvez définir plusieurs fiches de réponse textuelle et plusieurs réponses textuelles dans chaque fiche. Si vous définissez plusieurs fiches, elles sont concaténées en une seule réponse au moment de l'exécution. Si vous définissez plusieurs réponses dans une fiche, l'un des messages de la fiche est choisi de manière aléatoire au moment de l'exécution.

Ces messages peuvent contenir des références de paramètres et des fonctions système intégrées.

Charge utile personnalisée

Certaines intégrations permettent une réponse avec une charge utile personnalisée pour gérer les réponses enrichies. Ces charges utiles personnalisées sont fournies au format JSON défini dans la documentation de l'intégration. Par exemple, reportez-vous au format de charge utile personnalisée Dialogflow Messenger.

Vous pouvez inclure des références de paramètres dans votre fichier JSON de charge utile personnalisée. Ils doivent être traités comme des valeurs de chaîne JSON et sont donc placés entre guillemets doubles. Exemple :

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

Vous pouvez également envoyer une charge utile personnalisée aux intégrations que vous développez. Elle ne sera pas traitée par Dialogflow. Sa gestion dépend de votre logique métier.

Consultez également la section Modèles de charges utiles personnalisées ci-dessous.

Transfert à un agent humain

Cette réponse indique à l'appelant de l'API de détection d'intent que la conversation doit être transmise à un agent humain. Dialogflow utilise uniquement ce signal pour identifier les conversations transmises à des fins de mesure et ne modifie en aucun cas l'état de la session. Votre système ou votre intégration peut utiliser ce signal pour effectuer les actions nécessaires au transfert de la conversation. Dialogflow n'impose aucune structure pour ces données. Vous pouvez donc choisir n'importe quelle structure adaptée à votre système.

Métadonnées de réussite de la conversation

Cette réponse indique à l'appelant de l'API de détection d'intent que la conversation avec l'agent Dialogflow a abouti. Dialogflow utilise uniquement ce signal pour identifier les conversations ayant abouti à des fins de mesure et ne modifie en aucun cas l'état de la session. Votre système ou votre intégration peut utiliser ce signal pour effectuer les actions nécessaires. Dialogflow n'impose aucune structure pour ces données. Vous pouvez donc choisir n'importe quelle structure adaptée à votre système.

Lire du contenu audio préenregistré

Cette réponse lit un fichier audio pour les intégrations compatibles avec cette fonctionnalité.

Les exigences concernant le format des fichiers audio peuvent varier en fonction des intégrations. Par exemple, consultez les exigences de la passerelle téléphonique Dialogflow CX.

Pour les intégrations téléphoniques partenaires, l'URL du fichier audio doit être accessible par le partenaire. Une URL accessible au public, telle qu'un fichier public dans Cloud Storage, est toujours accessible au partenaire. Le partenaire peut également accorder un accès limité aux fichiers audio. Consultez la documentation du partenaire pour en savoir plus.

Texte audio de sortie

Cette réponse est semblable à la réponse text, mais elle ne s'applique qu'à la synthèse vocale. Si votre agent peut gérer à la fois les sessions textuelles et les sessions vocales, vous pouvez utiliser des réponses uniques pour texte et texte audio de sortie afin de créer une expérience utilisateur différente pour le texte par rapport à voix. Si un texte audio de sortie est fourni pour une session vocale, les réponses en texte brut sont ignorées.

Si votre agent gère des sessions textuelles et vocales, et que vous souhaitez utiliser les mêmes messages de réponse dans les deux cas, utilisez simplement les réponses textuelles pour les deux types de session.

Le texte audio de sortie est concaténé de la même façon que les réponses textuelles. Si les réponses de texte audio de sortie sont un mélange de texte et de SSML, le résultat concaténé est traité comme du SSML. Dans l'idéal, le concepteur de l'agent doit utiliser soit du texte, soit du SSML.

Réponse conditionnelle

Ce type de réponse est utilisé pour les réponses conditionnelles. Le format général est :

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

où :

• [condition] est le même format que celui utilisé pour les conditions de routage.
• [response] est une réponse textuelle.
• Les blocs elif et else sont facultatifs.

Exemple :

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

[condition] et [response] peuvent utiliser des fonctions système intégrées pour générer des valeurs dynamiques pendant les conversations. Pour plus d'informations, veuillez consulter les références des fonctions système et des conditions de routage.

Pour les agents multilingues, [condition] est commun à toutes les langues, tandis que [response] est spécifique à chaque langue. Lorsque vous modifiez [condition] pour une langue dans la console, l'élément est mis à jour dans toutes les langues de l'agent. Et dans la mesure où l'élément devient une nouvelle condition, [response] est effacé pour toutes les langues. autres que celle sélectionnée lors de la mise à jour de [condition].

Transfert d'appel téléphonique

Remarque : Le transfert d'appel n'est actuellement disponible que pour la passerelle de téléphonie Dialogflow.

Pour certaines intégrations de téléphonie, vous pouvez spécifier un numéro de téléphone aux États-Unis pour le transfert d'appel. Au moment de l'exécution, lorsque l'agent virtuel Dialogflow appelle un fulfillment avec un transfert d'appel, l'appel est transféré vers le numéro spécifié et la gestion des agents virtuels est suspendue.

Messages de réponse spécifiques au canal

Lorsque vous définissez le traitement, vous pouvez créer des messages de réponse spécifiques au canal, afin de créer des réponses ciblées pour les chats textuels, vocaux et SMS, les intégrations spécifiques compatibles avec les canaux, etc. Tous les messages de réponse qui ne sont pas spécifiques à un canal sont appelés messages de réponse par défaut.

Au moment de l'exécution, Dialogflow sélectionne le message de réponse par défaut ou un message de réponse spécifique au canal lorsqu'une requête de détection d'intent spécifie un canal. Nous vous recommandons de définir des messages de réponse par défaut, même si vous utilisez des messages de réponse spécifiques au canal. Les messages de réponse par défaut peuvent servir de solution de secours lorsque votre système ne fournit pas de canal valide.

Un nom de critère est un champ personnalisé que vous pouvez définir pour n'importe quel texte. Si vous utilisez directement l'API Dialogflow pour les appels d'exécution, vous pouvez utiliser les noms de canaux de votre choix. Si vous utilisez une intégration existante, vous devez utiliser les noms des canaux reconnus par l'intégration.

Définir des messages de réponse spécifiques au canal au moment de la conception

Pour fournir des messages de réponse spécifiques au canal pour le traitement lorsque vous utilisez la console:

• Cliquez sur Ajouter un canal après avoir ajouté les messages de réponse par défaut. L'interface utilisateur vous permet d'ajouter des messages de réponse spécifiques aux canaux. Cliquez à nouveau sur Ajouter une chaîne pour ajouter une autre chaîne.

Pour fournir des messages de réponse spécifiques au canal pour le traitement lorsque vous utilisez l'API:

• Définissez le champ Fulfillment.messages[i].channel sur le canal souhaité pour chaque message de réponse. Si ce champ n'est pas défini, la réponse est un message de réponse par défaut.

Utilisation de messages de réponse spécifiques aux canaux au moment de l'exécution

Remarque :Si vous utilisez une intégration existante compatible avec les canaux, l'intégration effectue les étapes ci-dessous.

Pour recevoir un message de réponse spécifique au canal, celui-ci doit être spécifié dans le message de requête d'intent de détection. Consultez le champ queryParams.channel dans la méthode detectIntent du type Sessions. Accéder à la documentation de référence de l'API Session

Sélectionnez un protocole et une version pour la référence de session :

Protocole	V3	V3beta1
REST	Ressource de session	Ressource de session
RPC	Interface de session	Interface de session
C++	SessionsClient	Non disponible
C#	SessionsClient	Non disponible
Go	SessionsClient	Non disponible
Java	SessionsClient	SessionsClient
Node.js	SessionsClient	SessionsClient
PHP	Non disponible	Non disponible
Python	SessionsClient	SessionsClient
Ruby	Non disponible	Non disponible

Fermer

Si aucun canal n'est défini dans une requête ou qu'aucun canal correspondant n'est trouvé dans le traitement, le message de réponse par défaut est renvoyé par Dialogflow.

Modèles de charges utiles personnalisés

Si vous utilisez souvent des charges utiles personnalisées, utilisez des modèles de charges utiles personnalisées. Les charges utiles personnalisées sont parfois volumineuses et complexes. Par conséquent, l'utilisation de modèles peut faciliter le processus de création d'un agent.

Vous pouvez fournir ces modèles dans les paramètres de votre agent, ce qui les rend disponibles lors de la création du fulfillment pour votre agent.

Par exemple, la charge utile JSON pour les boutons "oui" et "non" peut être définie en tant que modèles de charge utile personnalisés. Lorsque vous créez un fulfillment qui nécessite ces boutons, vous ne devez sélectionner le modèle que lors de la création du fulfillment.

Lorsque vous sélectionnez un modèle pour une charge utile personnalisée de traitement, son contenu est inséré dans la charge utile. Vous pouvez ensuite modifier la charge utile si nécessaire.

Si vous modifiez un modèle, la modification n'est pas automatiquement appliquée à toutes les charges utiles de traitement où elle est référencée.

Pour créer un modèle de charge utile personnalisé, consultez les paramètres généraux de l'agent.

Pour sélectionner un modèle de charge utile personnalisé lors de la création du traitement, cliquez sur Sélectionner un modèle.

Appels Webhook

Lorsqu'un fulfillment est appelé et qu'il possède un webhook, l'agent envoie une requête à votre webhook. Le webhook peut effectuer toutes les actions nécessaires dans votre service, fournir un message de réponse dynamique, remplacer les valeurs des paramètres et modifier la page actuelle.

Vous trouverez ci-dessous la description des paramètres de webhook du traitement:

Terme	Définition
Activer le webhook	Cela permet d'activer le webhook pour le traitement.
Webhook	Sélectionnez la ressource de webhook.
Tag	Le tag textuel que vous fournissez ici sera renseigné dans le champ WebhookRequest.fulfillmentInfo.tag de la requête de webhook envoyée à votre service de webhook. Cela permet de contrôler le comportement du webhook de manière spécifique au fulfillment.

Préréglages des paramètres

Vous pouvez utiliser un fulfillment pour fournir des préréglages qui définissent ou remplacent les valeurs de paramètre actuelles. Ces préréglages seront appliqués avant de résoudre les messages de réponse statique ou d'appeler un webhook.

Vous pouvez également utiliser des fonctions système pour prédéfinir le paramètre sur une valeur générée dynamiquement.

Voici quelques exemples :

• Définissez un paramètre now sur l'heure actuelle :

  Paramètre	Valeur
  maintenant	$sys.func.NOW()

• Incrémentez le counter d'un paramètre existant par 1 :

  Paramètre	Valeur
  compteur	$sys.func.ADD($session.params.counter, 1)

• Définissez le paramètre new-cost sur la valeur du paramètre other-cost, tout en conservant la valeur complète de l'objet composite:

  Paramètre	Valeur
  nouveau-coût	$sys.func.IDENTITY($session.params.other-cost)

Paramètres vocaux avancés

Ces paramètres vocaux peuvent éventuellement remplacer les paramètres de synthèse vocale de la page, les paramètres de synthèse vocale du flux et les paramètres de synthèse vocale de l'agent.

File d'attente de réponses

Lors du tour d'un agent, il est possible (et parfois souhaitable) d'appeler plusieurs fulfillments, chacun pouvant générer un message de réponse. Dialogflow conserve ces réponses dans une file d'attente de réponses.

Réponse partielle pour l'API de diffusion

Preview

Ce produit ou cette fonctionnalité est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits et fonctionnalités pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Par défaut, Dialogflow n'envoie les réponses triées à l'utilisateur final qu'une fois le tour de l'agent terminé. Vous pouvez également activer l'option Renvoyer une réponse partielle dans le fulfillment afin de renvoyer des réponses actuellement en file d'attente en tant que réponse partielle lors de l'utilisation des API de diffusion. Pour en savoir plus, consultez la section Cycle de vie d'une page.

Par exemple, si votre webhook est susceptible de s'exécuter pendant une longue période, vous pouvez ajouter une réponse statique dans le fulfillment et activer la réponse partielle. Dialogflow vide la file d'attente de réponses et envoie tous les messages sous forme de réponse partielle avant d'appeler le webhook.

Actuellement, la réponse partielle n'est pas compatible avec les éléments suivants, mais elle le sera ultérieurement:

• Entrées audio dans le simulateur.
• Les intégrations de téléphonie partenaires peuvent être compatibles ou non avec les réponses partielles pour le moment. Consultez la documentation partenaire pour en savoir plus.

Pour tester cette fonctionnalité dans le simulateur, vous devez activer la réponse partielle.

Dans l'exemple suivant, gardez à l'esprit que votre webhook prend 5 secondes à s'exécuter et que la réponse partielle n'est pas activée. Le tour de conversation de l'agent Dialogflow n'est pas terminé tant que le webhook n'est pas terminé. Pendant ce délai de 5 secondes, les réponses sont mises en file d'attente et ne sont renvoyées à l'utilisateur final qu'une fois le tour terminé. Cela nuit à l'expérience utilisateur.

Si vous activez la réponse partielle dans le premier fulfillment, Dialogflow renvoie rapidement le premier message de fulfillment et appelle le webhook. Une fois le webhook terminé, Dialogflow renvoie la réponse finale. L'expérience utilisateur est améliorée dans ce scénario, car l'utilisateur ne doit pas attendre trop longtemps. De plus, l'appel du webhook s'exécute simultanément avec une réponse envoyée à l'utilisateur final.

Langage de balisage de synthèse vocale (SSML)

Vous pouvez utiliser le langage de balisage de synthèse vocale (SSML, Speech Synthesis Markup Language) dans les champs de texte ou de sortie de texte audio de sortie. Vous pouvez ainsi personnaliser votre réponse audio en fournissant des détails sur les pauses et le format audio des acronymes, des dates, des heures, des abréviations ou du texte qui devraient être censurés.

Pour en savoir plus sur la syntaxe, consultez la documentation SSML pour la synthèse vocale.

Remarque :Un champ de traitement ne peut pas comporter plus d'une paire de balises <speak></speak>.