Recherches récentes
Pas de recherche récente

Eric Ypsilantis
Adhésion le 14 avr. 2021
·
Dernière activité le 27 oct. 2021
Suivis
0
Abonnés
0
Activité totale
22
Votes
2
Abonnements
12
APERÇU DES ACTIVITÉS
BADGES
ARTICLES
PUBLICATIONS
COMMENTAIRES DE LA COMMUNAUTÉ
COMMENTAIRES SUR L’ARTICLE
APERÇU DES ACTIVITÉS
Dernière activité effectuée par Eric Ypsilantis
Eric Ypsilantis a créé un article,
Question
Je veux modifier le comportement natif du Web Widget (Classique) en utilisant les API Javascript. J'ai parcouru le Centre d'aide et j'ai trouvé de nombreuses implémentations différentes. Comment combiner ces différents workflows API du Web Widget (Classique) ?
Réponse
La chose la plus importante à savoir est quand vous voulez appliquer les paramètres de votre widget. Certains workflows doivent être exécutés chaque fois qu'un service est mis à jour, d'autres lors de la première connexion ou reconnexion du widget. Cela est illustré par cet exemple simplifié de configuration du service CRM :
Il y a un certain nombre de choses dans le script ci-dessus qui méritent d'être discutées. Tout d'abord, les étapes initiales consistant à masquer le widget puis à l'afficher à la réception d'un message non lu peuvent être omises sans modifier le reste des fonctionnalités du script. Comme ils sont utilisés dès le chargement du widget, ils ont été placés en haut du script. Ce n'est pas strictement nécessaire.
Ensuite, il est intéressant de noter que si certains workflows personnalisés placent un bloc API updateSettings dans un rappel chat:connected , vous pouvez également le placer dans un chat:departmentStatus, et il sera également appliqué quand le widget se connecte (ou se reconnecte) pour la première fois après une session interrompue). Pour cette raison, utilisez le chat:connected
API spécifiquement pour les commandes que vous ne souhaitez exécuter qu'une seule fois, et l'API chat:departmentStatus
API pour les commandes que vous souhaitez exécuter chaque fois que le service spécifié change après le chargement de la page.
Pour en savoir plus sur les différents workflows de l'API du Web Widget (Classique) , consultez ces articles :
- Puis-je configurer le Web Widget (Classique) pour présenter Chat sur ma page Web uniquement quand un service spécifique est en ligne ?
- Puis-je réappliquer le service après la reconnexion d'un visiteur de chat ayant expiré ?
- Comment m'assurer que le formulaire pré-chat est présenté au visiteur s'il expire mais se reconnecte ?
Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.
Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.
Modification le 12 janv. 2023 · Eric Ypsilantis
1
Abonné
2
Votes
0
Commentaire
Eric Ypsilantis a créé un article,
Question
Le workflow de routage à l’aide des déclencheurs décrit dans l’article Acheminement automatique des chats vers les services ne prend pas en compte le statut en ligne d’un service spécifique. Est-il possible d'afficher le Web Widget en ligne pour le chat sur ma page Web uniquement si un certain service est en ligne ?
Réponse
Il n'est pas possible d'afficher le widget en mode natif quand des services spécifiques sont en ligne, mais vous pouvez créer un script personnalisé en utilisant l'API Zendesk. Avec un script personnalisé, vous pouvez configurer le Web Widget (Classique) pour qu'il ne présente Chat que lorsqu'un service spécifique est en ligne. Le script identifiera un changement dans le statut du service du compte et l'API mettra à jour les paramètres du Web Widget (Classique)comme vous le souhaitez, en fonction du statut actuel du service.
Vous trouverez ci-dessous un exemple de script API qui utilise cette méthode. Cet exemple montre le Web Widget comme étant en ligne pour le Chat uniquement lorsque le service CRM est en ligne. Si le statut CRM du service n'est pas En ligne, Chat est supprimé. Quand Chat a été supprimé, seules les autres fonctionnalités activées du Web Widget (Classique) s'affichent pour le visiteur. Par exemple, le formulaire de contact ou la recherche du centre d'aide.
Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.
Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.
Modification le 22 nov. 2022 · Eric Ypsilantis
7
Abonnés
2
Votes
0
Commentaire
Eric Ypsilantis a créé un article,
Question
Quand une session de chat arrive à expiration et que le visiteur demande un nouveau chat, la nouvelle demande de chat ne conserve pas le service affecté lors de la session précédente. Existe-t-il un moyen de réappliquer le service affecté lors du chat précédent ?
Réponse
Il est normal qu'une nouvelle session de chat n'applique pas à nouveau le service automatiquement après l' expiration du délai d'un visiteur. Pour résoudre ce problème, utilisezlerappel de l'APIon chat:connectedpour identifier l'événement de reconnexion et mettez à jour les paramètres utilisateur avecl'APIupdateSettingspour configurer le service de la nouvelle session de chat.
L'API est appliquée quand l'événement de reconnexion se produit après l'expiration du délai d'un visiteur mais avant l'envoi du nouveau message par le visiteur. Cela garantit que le service est affecté à la nouvelle session.
Vous trouverez ci-dessous un exemple de script API qui utilise ces méthodes pour réappliquer le service Panier chaque fois qu'un visiteur se connecte pour la première fois ou se reconnecte à la suite d'une session expirée.
Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.
Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.
Modification le 12 janv. 2023 · Eric Ypsilantis
0
Abonnés
2
Votes
0
Commentaire
Eric Ypsilantis a créé un article,
Question
Quand la connexion de chat d'un visiteur expire mais que la fenêtre ou l'onglet contenant le widget est chargé, puis se reconnecte ultérieurement pour envoyer un nouveau message, le formulaire pré-chat ne lui est pas automatiquement présenté. Est-il possible de demander à un visiteur de toujours voir le formulaire pré-chat dans le Web Widget quand il se reconnecte après expiration d'un délai ?
Réponse
Par défaut, un visiteur ignore le formulaire pré-chat quand il se reconnecte. Forcez l'affichage du formulaire pré-chat en appliquant le script ci-dessous, avant le script du Web Widget (Classique)existant :
Testez votre workflow. Si nécessaire, appliquez ou appliquez à nouveau les paramètres du widget en ajoutant le script ci-dessous après le script que vous avez ajouté :
Cette dernière étape utilise l'API updateSettings pour appliquer ou réappliquer les paramètres du widget. Dans l'exemple ci-dessus, le paramètre Shopping Cart
service est appliqué lorsque le widget se connecte pour la première fois ou est reconnecté. Ce workflow est traité plus en détail dans l'article connexe : Puis-je réappliquer le service après qu'un visiteur du chat dont le délai d'attente a expiré se reconnecte ?
Vérifiez que vous avez correctement configuré cette solution. Vérifiez l'état actuel du widget quand il se connecte. Puis fermez, réinitialisez, puis rouvrez le widget pour être sûr que le visiteur qui se reconnecte s'affiche toujours dans le formulaire pré-chat.
Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.
Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.
Modification le 30 avr. 2024 · Eric Ypsilantis
1
Abonné
2
Votes
0
Commentaire
Eric Ypsilantis a créé un article,
Question
Si un visiteur charge le Web Widget (Classique) avant la fin des horaires d'ouverture , il peut chatter une fois que tous nos agents sont hors ligne pour la journée. Par conséquent, ils créent un chat manqué au lieu d'un message hors ligne. Existe-t-il un moyen de s'assurer que le widget n'autorise pas les demandes de chat pour un service qui est actuellement hors ligne ?
Réponse
Le comportement natif du widget ne doit pas être mis à jour en temps réel car un service spécifique passe hors ligne après son chargement sur une page. Cependant, vous pouvez forcer la mise à jour du widget chaque fois que cela se produit et que le visiteur n'est pas déjà dans une session active utilisant l'API.
Chaque fois que le service de chat a une mise à jour de statut, vérifiez que le nouveau statut est Hors ligne , puis vérifiez si le visiteur est déjà dans une session active. Si le statut de l'agent est Hors ligne et que le visiteur n'est pas dans une session active, utilisez la méthode updateSettings pour supprimer le chat.
Consultez l'exemple ci-dessous qui vérifie si le service CRM est en ligne.
Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.
Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.
Modification le 22 nov. 2022 · Eric Ypsilantis
2
Abonnés
2
Votes
0
Commentaire
Eric Ypsilantis a ajouté un commentaire,
Hi CJ, the script in this article is specifically for setting (and setting again if needed) a single specified department.
Unfortunately there isn't an API to get the prior session's department, which would be required to know which of these 5 departments to use again upon reconnection.
Afficher le commentaire · Publication le 11 août 2021 · Eric Ypsilantis
0
Abonnés
0
Votes
0
Commentaire
Eric Ypsilantis a ajouté un commentaire,
Hi CJ, I would expect to see this "Uncaught ReferenceError: zE is not defined" error if the script in this article is being used without your account-specific widget snippet being in your code first.
Try adding the widget snippet from your account (on the Channels > Widget page in Support) above the script using the widget APIs - your Web Widget will need to be loaded before these zE APIs would work.
Hope this helps!
Afficher le commentaire · Publication le 11 août 2021 · Eric Ypsilantis
0
Abonnés
0
Votes
0
Commentaire
Eric Ypsilantis a ajouté un commentaire,
I'm glad to hear you find the article helpful, @...! You know, I had been asked this before back when I was less dangerous with JavaScript, and didn't think it would be possible given how I'm using the API - but let me ponder this and I'll get back to you here. Is the idea to only show the widget as online if a subset of the departments is online, but then not set the department to use in the widget automatically (let the user choose)?
Afficher le commentaire · Publication le 25 juin 2021 · Eric Ypsilantis
0
Abonnés
0
Votes
0
Commentaire