Justin H

SOMMAIRE

Le 5 mars 2024, de 19h50 UTC à 22h06 UTC, certains clients Talk ont peut-être rencontré des problèmes de connectivité, notamment l’impossibilité de passer, recevoir ou transférer des appels. 

 

Chronologie

21:36 UTC | 13:36 (HEURE DU PACIFIQUE)

Nous étudions les problèmes de connectivité Talk, notamment l’impossibilité de passer, recevoir ou transférer des appels. Prochaine mise à jour dans 15 minutes ou plus tard.

22:06 UTC | 14:06 (HEURE DU PACIFIQUE)

Nos ingénieurs continuent d’enquêter sur les problèmes de connectivité Talk, notamment l’impossibilité de passer, recevoir ou transférer des appels. Prochaine mise à jour dans 30 minutes ou plus tard.

22:32 UTC | 14:32 HEURE DU PACIFIQUE

Notre enquête se poursuit sur les problèmes liés à Talk ayant pour conséquence l’impossibilité de passer, recevoir ou transférer des appels. Prochaine mise à jour dans 1 heure ou quand nous aurons de nouvelles informations à partager.

23:31 UTC | 15:31 HEURE DU PACIFIQUE

Nos ingénieurs ont annulé une modification et nous constatons une reprise de notre côté. Nous continuerons de suivre les performances pendant les 24 prochaines heures et fournirons une mise à jour à ce moment-là.

6 mars - 10h59 UTC | 02:59 heure du Pacifique

La fonctionnalité Talk est entièrement rétablie et le fonctionnement normal de la fonctionnalité Talk est confirmé par les commentaires des clients et notre surveillance interne. Nous vous remercions de votre patience pendant cette période. Cet incident est maintenant résolu.

 

APRÈS LE TEMPS DE

Analyse de la cause

Cet incident semble avoir été causé par un problème de fournisseur d’accès local pour certains clients aux États-Unis.

Résolution

Pour résoudre ce problème, nous avons annulé une modification récente de Talk. Cependant, notre enquête indique une panne du FAI qui correspond plus précisément à la fenêtre d’impact.

Éléments de correction

1. Améliorez la surveillance et les alertes en cas d’échec des appels sortants.
2. Travaillez avec notre fournisseur pour ajuster les seuils d’alerte afin que nous puissions être notifiés plus rapidement dans des situations semblables.
3. Améliorez les documents de dépannage pour évaluer la portée avec plus de précision.

 

POUR EN SAVOIR PLUS

Pour des informations sur le statut actuel de votre Zendesk, consultez notre page de statut du système. Le résumé de notre enquête rétrospective est généralement affiché ici quelques jours après la fin de l’incident. Si vous avez d’autres questions au sujet de cet incident, envoyez un ticket via la messagerie ZBot au sein du Web Widget.

SOMMAIRE

Le 5 mars 2024, de 15h30 UTC à 18h25 UTC, les clients de Sunshine Conversations dans tous les Pods utilisant les canaux de messagerie sociale peuvent avoir subi une interruption de service importante en raison d’une panne chez Meta. Cette panne a essentiellement affecté WhatsApp, ainsi que Facebook Messenger et Instagram, avec une interruption partielle du trafic sortant via ces canaux.

Chronologie

16:30 UTC | 08H30 HEURE DU PACIFIQUE
Nous avons confirmé un problème affectant tous les canaux de messagerie sociale optimisés par Meta, notamment Facebook, Messenger, WhatsApp et Instagram. Nous fournirons une autre mise à jour quand notre fournisseur partenaire aura résolu ce problème.

17:51 UTC | 9:51 HEURE DU PACIFIQUE
Nous commençons à voir la reprise du problème qui affecte l’utilisation de tous les canaux de messagerie sociale optimisés par Meta. Nous continuerons de travailler avec notre fournisseur partenaire et de surveiller la situation jusqu’à résolution complète.

19:15 UTC | 11H15 (HEURE DU PACIFIQUE)
Nous avons le plaisir de vous informer que le problème à l’origine des retards dans les messages entrants et sortants sur tous les canaux de messagerie sociale optimisés par Meta a été résolu et que ces canaux traitent les messages normalement. Nous vous remercions de votre patience pendant que nous travaillions avec notre fournisseur partenaire.

 

APRÈS LE TEMPS DE

Analyse de la cause

Cet incident est dû à un problème avec les services de Meta, affectant spécifiquement l’API WhatsApp Cloud. Meta n’a pas révélé la cause exacte, mais a identifié la perturbation et s’est efforcé de rétablir les services. Pendant ce temps, les systèmes de surveillance de Sunshine Conversations ont détecté un nombre élevé d’erreurs lors des tentatives d’envoi de messages via les canaux concernés.

Résolution

La résolution de l’indisponibilité dépendait entièrement des efforts de reprise et récupération de Meta. Sunshine Conversations a surveillé la situation de près et a fourni des mises à jour aux clients dès que possible. Une fois que Meta a annoncé que les services étaient rétablis, Sunshine Conversations a vérifié que le trafic sortant avait repris à des niveaux normaux et que les messages étaient bien livrés via les canaux de messagerie sociale.

Éléments de correction

1. Améliorez la surveillance de la santé du trafic sortant.
2. Révisez et mettez à jour le plan de réponse aux incidents pour inclure d’autres canaux de communication avec Meta au cas où leur portail d’assistance principal serait indisponible.

 

POUR EN SAVOIR PLUS

Pour des informations sur le statut actuel de votre Zendesk, consultez notre page de statut du système. Le résumé de notre enquête rétrospective est généralement affiché ici quelques jours après la fin de l’incident. Si vous avez d’autres questions au sujet de cet incident, envoyez un ticket via la messagerie ZBot au sein du Web Widget.

SOMMAIRE

APRÈS LE TEMPS DE

Analyse de la cause

Cet incident a été provoqué par un défaut échappé, où le service de traitement des événements a généré des erreurs lors de la tentative d’analyse des événements webhook avec une valeur nulle dans leurs métadonnées.

Résolution

Pour résoudre ce problème, la logique du code a été mise à jour pour que les valeurs nulles dans les objets de métadonnées soient acceptées.  Nous avons continu de surveiller la situation et avons confirmé dans les journaux que les erreurs du Pod 26 ne se produisaient plus après cette modification.

Éléments de correction

1. Mettez à jour la documentation publique de Sunshine Conversation pour accepter les valeurs nulles dans les objets de métadonnées [planifiés]
2. Ajout d’alertes de surveillance supplémentaires pour de telles erreurs

POUR EN SAVOIR PLUS

Pour des informations sur le statut actuel de votre Zendesk, consultez notre page de statut du système. Le résumé de notre enquête rétrospective est généralement affiché ici quelques jours après la fin de l’incident. Si vous avez d’autres questions au sujet de cet incident, envoyez un ticket via la messagerie ZBot au sein du Web Widget.

SOMMAIRE

Le 28 novembre 2023, de 13:14 UTC à 17:14 UTC, l’icône Talk/téléphone a disparu des clients Zendesk Talk utilisant plusieurs pods et certains clients ont vu des rapports Explore indiquant un nombre élevé d’appels manqués. 

Chronologie

APRÈS LE TEMPS DE

Analyse de la cause

Cet incident a été provoqué par un correctif logiciel contenant un défaut échappé qui n’était pas visible pendant le processus de test.  Ce correctif impliquait une variable qui n’était pas toujours disponible pendant le chargement de l’activité vocale, ce qui entraînait le blocage et l’icône d’appel ne s’affichait pas dans les scénarios où des applications tierces étaient installées par les agents.

Résolution

Pour résoudre ce problème, nous avons effectué un rétablissement à la version précédente du logiciel et avons reçu une confirmation de récupération.

Éléments de correction

1. Ajout d’un scénario de test pour vérifier le chargement des icônes d’appel en cas d’applications tierces. [Publication planifiée]
2. Ajout de surveillances et d’alertes en cas d’échec de l’activité vocale. [Publication planifiée]

POUR EN SAVOIR PLUS

Pour des informations sur le statut actuel de votre Zendesk, consultez notre page de statut du système. Le résumé de notre enquête rétrospective est généralement affiché ici quelques jours après la fin de l’incident. Si vous avez d’autres questions au sujet de cet incident, envoyez un ticket via la messagerie ZBot au sein du Web Widget.

SOMMAIRE

Le 16 novembre 2023, de 18h02 UTC à 20h00 UTC, certains clients Support des Pods 13, 17, 19, 23, 28 et 29 ont rencontré des retards, voire un arrêt total de la réception des e-mails entrants. Les délais variaient de 15 à 60 minutes entre l’envoi des e-mails et la création des tickets dans Zendesk via les services gérés par Google.

Chronologie

18:53 UTC | 10:53 (HEURE DU PACIFIQUE)
Nous étudions les rapports d’e-mails entrants qui ne sont pas traités pour les clients qui utilisent les Pods 28 et 29. Nous vous fournirons des informations supplémentaires sous peu.

18:57 UTC | 10:57 (HEURE DU PACIFIQUE)
Nous avons confirmé un problème qui provoque des retards dans le traitement des e-mails entrants pour les clients des Pods 13, 19, 23, 28 et 29. Notre équipe enquête et vous fournirons d’autres mises à jour dès qu’elles seront disponibles.

19:33 UTC | 11:33 (HEURE DU PACIFIQUE)
Notre équipe continue d’enquêter sur le problème responsable des retards de traitement des e-mails entrants sur les Pods 13, 17, 19, 23, 28 et 29. Nous nous efforçons de minimiser l’impact et ne manquerons pas de partager de nouvelles informations dès que possible.

19:54 UTC | 11:54 (HEURE DU PACIFIQUE)
Nous commençons à voir une amélioration du problème responsable des retards de traitement des e-mails entrants sur les Pods 13, 17, 19, 23, 28 et 29. Notre équipe continuera de surveiller pour garantir une récupération complète. 

21:14 UTC | 13:14 (HEURE DU PACIFIQUE)
Nous avons résolu le problème qui causait des retards des e-mails entrants pour les clients sur les Pods 13, 17, 19, 23, 28 et 29, et les e-mails entrants se traitent normalement pour le moment. Nous vous remercions de votre patience pendant notre enquête.

 

APRÈS LE TEMPS DE

Analyse de la cause

Cet incident a été dû au fait que le service Mail Fetcher a rencontré des problèmes de connectivité avec Gmail, perturbant le traitement des messages entrants dans Support et les réponses 302 déplacés de Gmail ont été interprétées comme des échecs par la vérification de l’activité, indiquant à l’orchestration des conteneurs que les Pods n’étaient pas en bonne santé. Cela a amené l’orchestration à remplacer les Pods et à interrompre le traitement des e-mails dans les conteneurs associés, ce qui provoque des retards ou des arrêts des e-mails entrants.

Résolution

Pour résoudre ce problème, le trafic d’e-mails entrants a été rétabli une fois que Gmail a arrêté de bloquer ces vérifications, ce qui a permis aux e-mails entrants de Support de terminer la création des Pods et de recommencer à traiter les e-mails. Peu de temps après, les files d’attente de messagerie entrantes se sont ratées et le trafic a recommencé à fonctionner normalement.

Éléments de correction

1. Améliorez les outils d’implémentation existants pour les contrôles de santé des e-mails. 
2. Créez des alertes supplémentaires. 
3. Ajoutez des lignes de code de correction à des applications spécifiques.

 

POUR EN SAVOIR PLUS

Pour des informations sur le statut actuel de votre Zendesk, consultez notre page de statut du système. Le résumé de notre enquête rétrospective est généralement affiché ici quelques jours après la fin de l’incident. Si vous avez d’autres questions au sujet de cet incident, envoyez un ticket via la messagerie ZBot au sein du Web Widget.

Hey shelley,

I suspect that this could be achieved using a custom attribute to filter out tickets with singular engagements. 

Hello Oanh Chau, 

You should be able to make a report like this in the Support: Tickets Dataset. The screenshot below is a bare bones idea of what metrics and attributes you would need to use: 

The Test Tag Inclusion metric I have here uses the following formula to display only solved tickets with the tags you specify: 

IF (([Ticket status - Unsorted] = "Solved" OR [Ticket status - Unsorted] = "Closed")) 
AND (INCLUDES_ANY([Ticket tags], "your_tag_here"))
THEN [Ticket ID]
ENDIF

You would need to make two custom metrics for your Large and Super Large tags, so they will show as separate columns in your report. 

Hey Bobby Koch, 

The backlog snapshots occur at midnight daily. To view the most current totals for outstanding tickets, we recommend using the Tickets dataset. 

Hey Joel Sandi, 

To answer your first question, you should be able to report on ticket information with an Explore Report using the Guide: Knowledge Capture dataset. There is a set of attributes categorized as "ticket" that allow you to look closer at ticket data from the Knowledge Capture App. 

As for your second question, the articles linked per ticket metric, as well as all the metrics under the "Knowledge Capture" Dashboard tab, are meant to gauge performance metrics of the Knowledge Capture application, primarily. From a business value perspective, the articles linked per ticket metric could show pain points for your staff in your Knowledge Base. I would assume that ideally, you would want this number to be as close to 1 as possible (1 article for each ticket). 

Hey Jacqui, 

Are you using bookmarks to capture the desired time range in this dashboard?