Les métadonnées de messagerie utilisent les champs et les marqueurs de conversation (aussi appelés champs de ticket personnalisés et marqueurs de ticket personnalisés) pour recueillir plus d’informations au sujet du problème, du produit ou du service. Vous pouvez aussi utiliser ces métadonnées pour améliorer le routage des tickets dans l’espace de travail d’agent en créant des déclencheurs dans le Centre d’administration. Vous pouvez ajouter des métadonnées de messagerie à vos tickets et à votre formulaire d’envoi de demande du centre d’aide si vous voulez que les utilisateurs finaux voient les champs personnalisés.
Vous pouvez aussi utiliser les champs et les marqueurs de conversation pour envoyer les métadonnées de messagerie à vos agents à partir du Web Widget et des SDK Zendesk via les API côté client. Cela permet le transfert automatique des informations pertinentes, comme la référence produit, le numéro de confirmation ou l’ID de commande, à l’agent. Ces métadonnées supplémentaires aident à fournir des informations contextuelles complètes et à améliorer la qualité de l’assistance.
- Meilleur contexte pour les agents. Les agents disposent d’informations contextuelles correctes, présentées dans leur vue de l’espace de travail d’agent. Les données manquantes ou les données fournies par l’utilisateur final peuvent induire des erreurs. En fournissant des informations pertinentes de façon programmatique, vous réduisez le risque d’erreurs et le temps passé à demander des informations.
- Routage amélioré. Les entreprises s’appuient sur les informations contenues dans les champs et les marqueurs de ticket pour router rapidement le ticket au bon groupe d’agents. Avec des données plus complètes, ce routage est plus efficace.
- Expérience optimale pour les utilisateurs finaux. Les utilisateurs finaux n’auront plus à saisir à plusieurs reprises des données déjà disponibles côté client.
- Workflows d’automatisation améliorés. Le créateur de bots peut utiliser les données supplémentaires pour créer une meilleure expérience de bot.
- Mêmes fonctionnalités que les SDK Support du Web Widget (Classique), qui prennent en charge les champs et les marqueurs de ticket.
Aperçu des métadonnées de messagerie
Supposons que vous exploitiez une boutique en ligne et qu’un utilisateur final s’intéresse à une paire de chaussures spécifique. Sur cette page, il y a la référence produit, les tailles et les couleurs. Quand l’utilisateur final a des questions au sujet de ces chaussures, l’agent doit connaître les informations ci-dessus pour savoir exactement à quelles chaussures s’intéresse l’utilisateur. Sans les champs de ticket personnalisés, l’agent (ou le bot Zendesk) doit demander toutes ces informations à l’utilisateur final avant de pouvoir répondre à ses questions.
Avec les métadonnées de messagerie, vous pouvez obtenir ces données de façon programmatique à partir de la page ou en demandant à l’utilisateur final de remplir un formulaire, ou encore un mélange des deux. Par exemple, en utilisant un champ de ticket personnalisé, vous pouvez utiliser l’API pour récupérer la référence produit à partir de la page du produit. Comme l’utilisateur final peut sélectionner la couleur et la taille ou non, un bot Zendesk (par exemple) peut les lui demander en utilisant les champs de ticket personnalisés et afficher les valeurs par défaut. L’utilisateur final peut mettre ces valeurs par défaut à jour ou les laisser telles quelles.
- Les utilisateurs finaux n’ont pas à saisir manuellement des données qui existent sur la page qu’ils consultent. Par exemple, si un utilisateur final est dans un formulaire de retour de commande et que l’ID de commande existe sur cette page, vous pouvez récupérer ce numéro de façon programmatique, au lieu de demander à l’utilisateur final de le taper.
- Du contenu supplémentaire peut être ajouté automatiquement pour aider l’agent. Par exemple, si un utilisateur final a ouvert son panier, vous pouvez configurer un champ de conversation « Panier actif » sur vrai.
- Vous pouvez contrôler le chemin que suit un bot. Par exemple, si un utilisateur final est sur une page pour la Marque A, vous pouvez le configurer dans un champ afin que le bot suive le chemin Marque A.
Configuration pour les métadonnées de messagerie
La configuration des champs de conversation se fait dans le Centre d’administration au moment de leur création afin qu’un utilisateur final puisse configurer leurs valeurs. Les marqueurs de conversation ne nécessitent pas d’étapes préalables pour l’API de métadonnées puisse être utilisée.
Pour utiliser les métadonnées de messagerie, vous devez d’abord déterminer les données que vous souhaitez recueillir et la façon dont vous les utiliserez. Cela dépend entièrement de votre cas d’utilisation. Vous devez parfaitement comprendre l’expérience de l’utilisateur final quand votre développeur configure les valeurs de champ et de marqueur de ticket de façon programmatique dans le Web Widget et les SDK Zendesk.
- Un administrateur Zendesk crée un champ de ticket personnalisé et transmet le nom et l’ID de champ à un développeur, en lui indiquant aussi la façon dont il sera utilisé et les données qu’il doit recueillir.
- Un développeur code l’appel à l’API de métadonnées en se servant de l’ID du champ pour connecter la valeur à ce champ.
- Les données sont configurées de façon programmatique dans l’API de métadonnées à l’exécution et sont disponibles lors de la session suivante.
- Les données de champ et de marqueur de ticket sont ajoutées au ticket d’assistance au moment de sa création.
Les métadonnées de champs et de marqueurs de ticket peuvent être configurées n’importe quand avant la création d’un ticket. Elles peuvent être configurées avant la création d’une conversation ou pendant la conversation (même pendant une conversation avec un bot Zendesk). Une fois un ticket créé, il n’y a plus d’« écoute » sur le backend.
Une fois un ticket clos, les métadonnées de messagerie sur le backend (comme les tickets) sont réinitialisées et retrouvent un état nul vide. Actuellement, les métadonnées de messagerie persistent côté client et cela sera résolu dans une version future.
Ajout d’un champ de conversation
Les clients, quelle que soit leur édition Support, peuvent créer des champs de conversation, mais la messagerie doit être configurée et vous devez utiliser le Web Widget et les SDK Zendesk pour la messagerie.
Les champs de ticket système, comme le champ Priorité, ne sont pas pris en charge. Ils s’affichent dans le formulaire de contact par défaut (et tout autre formulaire de ticket) en cas d’accès par le biais du centre d’aide, mais pas dans le Web Widget.
- Dans le Centre d’administration, cliquez sur Objets et règles (
) dans la barre latérale, puis sélectionnez Tickets > Champs. - Cliquez sur Ajouter un champ.
- Sélectionnez un type de champ, puis saisissez un nom d’affichage.
- (facultatif) Saisissez une description pour votre champ personnalisé. Seuls les administrateurs peuvent la voir.
- Sous Permissions, sélectionnez Les clients peuvent apporter des modifications.
Remarque – Comme les valeurs peuvent être configurées via un appel API côté client public, les données doivent toujours être traitées comme si c’était un utilisateur final qui les avait fournies. Il est déconseillé d’utiliser ces API pour les données sensibles.
- Saisissez un titre visible pour les clients.
- Sélectionnez Obligatoire pour résoudre un ticket si l’agent doit remplir le champ pour résoudre le ticket. Cette option n’est pas disponible pour tous les types de champs.
Remarque – Quand les agents fusionnent un ticket, ils n’ont pas besoin de remplir les champs obligatoires, car les tickets fusionnés vont directement au statut Clos sans passer par le statut Résolu. Ce paramètre est aussi ignoré si une règle de gestion change le statut d’un ticket et le configure sur Résolu, car c’est un processus système qui résout le ticket et non un agent.
- Sélectionnez Obligatoire pour envoyer une demande si l’utilisateur final doit remplir ce champ pour envoyer un ticket.
- Configurez les autres options, en fonction du type de champ.
- (facultatif) Spécifiez une valeur par défaut pour le champ personnalisé.
Remarque – L’option par défaut dans une liste déroulante ne s’applique qu’aux nouveaux tickets créés par les agents via l’interface Support ou créés par les utilisateurs partout où s’affiche le formulaire de ticket. Si vous remplacez un formulaire de ticket existant par un formulaire contenant une liste déroulante avec une option par défaut, l’option par défaut ne s’affiche pas et apparaît vide.
- Cliquez sur Enregistrer ou, pour créer un autre champ personnalisé, cliquez sur l’icône de liste déroulante et sélectionnez Enregistrer et ajouter un autre.
- Enregistrez l’ID du champ que vous venez de créer car vous en aurez besoin pour utiliser l’API de métadonnées.
Une fois la création effectuée, les développeurs peuvent utiliser l’API /api/v2/ticket_fields pour voir les données de champ de conversation. Voici un exemple de réponse :
[
{
url: "https://z3n-lhills.zendesk.com/api/v2/ticket_fields/10093547287955.json",
id: 10093547287955,
type: "integer",
title: "Bike Order id",
raw_title: "Bike Order id",
description:
"An API will populate this bike order id value",
raw_description:
"An API will populate this bike order id value",
position: 9999,
active: true,
required: false,
collapsed_for_agents: false,
regexp_for_validation: "\A[-+]?\d+\z",
title_in_portal: "Bike Order Id",
raw_title_in_portal: "Bike Order Id",
visible_in_portal: true,
editable_in_portal: true,
required_in_portal: false,
tag: null,
created_at: "2022-10-04T04:48:05Z",
updated_at: "2022-10-04T04:48:05Z",
removable: true,
agent_description: "Order id from our bikes catalog",
},
]Suppression des valeurs des champs de conversation
Il peut arriver que vous deviez supprimer les valeurs des champs de conversation. Cela dépend de votre cas d’utilisation et a lieu quand les données récupérées ne sont plus valides. Par exemple, supposons que vous utilisez des champs de conversation pour recueillir des données à partir du panier en ligne d’un utilisateur final. Si l’utilisateur final supprime tous les articles de son panier, les données que vous avez recueillies ne sont plus valides et vous pouvez supprimer les valeurs de ces champs de conversation.
Vous utilisez l’API clearConversationFields(
) pour supprimer les valeurs des champs de conversation.
Ajout d’un marqueur de conversation
Les marqueurs sont des mots ou des combinaisons de mots que vous pouvez utiliser pour ajouter plus de contexte aux tickets et aux sujets. Vous pouvez ajouter des marqueurs aux tickets, aux utilisateurs et aux organisations. Vous pouvez, par exemple, marquer toutes les demandes associées aux ventes avec « ventes » ou « info_ventes ». Vous pouvez ensuite créer une vue ou un rapport pour suivre ces demandes.
Pour en savoir plus, consultez À propos des marqueurs.
Utilisation des API de métadonnées
Consultez la section consacrée à l’utilisation des métadonnées de messagerie dans la documentation pour les développeurs afin de voir un exemple d’utilisation des API de métadonnées.
Configuration des champs et des marqueurs de conversation
La configuration des valeurs des champs de conversation se fait à l’aide de l’API setConversationFields. Par exemple, si l’ID de votre champ de ticket personnalisé est 10093547287955 et que vous voulez configurer sa valeur sur 548832222, vous devez appeler :
zE('messenger:set', 'conversationFields', [{ id: ‘10093547287955’, value: ‘548832222’}]);
Si vous utilisez un champ de liste déroulante personnalisé ou n’importe quel champ qui associe une valeur de champ à un marqueur, en configurant la valeur du champ personnalisé, vous configurez aussi la valeur du marqueur personnalisé dans le ticket généré.
| API côté client pour configurer les champs de conversation | |
|---|---|
| Web Widget | zE('messenger:set',
'conversationFields', [{ id: '{field ID}', value:
'{value}'}]) |
| iOS | Zendesk.instance.setConversationFields(["{field ID}” :
“{field ID}"]) |
| Android | Zendesk.instance.setConversationFields(listOf(
TicketField(id="{field ID}", value="{value}"
))) |
| Unity | ZendeskMessaging.Instance.SetConversationFields(Dictionary |
{field ID} doit être une chaîne. Sinon, il sera converti en chaîne. {value} doit être une chaîne, un nombre ou une valeur booléenne.La configuration des valeurs des marqueurs de conversation se fait avec l’API setConversationTags. Comme avec l’API setConversationFields, si vous configurez un marqueur personnalisé associé avec un champ personnalisé modifiable, le champ personnalisé est configuré. Si le marqueur personnalisé est associé avec un champ personnalisé privé (non modifiable), le champ personnalisé n’est pas configuré.
| API côté client pour configurer les marqueurs de conversation | |
|---|---|
| Web Widget | zE('messenger:set',
'conversationTags', ['{tag value}', '{tag
value}']) |
| iOS | Zendesk.instance.setConversationTags(["{tag value}",
"{tag value}"]) |
| Android | Zendesk.instance.setConversationTags(listOf("{tag
value}", "{tag value}")) |
| Unity | ZendeskMessaging.Instance.SetConversationTags(List |
Voici un exemple de réponse utilisant setConversationTags :
conversation: {
...
metadata: {
"zen:ticket:tags": "likes-nike-trainers, frequent-shopper",
},
}Suppression des champs et des marqueurs de conversation
Vous pouvez supprimer les marqueurs et les valeurs des champs de conversation quand le contexte côté client change. Par exemple, l’utilisateur final quitte une page produit et se rend sur la page d’accueil de votre boutique. Les données recueillies à partir de cette page produit ne sont plus valides.
Pour ce faire, utilisez les API ClearConversationFields et ClearConversationTags. Cela supprime tous les champs et les marqueurs de conversation. Vous ne pouvez pas supprimer un champ ou un marqueur individuel.
| API côté client pour supprimer les champs et les marqueurs de conversation | |
|---|---|
| Android |
Zendesk.instance.clearConversationFields()
Zendesk.instance.removeConversationTags()
|
| Unity |
ZendeskMessaging.Instance.ClearConversationFields()
ZendeskMessaging.Instance.ClearConversationTags()
|
Créateur de bots
Les champs mis à jour à l’aide des API de métadonnées seront remplis avec les données existantes et pourront être modifiés par vos clients une fois présentés à cette étape. Pour en savoir plus au sujet de cette interaction, consultez Types d’étapes des workflows de réponse et Création de champs de ticket personnalisés.