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 CX conserve ces réponses dans une file d'attente de réponses. Une fois le tour de l'agent terminé, Dialogflow CX envoie les réponses triées à l'utilisateur final.

Cas d'utilisation du fulfillment

Le fulfillment vous permet de fournir des messages de réponse aux emplacements suivants :

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

Capture d'écran de fulfilment

Réponses de l'agent (options de dialogue)

Définissez les messages de réponse de l'agent au moment de la conception lorsque vous créez 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 suivantes. Dans la console, le panneau de fulfillment comprend une fiche Agent dialogue initiale. Vous pouvez ensuite cliquer sur Add dialogue response pour ajouter d'autres fiches pour les autres types de messages de réponse.

Réponse texte statique

Les messages de réponse texte statique fournissent un dialogue textuel à l'utilisateur. Si vos appels d'API de détection d'intent ou votre intégration utilisent la synthèse vocale, ce texte génère du contenu audio. Pour ces messages, le texte fourni utilise le langage de balisage de synthèse vocale (SSML).

Vous pouvez définir plusieurs fiches de réponse texte et plusieurs réponses texte 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 sélectionné 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 doivent être 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 CX Messenger.

Vous pouvez inclure des références de paramètres dans votre fichier JSON de charge utile personnalisée. Placez-les entre guillemets doubles pour les traiter comme des valeurs de chaîne JSON. Exemple :

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

La charge utile JSON personnalisée doit être limitée à 24 niveaux de profondeur.

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

Pour en savoir plus, consultez la section Modèles de charges utiles personnalisées.

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 CX 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 toutes les actions nécessaires au transfert de la conversation. Comme Dialogflow CX n'impose aucune structure à ces données, vous pouvez choisir celle qui convient le mieux à 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 CX a réussi. Dialogflow CX utilise 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 toutes les actions nécessaires. Dialogflow CX n'impose aucune structure à ces données. Vous pouvez donc choisir celle qui convient le mieux à 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 d'une intégration à l'autre. Par exemple, consultez les exigences concernant la passerelle de téléphonie Dialogflow CX.

Pour les intégrations de téléphonie partenaires, le partenaire doit pouvoir accéder à l'URL du fichier audio. Une URL accessible au public, telle qu'un fichier public dans Cloud Storage, est toujours accessible par le partenaire. Le partenaire peut également fournir un accès limité aux fichiers audio. Pour en savoir plus, consultez la documentation du partenaire.

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 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. Idéalement, vous devez utiliser du texte ou du SSML de manière cohérente.

Réponse conditionnelle

Ce type de réponse fournit des réponses conditionnelles :

Le format général est :

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

où :

  • [condition] utilise le même format que 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 en savoir plus, consultez la section Fonctions système et conditions de routage. La [condition] est résolue en fonction de l'état de la session au début du fulfillment. Si la [response] dépend de l'état de la session, elle est résolue en fonction de l'état de la session mis à jour à la fin du fulfillment.

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, cette partie est mise à jour dans toutes les langues de l'agent. Comme elle devient une nouvelle condition, [response] est effacée pour toutes les langues autres que celle que vous avez sélectionnée lors de la mise à jour de [condition].

Transfert d'appel téléphonique

Les transferts d'appel ne sont disponibles que pour la passerelle de téléphonie Dialogflow CX.

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

Réponse de l'outil de datastore

Ce type de réponse configure les réponses de l'agent renvoyées par les outils de datastore associés. Si vous avez configuré un outil de data store dans ce fulfillment, une fiche de réponse d'outil de data store est renseignée automatiquement.

  • Liens sources : définissez le nombre maximal de citations à renvoyer à l'utilisateur après la réponse. Une citation est un lien vers la source d'informations dans le data store, affiché sous forme de boutons. La valeur par défaut est 1.
  • Citations intégrées : limitez le nombre de citations intégrées renvoyées par phrase au lieu de lister les liens après la réponse.
  • Remplacement génératif : configurez l'agent pour qu'il tente une réponse générée par l'IA si le data store renvoie un résultat vide. Si cela échoue, l'agent utilise des réponses statiques.
  • Réponses statiques : saisissez des réponses texte statiques dans le champ final à envoyer à l'utilisateur mot à mot.

Messages de réponse spécifiques à un canal

Lorsque vous définissez un fulfillment, vous pouvez créer des messages de réponse spécifiques à un canal pour créer des réponses ciblées pour le chat textuel, la voix, les SMS ou des intégrations spécifiques compatibles avec les canaux. 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 CX sélectionne le message de réponse par défaut ou un message de réponse spécifique à un canal lorsqu'une requête de détection d'intent spécifie un canal. Il est recommandé de définir des messages de réponse par défaut, même si vous utilisez des messages de réponse spécifiques à un canal. Les messages de réponse par défaut servent de solution de secours lorsque votre système ne parvient pas à fournir un canal valide.

Un nom de canal est un champ personnalisé que vous pouvez définir sur n'importe quel texte. Si vous utilisez directement l'API Dialogflow CX pour les appels d'exécution, vous pouvez utiliser les noms de canal de votre choix. Si vous utilisez une intégration existante, vous devez utiliser les noms de canal que l'intégration reconnaît.

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

Pour fournir des messages de réponse spécifiques à un canal pour le fulfillment lorsque vous utilisez la console :

  • Cliquez sur Add channel (Ajouter un canal) après avoir ajouté des messages de réponse par défaut pour ajouter des messages de réponse spécifiques à un canal. Cliquez à nouveau sur Add channel (Ajouter un canal) pour ajouter d'autres canaux.

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

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

Utiliser des messages de réponse spécifiques à un canal au moment de l'exécution

Si vous utilisez une intégration existante compatible avec les canaux, l'implémentation de l'intégration effectue ces étapes.

Pour recevoir un message de réponse spécifique à un canal, vous devez spécifier le canal dans le message de requête de détection d'intent. Consultez le champ queryParams.channel dans la méthode detectIntent du type Sessions.

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

Dialogflow CX renvoie le message de réponse par défaut si une requête ne définit aucun canal ou si le fulfillment ne trouve aucun canal correspondant.

Modèles de charges utiles personnalisées

Si vous utilisez des charges utiles personnalisées souvent, utilisez des modèles de charges utiles personnalisées. Les charges utiles personnalisées sont parfois volumineuses et complexes. L'utilisation de modèles simplifie donc le processus de création d'agents.

Fournissez ces modèles dans les paramètres de votre agent pour les rendre disponibles à la sélection lors de la création d'un fulfillment pour votre agent.

Par exemple, la charge utile JSON pour les boutons "Oui" et "Non" peut être définie comme des modèles de charges utiles personnalisées. Lorsque vous créez un fulfillment qui nécessite ces boutons, sélectionnez le modèle lors de la création du fulfillment.

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

Si vous modifiez un modèle, les modifications ne sont pas automatiquement propagées à toutes les charges utiles de fulfillment où il est référencé.

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

Pour sélectionner un modèle de charge utile personnalisée lors de la création d'un fulfillment, cliquez sur Select template (Sélectionner un modèle) lorsque vous créez une charge utile personnalisée de fulfillment.

Appels Webhook

Lorsqu'un fulfillment déclenche un webhook, l'agent envoie une requête à votre service. Votre webhook peut effectuer des actions, fournir des messages de réponse dynamiques, remplacer les valeurs des paramètres et modifier la page actuelle.

Les paramètres de webhook pour le fulfillment sont décrits ci-dessous :

X Élément
Activer le webhook Cela active le webhook pour le fulfillment.
Webhook Sélectionnez la ressource webhook.
Tag Le tag de texte que vous fournissez ici sera renseigné dans le champ WebhookRequest.fulfillmentInfo.tag de la requête webhook envoyée à votre service webhook. Cela peut être utilisé pour contrôler le comportement du webhook d'une manière spécifique au fulfillment.
Renvoyer une réponse partielle Permet d'annuler la lecture d'une réponse partielle. Pour en savoir plus, consultez la section Paramètres vocaux avancés.

Préréglages des paramètres

Utilisez le fulfillment pour fournir des préréglages qui définissent ou remplacent les valeurs de paramètre actuelles. Ces préréglages sont 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 un 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 un paramètre new-cost sur la valeur de 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)

Outils de datastore

Pour en savoir plus sur cette fonctionnalité, consultez la documentation sur les outils de datastore.

Paramètres vocaux avancés

Ces paramètres vocaux avancés peuvent remplacer les paramètres vocaux de la page, paramètres vocaux du flux, et paramètres vocaux de l'agent.

File d'attente de réponses

Lors du tour d'un agent, vous pouvez appeler plusieurs fulfillments, chacun pouvant générer un message de réponse. Dialogflow CX conserve ces réponses dans une file d'attente de réponses.

Réponse partielle pour l'API de diffusion

Par défaut, Dialogflow CX n'envoie les réponses triées aux utilisateurs finaux qu'une fois le tour de l'agent terminé. Vous pouvez également activer l'option Return partial response (Renvoyer une réponse partielle) dans le fulfillment afin de renvoyer des réponses en file d'attente en tant que réponse partielle lorsque vous utilisez les 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 CX vide alors la file d'attente de réponses et envoie tous les messages sous forme de réponse partielle avant d'appeler le webhook.

La réponse partielle n'est pas compatible avec les éléments suivants :

Pour tester cette fonctionnalité dans le simulateur, activez la réponse partielle.

Capture d'écran de réponse partielle dans le simulateur

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 CX 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.

Sans réponse partielle.

Si vous activez la réponse partielle dans le premier fulfillment, Dialogflow CX renvoie rapidement le premier message de fulfillment et appelle le webhook. Une fois le webhook terminé, Dialogflow CX renvoie la réponse finale. Ce scénario améliore l'expérience utilisateur, 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.

Avec réponse partielle.

Langage de balisage de synthèse vocale (SSML)

Vous pouvez utiliser le langage de balisage de synthèse vocale (SSML) dans les champs de fulfillment de texte ou de texte audio de sortie. Cela vous permet de personnaliser votre réponse audio en fournissant des informations sur les pauses et le formatage audio pour les acronymes, les dates, les heures, les abréviations ou le texte à censurer.

Pour en savoir plus sur la syntaxe, consultez la documentation SSML Text-to-Speech.

Précédent
Paramètres
Suivant
Webhooks