Partager via

Collecte des commentaires des utilisateurs dans les scénarios d’appel natif

  • Article

Introduction

En tant que bibliothèque tierce, nous devons reconnaître que les données de diagnostic, cruciales pour la résolution des problèmes, résident sur les appareils mobiles des utilisateurs finaux. Notre modèle de support dépend d’une relation symbiotique : pour aider efficacement vos clients, nous devons nous assurer que vous êtes équipé pour le faire. Cette documentation décrit les méthodologies de collecte des données de diagnostic lorsqu’un utilisateur signale un problème.

Principales préoccupations en matière de développement

  • Collecte en temps opportun : journaux de collecte immédiatement après un problème.
  • Réduire l’effort utilisateur: assurez-vous que l’utilisateur peut facilement signaler des erreurs au sein de votre application.
  • Confidentialité et sécurité: stockez les informations de votre utilisateur en toute sécurité, engagez-vous à donner votre consentement de manière proactive avant de transmettre des données.

Informations importantes à inclure avec les commentaires des utilisateurs

ID d’appel

Chaque appel effectué avec le Kit de développement logiciel (SDK) d’appel a un ID d’appel. Les ID d’appel peuvent être utilisés en interne chez Microsoft pour diagnostiquer les problèmes liés à votre appel. La collecte des ID d’appel est la première ligne du soutien et peut mener à des enquêtes plus rapides.

Dans le Kit de développement logiciel (SDK) d’appel natif et d’interface utilisateur, les API existent pour récupérer les ID d’appel.

Fichiers journaux

Le Kit de développement logiciel (SDK) Native Calling et ses dépendances génèrent des fichiers chiffrés .blog dans un répertoire temporaire. Ces fichiers ne peuvent pas être lus en dehors de Microsoft. Ils sont chiffrés pour des raisons de confidentialité et de conformité. Ces fichiers sont la source de vérité quant à ce qui se passe sur cet appareil particulier avec le Kit de développement logiciel (SDK) natif et ses dépendances. Ces fichiers sont une ressource importante pour les développeurs et les utilitaires de résolution des problèmes au sein de Microsoft.

Les scénarios nécessitant des fichiers .blog doivent être plus rares. Ces fichiers constituent une deuxième ligne de défense importante pour la résolution des problèmes. Nous encourageons les développeurs à les collecter de manière proactive via vos flux de support.

Activation des commentaires du client

Intégration d’outils de commentaires utilisateur

Une fois que vous connaissez les données à collecter, vous devez satisfaire l’article utilisateur suivant.

En tant qu’utilisateur, j’aimerais signaler un problème

Chaque application est libre d’implémenter la prise en charge de l’utilisateur de la manière la mieux adaptée au cas d’usage. Sinon, pour les utilisateurs du KIT de développement logiciel (SDK) d’interface utilisateur, le mécanisme intégré est disponible pour répondre partiellement à l’histoire.

  • Signaler un formulaire de problème: bouton et formulaire, cliquez pour envoyer. La bibliothèque d’interface utilisateur offre une implémentation prête à l’emploi de ce formulaire.
  • Commentaires de fin d’appel: solliciter des commentaires à la fin d’un appel. Le formulaire de commentaires donne à l’utilisateur la possibilité de partager des problèmes qu’il a eu avec l’appel.

Il est essentiel de concevoir ces mécanismes de commentaires avec des invites claires pour le consentement de l’utilisateur, ce qui garantit que les utilisateurs sont pleinement informés des données partagées et de leur objectif. Cette transparence crée une confiance et encourage davantage d’utilisateurs à signaler des problèmes.

Envoi d’informations de support et de commentaires à un serveur

Transmission des informations de support

Une fois que les commentaires sont collectés localement, ils doivent être envoyés à un serveur. L’envoi cible généralement un CRM (Gestion des relations client) ou d’autres outils qui peuvent gérer des tâches telles que le triage, la hiérarchisation et l’affectation de travail pour prendre en charge les spécialistes.

Même si ce document n’est pas destiné à couvrir l’intégralité du site des communications client/serveur et de tous les outils de support ou CRMs possibles, notez les points suivants :

  • Utiliser des protocoles de transmission sécurisés
  • Inclure les journaux et les ID d’appel lors de la création de demandes de support
  • Inclure les informations envoyées par l’utilisateur (message, heure d’erreur, spécifications de l’appareil)
  • Fournissez les informations de suivi de l’utilisateur pour son problème (Options : Notifier dans l’application, l’e-mail, le sms)

Le développeur d’applications est libre de décider comment transmettre ces données à mesure qu’elles quittent l’appareil des utilisateurs finaux et entrent un serveur sur le cloud. Pour obtenir un exemple simplifié, vous pouvez référencer la collecter les commentaires des utilisateurs didacticiel, qui offre des insights sur les implémentations client et serveur de ce processus.

Implémentation dans les applications du Kit de développement logiciel (SDK) et de la bibliothèque d’interface utilisateur appelantes

Pour les développeurs qui utilisent le Kit de développement logiciel (SDK) Appelant ou la bibliothèque d’interface utilisateur ACS, tenez compte des outils et API suivants :

Conclusion

Ce guide met l’accent sur la nécessité de collecter et de transmettre efficacement les données de diagnostic pour une prise en charge efficace des utilisateurs dans les applications appelantes natives. L’utilisation de ces stratégies permet de diagnostiquer et de résoudre rapidement les problèmes des utilisateurs, d’améliorer les performances et la satisfaction des utilisateurs de l’application.