Pannes et retards : informez chaque client concerné dans son propre chat avec un seul message

À 09:40, la connexion ne marche plus et, à 10:30, 38 clients ont déjà écrit sur 3 canaux. Chaque réponse est formulée autrement, et personne ne sait dire qui a déjà eu un retour. Une fois le correctif en ligne, quelqu'un doit encore tous les retrouver.

Un retard du transporteur dans une boutique en ligne suit le même chemin, juste plus lentement. Vous trouverez ici 4 modèles, un rythme de mises à jour selon la gravité et 2 cas concrets, valables pour n'importe quel logiciel de support client.

Ce que doit contenir chaque message de panne

L'équipe Statuspage d'Atlassian résume le premier message en une ligne : « Reconnaissez vite le problème, résumez brièvement l'impact connu, promettez d'autres mises à jour » (Atlassian).

Hyperping, qui vend des pages de statut, demande 6 informations dans chaque avis (Hyperping) :

• ce qui ne marche pas
• qui est touché
• depuis quand
• la solution de contournement
• l'heure de la prochaine mise à jour
• où suivre la situation

Donnez l'heure de la prochaine mise à jour, puis tenez-la

L'heure de la prochaine mise à jour est ce qui aide le plus. Un client qui lit « prochaine mise à jour avant 11:00 CET » n'a aucune raison de rafraîchir la page sans arrêt ni d'écrire « du nouveau ? ».

Alors tenez parole. La règle d'Hyperping : « ne jamais laisser passer une heure de mise à jour promise », car « une mise à jour manquée ressemble à du silence ». Si 11:00 arrive et que vous n'avez rien de neuf, envoyez « Nous y travaillons toujours, prochaine mise à jour avant 11:30. »

C'est pareil pour l'heure prévue du correctif. Le guide de Cronitor le dit sans détour : « Les gens s'organisent autour de l'heure que vous avez publiée », donc publiez à nouveau dès que cette heure glisse (Cronitor).

Soyez clair sur la cause, et assumez

Nommez la cause avec des mots simples, ou dites que vous ne la connaissez pas encore. Une supposition que vous devez retirer plus tard coûte de la confiance.

Assumez le problème même quand quelqu'un d'autre l'a causé. Encore Atlassian : « aux yeux de vos clients, c'est un problème de votre service. » Cela vaut aussi pour votre transporteur.

À quel rythme informer, selon la gravité

Les 2 premières lignes du tableau suivent Atlassian, qui conseille une mise à jour toutes les 30 minutes par défaut, et Hyperping, qui donne ces chiffres :

• le premier avis dans les 15 à 30 minutes après la confirmation de la panne
• des mises à jour toutes les 30 à 60 minutes
• toutes les 15 minutes quand une panne totale touche un service qui vous rapporte de l'argent
• l'avis de résolution dans les 30 minutes après le correctif

La ligne panne partielle se situe du côté lent de la fourchette d'Hyperping. Les 2 dernières lignes sont notre propre règle pratique pour les problèmes plus lents.

Quelle que soit la ligne, toute personne qui a reçu le premier message reçoit aussi le dernier, même une fois la pression retombée.

4 modèles à copier

Écrivez-les pour une fenêtre de chat, car c'est là qu'arrivent beaucoup de ces mises à jour. Faites court, indiquez le fuseau horaire à côté de chaque heure et oubliez le « Cher client ».

Les mots entre [crochets] sont à compléter.

1. Premier avis

Bonjour [prénom], merci de nous avoir prévenus. [La connexion] ne fonctionne pas pour [certains / tous les] clients depuis [09:40 CET], et nous nous en occupons.

[En attendant, vous pouvez ...] Nous ne connaissons pas encore la cause. Notre prochaine mise à jour arrive dans ce chat avant [10:25 CET], même s'il n'y a rien de nouveau.

Pour un retard de livraison :

Bonjour [prénom], votre commande [numéro] est retardée. [Transporteur] n'a pas enlevé de colis dans notre entrepôt depuis [mardi] à cause d'[une panne informatique dans son dépôt].

Votre commande est emballée et prête, et nous pensons qu'elle partira d'ici [vendredi]. Dans tous les cas, nous vous écrivons à nouveau avant [demain, 17:00]. Si vous préférez ne pas attendre, répondez « annuler » et nous vous remboursons intégralement.

2. Point d'étape avec l'heure de la prochaine mise à jour

Point sur [le problème de connexion], [10:25 CET] : nous avons trouvé la cause. [Une modification de la base de données faite ce matin bloque les connexions.]

Nous sommes en train de [l'annuler] et nous pensons que [la connexion] fonctionnera à nouveau vers [11:00 CET]. Cette estimation peut encore bouger. Prochaine mise à jour avant [10:55 CET].

3. Correctif en ligne, ou colis en route

[La connexion] fonctionne à nouveau depuis [11:05 CET]. Si vous voyez encore [l'erreur], merci de [vous déconnecter puis de vous reconnecter] et répondez ici si cela ne suffit pas. [Les réservations faites entre 09:40 et 11:05 n'ont pas été enregistrées, merci de les saisir à nouveau.]

Pour un retard de livraison :

Bonne nouvelle : [transporteur] a enlevé les colis bloqués [vendredi]. Votre commande [numéro] est en route, suivi : [lien].

Elle devrait arriver d'ici [mardi]. Le suivi peut mettre jusqu'à un jour pour afficher le premier scan.

4. Message final

[Le problème de connexion] est réglé et nous clôturons cette conversation. Il a duré de [09:40] à [11:05 CET] et venait de [une phrase]. Pour éviter que cela se reproduise, nous [un changement concret].

Désolés pour la gêne, et merci pour votre patience. Si quelque chose vous semble encore anormal, répondez simplement ici.

Restez concret ici. « Nous avons pris des mesures pour éviter que cela se reproduise » ne dit rien. « Nous testons désormais les modifications de la base de données d'abord sur une copie des données réelles » montre au client que vous avez appris quelque chose.

Écrivez-les avant d'en avoir besoin

Écrivez vos 4 modèles maintenant, tant que tout fonctionne, et décidez qui les envoie et à quel rythme. Quand la prochaine panne ou le prochain souci de transporteur arrive, la personne de permanence n'a plus qu'à remplir les crochets.

Cas 1 : une panne dans un SaaS

Prenons un outil de réservation utilisé par 1,200 petites entreprises. Une modification de la base de données part à 09:30 et, à partir de 09:40, plus personne ne peut se connecter. Le support le confirme à 09:46.

Comment partent les mises à jour

• 09:55 : premier avis (modèle 1), prochaine mise à jour avant 10:25.
• 10:25 : modèle 2. Cause trouvée, retour en arrière lancé, connexion attendue vers 11:00, prochaine mise à jour avant 10:55.
• 10:55 : le retour en arrière tourne encore, alors l'équipe envoie « Nous y travaillons toujours, prochaine mise à jour avant 11:15 ». Rien de nouveau, et la promesse est tenue quand même.
• 11:10 : modèle 3, avec la phrase sur les réservations non enregistrées.
• 15:00 : après 4 heures sans nouvelle erreur, le modèle 4 donne la cause et le changement.

Où des clients passent à la trappe

À 10:30, 38 clients avaient écrit : 21 dans le chat du site web, 12 par e-mail et 5 sur WhatsApp. À 11:05, ils étaient 52.

Les 14 qui ont écrit après 10:30 ont besoin du statut actuel, alors gardez un seul texte à jour que toute l'équipe copie. À la main, cette panne représente plus de 200 envois sur 3 canaux, et c'est là que des clients passent à la trappe.

Cas 2 : un problème de transporteur bloque 200 commandes

Une boutique en ligne expédie environ 70 commandes par jour. Un mardi début décembre, le dépôt régional du transporteur subit une panne informatique et arrête les enlèvements. Deux fois, le transporteur promet un passage pour le lendemain.

Le jeudi, il est clair que rien ne bougera de sitôt, et 200 commandes emballées attendent dans l'entrepôt. Parmi ces clients, 64 ont déjà écrit : 30 sur WhatsApp, 25 par e-mail et 9 dans le chat du site web.

Le moment aggrave tout. Le blog entreprise de Shopify, qui cite le prestataire de support Influx, indique que les boutiques connaissent « un pic moyen de 79% des tickets de support la première semaine de décembre » (Shopify).

Ce sont des chiffres d'un prestataire, mais si votre mois de décembre ressemble à ça, le retard tombe sur une file d'attente déjà pleine.

Quand un vendeur britannique s'est retrouvé avec plus de 500 commandes Amazon bloquées derrière un porte-conteneurs en retard, il a raconté ensuite sur le forum des vendeurs Amazon que suivre les questions des clients avait été le plus dur.

Le plan pour les 200 commandes

1. Écrivez aux 200 ce jeudi-là, par e-mail depuis votre système de boutique, avant que les 136 autres ne s'en rendent compte et commencent à poser des questions. Utilisez la version livraison du modèle 1.
2. Répondez aux 64 qui ont écrit, sur le canal qu'ils ont utilisé, avec le même texte.
3. Faites une mise à jour par jour. Le jour où les colis repartent, envoyez le modèle 3 avec le lien de suivi et, quelques jours plus tard, vérifiez quels colis ne sont toujours pas arrivés.

Pour la version de tous les jours de ces questions, consultez notre guide sur les messages « où est ma commande ? ».

Un piège sur WhatsApp

Meta n'autorise le texte libre sur WhatsApp que dans les 24 heures qui suivent le dernier message du client. En dehors de cette fenêtre, « les entreprises ne peuvent envoyer que des messages modèles » (Meta).

Donc, le jeudi, la boutique ne peut joindre les clients WhatsApp qui ont écrit le mardi qu'avec un modèle approuvé. Faites approuver un modèle pour les retards avant d'en avoir besoin.

Ce que dit la loi quand les commandes sont en retard

Aux États-Unis

La Mail, Internet, or Telephone Order Merchandise Rule de la FTC couvre les commandes qui ne sont pas encore parties. Si vous ne pouvez pas expédier dans le délai annoncé (30 jours si vous n'en avez annoncé aucun), vous devez (guide de la FTC pour les entreprises) :

• prévenir le client avant la fin de ce délai
• donner une nouvelle date, ou dire que vous ne pouvez pas
• proposer l'annulation avec « un remboursement complet et rapide »

Dans l'UE

L'article 20 de la directive 2011/83/UE relative aux droits des consommateurs dit que le risque de perte ou de détérioration ne passe au consommateur que lorsque lui, ou une personne qu'il a désignée autre que le transporteur, prend physiquement possession des biens (texte de la directive).

Un colis perdu par le transporteur, c'est donc à vous de le remplacer ou de le rembourser, sauf si le client a choisi un transporteur que vous ne proposiez pas. L'Allemagne applique la même règle au § 475 (2) BGB.

Le Brésil et d'autres pays ont leurs propres règles. Ceci est une information générale, pas un conseil juridique.

Une mise à jour dans chaque chat avec un ticket groupé Deskwoot

Deskwoot est notre propre logiciel de support client. Un ticket groupé y est un ticket sans client, pour un problème que partagent beaucoup de clients, et il transforme les plus de 200 envois du cas 1 en un seul envoi par mise à jour.

1. Créez le ticket groupé, par exemple « Connexion impossible depuis 09:40 ».
2. Liez les chats et les tickets concernés. La recherche du ticket groupé trouve ceux qui sont ouverts ou en attente par nom, texte du message ou numéro.
3. Rédigez la mise à jour et cliquez sur Aperçu de la mise à jour. L'aperçu compte qui la recevra et liste sous « Non joints » chaque chat qu'il ne peut pas atteindre, avec la raison.
4. Envoyez. Chaque client reçoit le texte une seule fois, dans son propre chat et sur le canal de ce chat (un e-mail part dans son fil de discussion).
5. Une fois le problème réglé, « Résoudre avec tous les éléments liés » ferme le ticket groupé et tout ce qui y est lié, avec le modèle 4 comme dernier message facultatif.

Le tableau « Clients concernés » indique pour chaque client si la dernière mise à jour a été distribuée, lue ou non distribuée, avec la raison. Si l'envoi s'arrête en cours de route, un second envoi ne touche que les clients qui manquent encore.

Une mise à jour de ticket groupé n'est jamais un modèle WhatsApp, donc les chats au-delà des 24 heures arrivent sous « Non joints ». Envoyez à chacun un modèle approuvé (comment ça marche, pour les numéros sur la WhatsApp Cloud API) et, dès que le client répond, la mise à jour suivante lui parvient.

Les tickets groupés font partie du forfait Enterprise, $12 par agent et par mois ou $9.60 en facturation annuelle (tarifs), et une mise à jour touche jusqu'à 500 clients.

Essayez sur une panne de test

Créez un compte et votre nouvel espace de travail reçoit 7 jours d'Enterprise gratuits, sans carte bancaire, pour 30 sièges maximum, le vôtre compris. Liez 2 ou 3 chats de test à un ticket groupé nommé « Panne de test » et envoyez-leur une mise à jour pour voir l'aperçu et le tableau.

À la fin des 7 jours, rien n'est facturé : vous choisissez un forfait payant ou vous continuez sur le forfait gratuit Hacker pour 1 agent.