Un client ne parvient pas à se connecter le lundi matin. Il n'ouvre pas de ticket. Il publie sur X : « acme me déconnecte toutes les dix minutes depuis la mise à jour, d'autres personnes ont ce problème ? ». Deux personnes répondent qu'elles rencontrent le même souci. Le temps qu'un membre de votre équipe tombe par hasard sur le fil de discussion, nous sommes mercredi et l'auteur du message a déjà demandé une démo à un concurrent.
Votre service d'assistance est conçu pour les personnes qui vous contactent directement. Or, une part croissante des demandes de support ne suit pas ce canal. Elles sont publiées en public, parfois avec le nom de votre marque mal orthographié, et n'atteignent jamais votre boîte de réception de support à moins que quelqu'un ne parte à leur recherche.
Je m'appelle Julien et je travaille sur KWatch.io, un outil d'alerte par mot-clé pour LinkedIn, X, Facebook, YouTube, Reddit et Hacker News. Cet article explique comment détecter ces réclamations et déposer chacune d'elles dans la file d'attente que vos agents utilisent déjà, afin qu'une publication sur Reddit soit traitée comme un e-mail.
La plupart des équipes de support surveillent les réseaux sociaux, mais uniquement ce qui leur parvient directement. Les services d'assistance intégrant X détectent les mentions directes de votre compte officiel. Cela fonctionne quand les utilisateurs vous identifient. Mais beaucoup ne le font pas.
Les internautes écrivent « acme » au lieu de « @acme ». Ils demandent sur r/sysadmin si la synchronisation d'autres personnes est en panne. Ils vous mentionnent au détour d'un commentaire sur Hacker News qui traite d'un tout autre sujet. Rien de tout cela n'apparaît dans un flux de mentions, et rien n'arrive jusqu'à la personne de garde.
L'autre problème concerne la responsabilité. Lorsque les réclamations sur les réseaux sont repérées par l'équipe marketing, elles ont tendance à stagner dans un canal Slack marketing jusqu'à ce que quelqu'un les transmette. Un ticket a un responsable, une échéance et un statut. Un message Slack ne possède aucun de ces éléments ; la solution consiste donc à transformer la réclamation en ticket le plus tôt possible.
Avant d'intégrer quoi que ce soit à votre service d'assistance, vous avez besoin d'alertes qui identifient les problèmes de support plutôt que chaque mention de votre marque. Une alerte KWatch exige que chaque mot-clé de sa liste soit présent : les virgules fonctionnent donc comme un ET logique (AND). Cela vous permet d'associer le nom de votre produit aux mots employés par les utilisateurs lorsque quelque chose ne fonctionne pas.
En prenant « acme » comme exemple de nom de produit, voici une sélection de départ :
1. acme, not working et acme, broken pour les pannes franches
2. acme, can't login et acme, logged out pour les problèmes de compte
3. acme, refund et acme, charged pour les réclamations liées à la facturation
4. acme, help pour les personnes demandant comment effectuer une action
Chaque ligne constitue une alerte distincte. Si vous mettiez tous ces mots dans une seule alerte, une publication devrait contenir chacun d'eux pour correspondre. Au bout d'une semaine, examinez quelles alertes se sont déclenchées et la manière dont vos utilisateurs formulent leurs demandes, puis ajustez. Essayez également votre identifiant officiel comme mot-clé, car certaines personnes vous mentionnent au lieu d'écrire le nom de la marque.
Les filtres permettent de garder la file d'attente propre, et ils sont ici plus indispensables que partout ailleurs, car chaque faux positif devient un ticket que quelqu'un doit clôturer. Ajoutez les comptes de votre support et de votre marque en Utilisateurs exclus afin que vos réponses n'ouvrent pas de nouveaux tickets. Sur Reddit et Hacker News, activez l'option Mots entiers uniquement si votre nom est court, pour qu'« acme » ne corresponde pas à « acmeplex ». Quelques mots-clés exclus permettent d'écarter le bruit évident, comme les offres d'emploi qui vous mentionnent. Gardez cette liste courte, car une publication est éliminée dès que l'un des mots-clés exclus y figure. Nous avons passé en revue chaque filtre dans notre article sur la réduction du bruit dans les alertes par mot-clé.
La rapidité dépend de la plateforme, et il est bon de la connaître avant de promettre un délai de réponse. Voici les fréquences d'actualisation issues de notre documentation :
| Plateforme | Fréquence de vérification du nouveau contenu |
|---|---|
| Hacker News | 1 seconde à 1 minute |
| Linkedin, Youtube | 1 à 10 minutes |
| Reddit, X, Facebook | 10 minutes à 1 heure |
Une réclamation sur X peut ainsi prendre jusqu'à une heure pour arriver dans votre file d'attente. Pour la plupart des équipes de support, cela reste bien plus rapide que de la trouver manuellement le mercredi. Toutefois, si vous appliquez un SLA très strict sur les mentions directes (@mentions), conservez le canal natif X de votre service d'assistance pour celles-ci et utilisez les alertes par mot-clé pour tout ce qu'il ne peut pas voir, comme les publications non identifiées, les fils Reddit et les commentaires Hacker News. KWatch ne peut pas non plus lire les messages privés (DMs), ceux-ci restent donc gérés avec vos outils actuels.
Une fois les alertes actives, l'étape suivante consiste à les acheminer de KWatch vers des tickets. La méthode la plus propre est d'utiliser un webhook d'API. Chaque correspondance arrive sous la forme d'une charge utile JSON, et vous pouvez configurer un webhook par alerte : vos alertes de réclamation rejoignent ainsi le service d'assistance tandis que vos autres alertes sont dirigées ailleurs. Un webhook spécifique à une alerte a la priorité sur celui défini au niveau du compte.
Voici l'exemple de charge utile issu de notre documentation :
{
"platform": "reddit",
"query": "Keywords: vllm",
"datetime": "19 Jan 24 05:52 UTC",
"link": "https://www.reddit.com/r/LocalLLaMA/comments/19934kd/sglang_new/kijvtk5/",
"author": "lmzoo",
"content": "sglang runtime has a different architecture on the higher-level part with vllm.",
"sentiment": "neutral"
}
Tous les champs nécessaires pour un ticket y figurent. Le champ content devient la description, le champ link se place en tête afin que l'agent puisse ouvrir le fil de discussion, et le champ query indique quelle alerte s'est déclenchée. Pour X, le champ auteur inclut également le nom complet et le nombre d'abonnés de la personne, ce qui aide l'agent à hiérarchiser ses réponses.
1. Créez un Zap avec Webhooks by Zapier et le déclencheur Catch Hook, puis collez l'URL du webhook dans le champ API Webhook URL de vos alertes de réclamation.
2. Ajoutez une étape Filter si vous souhaitez que seules certaines correspondances deviennent des tickets. Une règle classique consiste à laisser passer tout ce dont le champ sentiment n'est pas positif, ce qui élimine les messages du type « acme a réglé mon problème en cinq minutes ».
3. Ajoutez l'action de création de ticket de votre service d'assistance. Dans Zendesk, il s'agit de Create Ticket. Associez le champ content à la description, construisez l'objet à partir de platform et author, et ajoutez un tag comme social afin de pouvoir facilement générer des rapports sur ces tickets.
Le même flux fonctionne avec un nœud Webhook, un nœud IF sur le champ sentiment, et le nœud Zendesk ou Freshdesk configuré pour créer un ticket. Si vous n'avez jamais connecté KWatch à l'un de ces outils auparavant, notre guide Zapier et n8n détaille la configuration des webhooks étape par étape.
Un mot sur le filtre de sentiment : il est mesuré par rapport à votre mot-clé, et le sarcasme peut encore le tromper de temps à autre. Je vous conseille donc de l'utiliser comme un filtre indicatif pendant les premières semaines. Transmettez tout, observez ce qui a été qualifié de positif, et seulement ensuite laissez le filtre écarter des tickets.
Un ticket issu de Reddit est un ticket particulier, car le client ne vous l'a pas adressé directement. Votre façon de répondre détermine si cela apportera une aide réelle.
Je vous conseille de garder la première réponse courte, publique et précise. Présentez-vous, indiquez que vous avez pris connaissance du problème, et donnez la solution de contournement ou l'étape suivante. Si vous avez besoin des identifiants du compte, demandez-lui de vous contacter en message privé, et ne demandez jamais d'informations personnelles dans le fil de discussion. Une fois le problème résolu, revenez le signaler. Cette dernière réponse sera celle que la prochaine personne rencontrant le même problème trouvera sur Google.
Certains fils de discussion porteront sur des sujets que vous ne pouvez pas corriger, comme une modification tarifaire impopulaire. Ils méritent d'être suivis, mais il est généralement préférable de les catégoriser et de les transmettre à l'équipe produit plutôt que d'y faire répondre le support. Et si une réclamation se transforme en vingt en l'espace d'une heure, il ne s'agit plus d'un simple ticket de support. Notre guide sur la détection d'une crise de relations publiques sur les réseaux sociaux explique la marche à suivre lorsque cela arrive.
Si votre équipe de support suit également une liste restreinte de comptes clés, notre produit frère MultiFollow vous alerte lorsque des profils LinkedIn et X spécifiques publient, ce qui vous permet de voir le message d'un utilisateur clé contrarié même s'il ne cite jamais le nom de votre produit.
Choisissez le nom de votre produit ainsi que l'expression que vos utilisateurs emploient le plus souvent en cas de panne, et configurez-la sur Reddit et Hacker News. Le forfait gratuit de KWatch comprend 2 alertes par mot-clé sur Reddit et 2 sur Hacker News avec notifications par e-mail, ce qui suffit pour mesurer le nombre de réclamations qui vous échappaient. Les alertes sur X et les filtres comme Utilisateurs exclus débutent avec le forfait Essential à 19 $ par mois, tandis que les webhooks d'API permettant de créer des tickets sont disponibles sur le forfait Business à 79 $.
Julien, Product Manager chez KWatch.io