Concevoir un parcours de secours WebChat lorsque le chat est indisponible ou difficile à utiliser
Un parcours de secours WebChat est un service d’assistance défini pour les personnes qui ne peuvent pas, ne veulent pas ou ne devraient pas avoir à accomplir leur tâche dans le chat. Découvrez comment le rendre accessible, attribué, testable et respectueux de la vie privée.
Un parcours de secours fait partie du service, ce n’est pas un lien de contact de dernier recours
Un parcours de secours WebChat est la voie concrète qu’un client peut emprunter lorsque le chat intégré est indisponible, inaccessible, inadapté à la tâche ou simplement lorsqu’il ne constitue pas sa manière préférée d’obtenir de l’aide. Il doit mener à un service capable de faire réellement avancer le problème du client, plutôt qu’à une page générique qui relance son parcours depuis le début.
Ce point va au-delà du handicap. Certaines personnes peuvent ne pas disposer d’un accès internet fiable, de la confiance, des compétences, de la confiance envers le numérique ou de la motivation nécessaire pour réaliser une tâche en ligne. Une opération d’assistance doit prévoir ces circonstances comme des conditions normales de service, et non comme des cas exceptionnels.
Placez la solution de secours là où le besoin survient : à côté du lanceur ou du point d’entrée du chat, dans les états d’erreur du chat, aux étapes comportant beaucoup de friction et dans la transaction concernée. Utilisez le même emplacement relatif et le même libellé chaque fois que le mécanisme d’aide se répète, afin que les clients puissent le trouver de façon prévisible.
- Traitez cette voie comme un service pris en charge, avec une destination, un responsable, des horaires et un processus de traitement.
- Rendez-la disponible avant qu’un client ait terminé un parcours de chat ou communiqué des informations inutiles.
- Indiquez clairement les alternatives disponibles, comme le téléphone, un formulaire web accessible, une demande de rappel ou une voie de service en personne spécifique.
- Ne faites pas du chat le seul moyen de signaler un problème lié au chat lui-même.
Cartographier les situations où le chat peut échouer ou devenir difficile à utiliser
Commencez par une cartographie des défaillances de bout en bout. Un widget peut ne pas se charger ; il peut se charger mais être difficile à utiliser au clavier ; un client peut être bloqué par l’authentification, l’envoi de fichier, la validation ou une réponse automatisée ; ou la conversation peut atteindre une file sans personne compétente disponible. Chaque point doit avoir une étape suivante définie.
Distinguez les défaillances auxquelles votre équipe web peut se préparer par la conception des conditions qu’elle ne peut pas entièrement maîtriser. Votre équipe contrôle la visibilité et l’accessibilité de la voie alternative, le libellé, la conception du formulaire, les données collectées, les règles de routage et la politique de dotation. La prise en charge du navigateur, les conditions réseau et la disponibilité de canaux tiers peuvent influer sur l’expérience, mais ils ne suppriment pas le besoin d’une alternative utilisable.
Intégrez le choix du client dans la cartographie. Une personne qui indique préférer appeler, avoir besoin d’un interprète ou ne pas pouvoir continuer en toute sécurité dans le chat n’est pas une conversion échouée. Elle demande une voie de service adaptée.
- Le widget n’apparaît pas parce que les scripts sont bloqués, que la connexion est lente ou que le navigateur n’est pas pris en charge.
- Le lanceur, les commandes, le déplacement du focus ou la saisie des messages ne peuvent pas être utilisés efficacement avec un clavier ou une technologie d’assistance.
- La connexion, les contrôles d’identité ou les processus de code à usage unique empêchent la progression.
- L’envoi de fichier, la validation de saisie ou le retour après soumission est peu clair ou échoue de manière répétée.
- L’automatisation ne comprend pas la demande, ne peut pas valider une réponse ou rencontre un cas hors périmètre.
- Aucun agent formé n’est disponible pendant le créneau nécessaire au client.
- Le problème nécessite un canal dont les capacités ne peuvent pas être fournies de manière sûre par le chat, comme un rendez-vous spécifique au service ou une assistance en personne.
Définir une norme minimale pour chaque voie de secours
Utilisez quatre critères : visible, compréhensible, utilisable et disponible. Un client doit pouvoir voir la voie sans terminer le chat, comprendre ce qui se passera ensuite, l’utiliser sans pointeur ni obstacle inutile, et atteindre un service réellement doté en personnel ou offrant un résultat clair hors horaires d’ouverture.
Pour un formulaire de secours accessible, demandez uniquement ce qui est nécessaire pour traiter la demande d’assistance. Donnez à chaque contrôle un libellé visible qui lui est associé, fournissez des instructions lorsque nécessaire et ne vous appuyez pas sur le texte indicatif pour communiquer les informations requises. En cas d’erreur, identifiez le champ concerné, expliquez le problème et la correction à apporter, et créez un lien vers le champ lorsque cela est approprié.
Testez les formulaires côté serveur ainsi que dans le navigateur. Les contrôles côté client peuvent être contournés et la prise en charge varie selon les navigateurs. Après l’envoi, fournissez une confirmation non ambiguë que la demande a été reçue, ou un résultat d’erreur clair ainsi qu’une voie permettant de continuer si l’envoi ne peut pas être terminé.
- Clavier : tous les contrôles de parcours, champs et actions d’envoi fonctionnent sans souris, et le focus visible reste apparent.
- Zoom et réorganisation : à une largeur équivalente à 320 pixels CSS, aucune information ni fonction n’est perdue et une utilisation ordinaire ne nécessite pas de défilement bidimensionnel.
- Authentification : n’exigez pas de test de fonction cognitive à moins qu’une méthode alternative ou un mécanisme d’assistance soit disponible.
- Retour : les messages de réussite, d’échec et d’étape suivante sont clairs et exposés de manière accessible.
- Cohérence : les voies d’aide répétées apparaissent dans un emplacement relatif cohérent sur les pages concernées.
Choisir une voie adaptée à la tâche et au client
Il n’existe pas d’alternative universellement correcte. Sélectionnez les voies en fonction de la recherche utilisateur, du risque de service et de la capacité opérationnelle. Le téléphone peut être préférable pour les problèmes urgents ou complexes ; une demande de rappel peut réduire le temps d’attente ; un formulaire accessible convient aux cas non urgents nécessitant une trace écrite ; et une voie en personne ou spécifique au service peut être nécessaire lorsqu’un client a besoin d’une assistance pratique.
Ne publiez pas une voie simplement parce qu’elle existe ailleurs dans l’organisation. Vérifiez qu’elle accepte le type de problème concerné, qu’une équipe le reçoit, qu’elle protège les informations client et qu’elle peut communiquer une issue. Une solution de secours qui aboutit à une boîte aux lettres non surveillée crée une seconde défaillance.
Lorsque le chat et la solution de secours font partie du même processus, évitez de demander aux clients de répéter des informations qu’ils ont déjà fournies. Sous réserve de contrôles de confidentialité appropriés, les informations nécessaires à nouveau doivent être disponibles à la sélection ou préremplies. Ne transférez pas automatiquement des informations sensibles simplement parce qu’elles ont été saisies dans le chat.
- Téléphone : utilisez-le pour les questions urgentes, sensibles ou très complexes ; publiez les horaires d’appel et les dispositifs d’accessibilité lorsqu’ils s’appliquent.
- Formulaire web accessible : utilisez-le pour les demandes structurées et non urgentes ; fournissez une référence ou une confirmation après un envoi réussi.
- Demande de rappel : utilisez-la lorsque les clients ne devraient pas avoir à attendre dans une file ; recueillez une méthode de contact adaptée et uniquement les informations de planification nécessaires.
- Voie en personne ou spécialisée : utilisez-la lorsqu’une tâche requiert une assistance locale, pratique ou réglementée.
- Voie d’urgence ou de protection : distinguez-la de l’assistance ordinaire lorsque cela est pertinent, avec un libellé et une responsabilité approuvés par l’équipe de service compétente.
Rédiger un texte qui donne l’étape suivante sans faire de promesses impossibles à tenir
Le texte de secours doit reconnaître la situation, indiquer l’action disponible et expliquer ce qui se passe ensuite. Évitez de blâmer le client, le jargon technique et les formulations vagues telles que « réessayez plus tard » sans autre choix. Évitez les promesses de délai de réponse, sauf si l’équipe responsable peut les respecter de manière fiable et a approuvé le texte.
Utilisez un texte propre à chaque canal. Une option téléphonique nécessite un numéro et des horaires. Une demande de rappel nécessite le mécanisme de confirmation attendu et d’éventuelles restrictions. Un formulaire nécessite une indication de ce que le client peut soumettre et un message de réussite clair. Un état hors horaires d’ouverture doit proposer la prochaine action disponible, et non une impasse.
- Exemple de message d’échec du widget : « Le chat n’est pas disponible pour le moment. Vous pouvez demander de l’aide à l’aide de notre formulaire accessible ou appeler le [numéro] pendant les [horaires]. »
- Exemple de sortie d’automatisation : « Je n’ai pas pu résoudre ce problème dans le chat. Choisissez « Demander l’aide d’une personne » pour envoyer vos informations à l’équipe d’assistance, ou utilisez [voie alternative]. »
- Exemple de confirmation de formulaire : « Votre demande a été reçue. Conservez cette confirmation pour vos dossiers. Si votre problème est urgent, appelez le [numéro]. »
- À éviter : « Nous vous répondrons prochainement », à moins que « prochainement » ait une signification opérationnelle définie et suivie.
Transmettre le contexte avec précaution, avec des limites de consentement et de vérification
Le transfert de contexte peut réduire l’effort du client, mais il doit être proportionné. Définissez un dossier de transfert minimal pour chaque voie de secours : la catégorie du problème, un bref résumé rédigé par le client, l’étape du parcours, la référence de dossier pertinente et le moyen de contact préféré peuvent suffire. Identifiez ce qui n’est jamais copié automatiquement, comme les pièces jointes inutiles, le texte libre sensible ou les identifiants.
Indiquez aux clients ce qui sera envoyé à l’équipe suivante et donnez-leur la possibilité de le vérifier ou de le modifier lorsque cela est approprié. Si un autre service, système ou objectif est impliqué, les responsables de la protection de la vie privée doivent déterminer si un nouveau consentement, un nouvel avis ou une autre base légale est nécessaire. Une voie de secours ne justifie pas de collecter plus de données que la tâche ne l’exige.
Le personnel destinataire doit vérifier l’identité via le processus approuvé par l’organisation avant de divulguer des informations de compte ou d’agir sur des demandes sensibles. Une référence de dossier peut aider à retrouver le travail ; elle ne constitue pas automatiquement une preuve d’identité.
- Définissez les champs minimaux de transfert et la règle de conservation pour chaque voie.
- Ne demandez jamais aux clients d’envoyer des mots de passe, codes d’authentification ou autres identifiants par chat ou par formulaire de secours.
- Conservez une explication destinée au client sur les informations transférées et leur raison.
- Ne permettez au personnel de voir la conversation d’origine que lorsque son rôle et le dossier l’exigent.
- Prévoyez une voie manuelle lorsque le contexte ne peut pas être transféré de manière sûre ou techniquement possible.
Créer des sorties explicites de l’automatisation et une voie d’escalade humaine
L’automatisation doit proposer une voie de sortie avant que la frustration ne mène à l’abandon. Définissez les déclencheurs d’une voie assistée : intention mal comprise à plusieurs reprises, échecs répétés de réponse validée, demande explicite d’une personne, sujet à haut risque, demande hors périmètre ou flux automatisé incapable d’accomplir une étape requise.
La voie d’escalade doit nommer une file de réception ou un canal alternatif, et non simplement afficher un message rassurant. Définissez ce que l’automatisation transmet, ce que les clients doivent faire ensuite et ce qui se passe si personne n’est actuellement disponible. Lorsqu’un transfert ne peut pas être doté en personnel, proposez à la place la voie approuvée de rappel, de formulaire ou de téléphone.
Le jugement humain reste nécessaire pour les exceptions, les demandes ambiguës, les réclamations, les indicateurs de vulnérabilité et les cas où la politique ou la sécurité exigent un examen. Le personnel a besoin d’instructions pour accepter, réacheminer et clôturer les demandes de secours, y compris lorsqu’une demande est arrivée dans le mauvais service.
- Déclencheur : le client sélectionne « parler à une personne » ou l’équivalent ; action : proposer un transfert vers une équipe disponible ou une voie alternative clairement identifiée.
- Déclencheur : deux tentatives infructueuses ou plus pour obtenir la même réponse validée ; action : expliquer le blocage et proposer de l’aide sans imposer une nouvelle tentative.
- Déclencheur : problème sensible, urgent ou défini par la politique ; action : désactiver l’automatisation inadaptée et orienter vers la voie de service responsable.
- Déclencheur : hors horaires d’ouverture ; action : afficher la disponibilité actuelle et la prochaine action prise en charge, sans laisser entendre qu’une aide en direct est présente.
Attribuer les responsabilités entre files, horaires et services
Chaque demande de secours doit avoir un responsable désigné, de sa réception à sa résolution. Cartographiez le modèle opérationnel par type de demande, canal, équipe interne, horaires de couverture, contact d’escalade et norme de clôture. Distinguez l’équipe responsable de la présentation sur le site web de celle responsable du résultat de service ; elles peuvent ne pas être les mêmes.
Une boîte de réception partagée peut être utile lorsque les conversations WebChat et WhatsApp nécessitent une gestion coordonnée, mais toutes les solutions de secours ne doivent pas entrer dans le même espace de travail. Le téléphone, les voies en personne et les voies spécialisées peuvent disposer de systèmes et de contrôles distincts. Ce qui importe est un transfert documenté et un moyen d’identifier les demandes qui n’ont pas reçu de réponse responsable.
Planifiez les variations de demande, la couverture par du personnel formé, la protection de la vie privée et les boucles de retour. Si une voie est indisponible en dehors des heures de fonctionnement, définissez et testez le libellé hors horaires et la responsabilité des demandes reçues à ce moment-là.
- Nommez un responsable du service, un responsable opérationnel de file et un responsable d’escalade pour chaque voie.
- Documentez les horaires d’ouverture, la couverture linguistique, la couverture spécialisée et la gestion hors horaires d’ouverture.
- Définissez des règles de routage pour les demandes destinées à la mauvaise équipe, les doublons, les demandes incomplètes et les demandes urgentes.
- Fournissez au personnel des modèles, des instructions de vérification et une voie claire pour les préoccupations d’accessibilité ou de confidentialité.
- Examinez les demandes non résolues et les schémas de défaillance récurrents avec les équipes capables de les corriger.
Questions fréquentes
Qu’est-ce qu’un parcours de secours WebChat ?
Il s’agit d’une voie d’assistance alternative définie pour les clients qui ne peuvent pas, ne veulent pas ou ne devraient pas avoir à accomplir leur tâche dans le chat intégré. Elle comprend la voie visible par le client, l’équipe destinataire, les horaires de fonctionnement, les contrôles de confidentialité et le processus de résolution.
Une page de contact générique suffit-elle lorsque WebChat est indisponible ?
En général, non. Une page de contact générique peut ne pas identifier le problème concerné, proposer une méthode accessible, préserver le contexte nécessaire ou atteindre une équipe capable d’agir. Une solution de secours utile indique exactement aux clients quoi faire et les connecte à une voie de service dont la responsabilité est attribuée.
Quelles informations un formulaire de secours doit-il recueillir ?
Recueillez uniquement les informations nécessaires au traitement de la demande, telles que la catégorie du problème, une description concise, un moyen de contact sûr et une référence pertinente. Utilisez des libellés visibles, des instructions claires, des messages d’erreur accessibles et une validation côté serveur. Ne demandez pas de mots de passe ni de codes d’authentification.
Comment l’automatisation doit-elle escalader vers une personne ?
Définissez des déclencheurs explicites, notamment une demande directe d’aide humaine, des échecs de validation répétés, des incompréhensions répétées, des sujets à haut risque et des demandes hors périmètre. Le déclencheur doit mener à une file dotée en personnel lorsqu’elle est disponible, ou à une voie de téléphone, rappel ou formulaire clairement identifiée lorsqu’elle ne l’est pas.
Comment webchat.vip peut-il prendre en charge le service WebChat principal ?
webchat.vip fournit des widgets WebChat installables, personnalisables et multilingues, ainsi que des flux automatisés capables de collecter des réponses validées, de créer des branches, de transférer et de passer la main à des personnes. Les équipes peuvent organiser les opérateurs, services, routages et horaires, et utiliser une boîte de réception partagée pour les conversations WebChat et WhatsApp. Les analyses opérationnelles, journaux de conversation, évaluations et rapports exportables peuvent soutenir les revues. Les responsables de site restent chargés de concevoir et d’exploiter des voies d’assistance alternatives en dehors du service de chat principal.
Sources et lectures complémentaires
Références primaires et reconnues utilisées pour vérifier la base factuelle de ce guide.
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C
- Understanding Success Criterion 2.1.1: Keyboard — W3C Web Accessibility Initiative
- Forms Tutorial — W3C Web Accessibility Initiative
- Validating Input — W3C Web Accessibility Initiative
- User Notification — W3C Web Accessibility Initiative
- Understanding Success Criterion 3.3.8: Accessible Authentication (Minimum) — W3C Web Accessibility Initiative
- Assisted digital support: an introduction — GOV.UK Service Manual
- Designing assisted digital support — GOV.UK Service Manual
- Set up and manage user support — GOV.UK Service Manual
- Quality assurance: testing your service regularly — GOV.UK Service Manual