Comment créer des guides de support client avec des captures d'écran

Les meilleurs articles d'aide naissent de tickets. Lorsque la même question revient trois fois en une semaine, un guide de captures d'écran répond à la quatrième plus vite qu'une réponse écrite et donne à chaque agent la même réponse à envoyer.

Cet article montre comment transformer un ticket résolu en guide, produire les captures sur Mac avec Temposhot et remettre le résultat à l'équipe support.

Choisir un problème client résolu

Choisissez un ticket déjà résolu dont la solution est fiable. Rédiger un guide alors que la cause reste floue diffuse une supposition à chaque client qui le lit.

Les bons candidats présentent trois caractéristiques :

• La même solution convient à la plupart des clients qui posent la question.
• La solution comporte plus de deux étapes ou passe par un contrôle difficile à trouver.
• Les agents l'expliquent aujourd'hui en texte libre, chacun à sa manière.

Utilisez les mots du client pour le titre du guide. « Modifier l'e-mail de mon compte » correspond à ce que les utilisateurs saisissent dans la recherche. « Gestion de l'e-mail du compte » ne correspond pas.

Noter les tickets candidats

Comptez les tickets de chaque candidat sur les 30 derniers jours, puis comptez les étapes de la solution. Le volume et la longueur déterminent ensemble l'ordre de priorité. Un problème qui arrive 11 fois par mois avec une solution de 4 étapes économise plus de réponses qu'un problème rare avec une solution de 12 étapes.

La solution pour l'e-mail de facturation arrive en tête pour le volume, et ses étapes sont claires. La réinitialisation à deux facteurs revient aussi souvent, mais elle dépend de vérifications d'identité définies par la politique de support. Rédigez ce guide avec le responsable de cette politique, afin que le guide fasse passer le client par la politique au lieu de la contourner.

Faire confirmer la solution par le responsable de la fonctionnalité

La solution d'un ticket peut n'être qu'un contournement. Avant l'enregistrement, demandez au responsable de la fonctionnalité de confirmer que les étapes correspondent au parcours pris en charge. Inscrivez son nom et la date dans le champ propriétaire du guide. Si le contournement cesse de fonctionner après une mise à jour, une personne identifiée sait à qui le signaler. Si le responsable ne peut pas confirmer les étapes, laissez le ticket ouvert pour le responsable du support et ne publiez pas le guide.

Définir le périmètre d'application du guide

Un guide valide pour une offre et erroné pour une autre génère de nouveaux tickets. Indiquez le périmètre en tête, en une ou deux lignes :

• Offre ou type de compte pour lequel les étapes sont valides.
• Plateforme : web, application de bureau ou application mobile.
• Rôle requis, par exemple propriétaire du compte ou administrateur.
• Éléments que le client doit avoir sous la main, par exemple un numéro de commande.

Si les étapes diffèrent selon la plateforme, rédigez deux guides plutôt qu'un seul avec des embranchements sur chaque page.

Rédiger des guides distincts pour le web et le mobile

Le champ de l'e-mail de facturation se trouve sous Account dans l'application web et sous Profile dans l'application mobile. Un guide unique couvrant les deux parcours oblige le lecteur à parcourir des embranchements sur chaque page. Rédigez deux guides avec la même base de titre, par exemple « Modifier l'e-mail de facturation (web) » et « Modifier l'e-mail de facturation (mobile) ».

Indiquez la plateforme dans le bloc de périmètre de chaque guide. L'agent peut alors envoyer le bon guide dès la première réponse, et le client ne s'engage pas dans le mauvais parcours.

Présenter le périmètre sous forme de tableau

Une condition de périmètre écrite dans une phrase passe facilement inaperçue. Un court tableau en tête du guide rend chaque condition visible. L'exemple ci-dessous couvre le guide de l'e-mail de facturation. La dernière ligne exclut l'usage abusif le plus fréquent du guide.

Chaque ligne répond à une question que l'agent poserait sinon dès la première réponse. La ligne « Non couvert » est la plus importante. Les clients qui la lisent s'arrêtent avant la première étape, et l'agent reçoit un ticket où le type de compte correct est déjà indiqué.

Recréer la solution avec des données de test

Les captures prises sur un compte du personnel montrent des menus que les clients n'ont pas. Les captures prises sur le compte réel d'un client montrent ses données. Utilisez un compte de test sur la même offre, avec des noms fictifs comme « Sample Customer » et un domaine d'e-mail d'exemple.

1. Lancer Action Capture

   Appuyez sur Command+3, sélectionnez Start Action Capture, puis choisissez Specific Window pour le navigateur ou l'application.

2. Commencer là où le client commence

   Partez de l'écran que le client voit après sa connexion, et non d'un lien profond que seul le personnel connaît.

3. Effectuer la solution

   Cliquez sur chaque étape. Chaque clic accepté enregistre la fenêtre juste avant le clic.

4. Terminer l'enregistrement

   Sélectionnez Finish capture dans la barre flottante. Le document s'ouvre dans l'éditeur, avec une page par étape.

Avec Parse clicked elements activé dans Configure, les titres de page commencent par Click "[[element-name]]", avec le libellé du contrôle renseigné. Le guide Action Capture présente tous les réglages.

Utiliser le ticket comme script de test

Le fil du ticket sert de script de test. Copiez la séquence d'actions décrite par le client, y compris les tentatives qui n'ont pas abouti. Une tentative échouée visible dans le ticket indique généralement l'étape qui doit comporter un avertissement. Ajoutez l'avertissement à la page qui précède cette étape, et non à la suivante, afin que le lecteur le voie avant de cliquer.

Préparer le compte de test

La solution doit fonctionner dans l'état du compte décrit par le ticket. Une modification qui dépend d'une facture en attente échoue sur un compte neuf. Préparez donc cet état avant l'enregistrement. La liste ci-dessous couvre les écarts courants.

Vérifiez le niveau de zoom avant la première exécution. Un guide enregistré à 110 pour cent et lu à 100 pour cent place les contrôles à d'autres endroits, et le lecteur ne peut pas faire correspondre la capture à l'écran.

Enregistrer le chemin d'erreur

Certains tickets commencent par une erreur. Enregistrez l'erreur une fois sur le compte de test, au moment où le client la voit. Placez le texte exact de l'erreur dans la description de cette page, et la solution sur la page suivante. Un lecteur qui voit la même erreur peut vérifier qu'il suit le bon guide avant de commencer.

Conservez la page d'erreur dans le guide, même lorsque la solution est courte. Les agents recherchent les textes d'erreur, et une page dont la description contient ce texte se retrouve plus facilement qu'une page qui ne contient qu'une capture.

Enregistrer les raccourcis utiles

L'enregistrement repose sur quelques touches. Les raccourcis ci-dessous couvrent l'enregistrement et la modification.

Décisions de capture et points de contrôle

La plupart des solutions de support comportent un moment où le client doit choisir : une option dans une liste déroulante, un onglet dans les réglages. Donnez à ce moment sa propre page et nommez le choix dans la description.

Certains écrans apparaissent sans clic, comme un état de chargement ou une bannière de confirmation. Appuyez sur Shift+Command+2 (le raccourci de capture manuelle) ou sélectionnez Capture now pour les enregistrer. Un guide sans ces points de contrôle ne permet pas au client de savoir si son dernier clic a fonctionné.

Nommer le choix sur la page

Une page de décision doit indiquer le nom de l'option tel qu'il apparaît à l'écran, ainsi que la condition qui en fait la bonne option. Le tableau ci-dessous présente les problèmes de formulation courants. Les règles de la première colonne s'appliquent à toutes les pages de décision.

Capturer l'état d'attente

Les clients s'arrêtent devant un indicateur de chargement ou un libellé « Processing », puis cliquent à nouveau. Capturez l'état d'attente sur sa propre page, avec une description qui indique la durée de l'attente et ce qu'il ne faut pas faire. Par exemple : « Processing se termine généralement en moins d'une minute. Ne sélectionnez pas Save à nouveau tant que ce libellé est affiché. »

Appliquez la même règle à toute étape qui envoie un e-mail ou modifie une valeur en arrière-plan. Indiquez le délai attendu dans la description de la page, afin que le client sache quand arrêter d'attendre.

Traiter les longues listes déroulantes

Une liste déroulante de plus d'une dizaine d'options ne tient pas dans une seule capture à une taille lisible. Capturez la liste ouverte avec l'option cible visible, puis ajoutez une page qui montre le champ après le choix. Placez le nom de l'option dans le titre de la première page et le résultat dans le titre de la seconde.

Ne comptez pas sur le lecteur pour faire défiler la liste. Si l'option se trouve sous la zone visible, utilisez un recadrage Framing qui conserve l'option, et indiquez-le dans la description, par exemple « Faites défiler jusqu'à Annual, la quatrième option en partant du bas ».

Rédiger chaque étape autour de la prochaine action du client

Réécrivez chaque titre analysé pour indiquer au client ce qu'il doit faire, en commençant par un verbe.

Titre analysé	Titre réécrit
Click "Settings"	Ouvrez Settings
Click "Email"	Sélectionnez le champ Email
Click here	Choisissez votre nouvelle offre

Utilisez Framing (F) avec Focus on action pour zoomer sur le contrôle. Balanced ou Close conservent en général assez de contexte pour un lecteur sur ordinateur portable. Supprimez dans le panneau Pages les pages créées par des clics accidentels.

Nommer le résultat, pas le libellé

Les titres analysés reprennent le libellé du contrôle. Un libellé comme « OK » ou « Submit » ne dit rien du résultat. Réécrivez le titre pour indiquer ce que fait le clic : « Sélectionnez Save pour appliquer la nouvelle adresse e-mail ». Le client sait alors ce qui va changer avant de cliquer.

Vérifiez chaque titre par rapport à l'écran qui suit. Si le titre annonce un résultat que la page suivante ne montre pas, il manque un point de contrôle à cette étape.

Une seule action par étape

Une étape qui indique « Ouvrez Account, sélectionnez Email et saisissez l'adresse » cache deux décisions. Un lecteur qui échoue sur la deuxième action n'a pas de page vers laquelle se tourner. Découpez l'étape en trois : ouvrir Account, sélectionner Email, saisir l'adresse. Chaque étape a alors une seule capture et un seul titre qui lui correspond.

Une exception s'applique. Deux actions que l'écran traite comme une seule unité, comme saisir une adresse et appuyer sur Return, peuvent partager une étape lorsque le résultat est une page unique. Nommez les deux actions dans le titre, par exemple « Saisissez l'adresse et appuyez sur Return ».

Ajouter une vérification claire du succès

Terminez le guide par ce que le client voit lorsque la solution a fonctionné : une bannière, une valeur mise à jour, un e-mail de confirmation. Capturez cet écran et donnez-lui un titre de résultat, par exemple « Votre nouvelle adresse apparaît sous Account ».

Sans vérification du succès, les clients répètent souvent les étapes ou ouvrent un ticket pour confirmer.

L'ordre des pages d'un guide terminé

Le schéma ci-dessous montre l'ordre des pages du guide de l'e-mail de facturation. Chaque case représente une page du document, et les flèches indiquent l'ordre de lecture.

La vérification du succès est la dernière page avant la page d'escalade. Un client qui voit la bannière s'arrête là. Un client qui ne la voit pas arrive à la page d'escalade avec l'écran où il s'est arrêté.

Ajouter les conditions d'escalade et les preuves

Indiquez à partir de quel moment le guide ne suffit plus et que le client doit contacter le support. Décrivez des conditions observables : un message d'erreur, un bouton absent, un débit qui n'a pas changé.

Indiquez au client ce qu'il doit envoyer pour que l'agent n'ait pas à le demander : le texte de l'erreur, l'heure, une capture de l'écran où il s'est arrêté. Demandez-lui de retirer les mots de passe et les numéros de carte avant l'envoi.

Rédiger le bloc d'escalade

L'agent qui reçoit une escalade a besoin de cinq informations sans avoir à les demander : l'identifiant du compte, l'offre, la plateforme, le texte exact de l'erreur et l'heure avec son fuseau horaire. Placez ces informations dans un bloc fixe à la fin du guide. Le client copie le bloc dans son message, et la première réponse de l'agent peut traiter directement le problème.

Mesurer l'effet du guide

Comptez les tickets pour le même problème pendant deux semaines après la publication du guide. L'exemple ci-dessous provient d'un guide sur l'e-mail de facturation qui a remplacé une réponse écrite en texte libre.

Le ticket restant avec une erreur a été transmis à la page d'escalade, ce qui a rendu la réponse brève. Sans le texte de l'erreur, l'agent l'aurait demandé, ce qui ajoute une réponse au fil. Comptez les escalades séparément, car elles révèlent des lacunes du guide et non des lacunes du produit. Examinez chaque escalade dans la semaine suivant son ticket. Une réponse que le guide aurait pu donner est une page à réécrire. Une réponse que le guide ne peut pas donner est une nouvelle ligne de périmètre.

Anonymiser avant la publication du guide

L'anonymisation est la dernière modification avant que le guide n'atteigne le centre d'aide. Suivez l'ordre ci-dessous, afin que la vérification porte sur la taille exportée de chaque page et non sur la vue de l'éditeur.

Tester le guide avec un lecteur neuf

Donnez le guide exporté à une personne qui ne l'a pas rédigé, idéalement un nouvel agent, et demandez-lui d'effectuer la solution sur un compte de test sans aide. Chaque question posée indique une page à réécrire.

Publiez ensuite. Temposhot ne propose ni page hébergée ni intégration. Exportez donc selon la destination : pages PNG ou WebP pour un article du centre d'aide, Export PDF pour une pièce jointe d'e-mail. Le guide d'export des documents présente les formats. Pour choisir entre les deux, consultez Guide PDF ou base de connaissances en ligne.

Chronométrer le test de lecture

Enregistrez le test de lecture comme une session client. Notez l'heure à chaque arrêt, car une longue pause sur une page indique un titre ou une décision à retravailler.

Réécrivez d'abord la page de décision. Dans l'exemple, la question portait sur le remplacement immédiat de l'ancienne adresse par la nouvelle. La réponse a été ajoutée à la description de la page de décision, et le lecteur suivant ne s'y est pas arrêté.

Fixer les conditions du lecteur

Donnez au lecteur le même zoom de navigateur, la même taille de fenêtre et le même état de compte que ceux supposés par le guide. Un lecteur sur une fenêtre plus petite voit une mise en page différente et ne peut pas faire correspondre la première capture. Le test échoue alors pour une raison que le guide peut corriger. Indiquez la taille de la fenêtre dans le bloc de périmètre lorsque la mise en page en dépend.

Organiser les guides pour le centre d'aide

Rangez chaque guide dans un dossier nommé avec les mots du client, afin que le nom du dossier corresponde à ce que le lecteur saisit dans la recherche. Conservez les pages PNG avec le PDF dont elles proviennent, pour que la paire soit facile à remplacer ensemble.

Utilisez des numéros d'étape dans les noms de fichiers PNG, afin que les pages se trient dans l'ordre de lecture lorsque le dossier s'ouvre dans le Finder.

Questions fréquentes

Combien d'étapes un guide de support doit-il comporter ?

Autant que la solution en demande, avec une action par étape. Si un guide dépasse une dizaine d'étapes, vérifiez s'il couvre deux problèmes.

Les guides de support doivent-ils utiliser de vraies captures de clients ?

Non. Reproduisez la solution avec un compte de test. Les vraies captures de clients contiennent des données personnelles et peuvent montrer des réglages propres à ce client.

Comment garder les guides de support à jour ?

Attribuez à chaque guide un responsable et une date de dernière vérification, et revérifiez-le lorsqu'une mise à jour touche ces écrans. Consultez comment maintenir la documentation par captures d'écran à jour.

Le guide remplace-t-il la réponse au ticket ?

Non. Le guide remplace la partie répétitive de la réponse. L'agent confirme toujours l'état du compte et ajoute les détails que le guide ne couvre pas, comme une décision de remboursement.

Comment savoir qu'un guide correspond encore au produit ?

Vérifiez le guide lorsqu'une mise à jour touche ses écrans, et refaites le test de lecture après toute modification d'une page de décision. Un changement de libellé de bouton ou de position dans un menu compte comme une modification du guide.

Qui est responsable du guide après publication ?

La personne indiquée dans le champ propriétaire du guide en est responsable. Elle répond aux retours des lecteurs, réécrit les pages qui ont provoqué des escalades et retire le guide lorsque la fonctionnalité change. Un dossier partagé du centre d'aide n'attribue pas de responsable à lui seul.

Où les lecteurs doivent-ils envoyer leurs retours ?

Indiquez le canal de support sur la dernière ligne du guide. Les captures ne peuvent pas répondre. Un lecteur qui a une question a donc besoin d'un moyen d'atteindre une personne.

Quand un guide doit-il être retiré ?

Retirez un guide lorsque la fonctionnalité qu'il décrit change, ou lorsque le nombre de tickets reste à zéro pendant trois mois alors que la fonctionnalité existe toujours. Retirez le guide du centre d'aide et conservez les fichiers exportés dans un dossier d'archive daté. Un guide retiré qui reste consultable renvoie les lecteurs vers des étapes qui n'existent plus.

Transformez vos clics en guide pas à pas clair

Action Capture enregistre la solution une seule fois et produit un guide ordonné à modifier et à exporter. Téléchargez Temposhot et transformez votre ticket le plus répétitif en guide.