Support client
Incidents Linear depuis les tickets de support (sans perdre l’histoire)
Reliez les tickets initdesk à Linear sans perdre le fil : équipe et préfixe de titre par défaut, quand créer vs lier un incident, quoi capturer avant de cliquer Créer, et comment boucler la boucle avec les clients.
Le moyen le plus rapide de tuer un bon rapport de bug, c’est de transférer un e-mail qui dit « le client est contrarié » et rien de reproductible.
L’ingénierie n’a pas besoin de drame. Elle a besoin de signal : ce qui a cassé, où, et comment le revoir. Le support a déjà les mots du client. Ce qui manque, c’est une habitude qui transforme ces mots en incident Linear autonome, tout en gardant le ticket initdesk comme lieu où le client reçoit les mises à jour.
C’est le rôle de l’intégration Linear d’initdesk : pas « plus de tickets », mais un fil dans l’e-mail et un objet dans Linear, liés pour que personne ne retape la même histoire dans Slack.
Connectez une fois, routez à chaque fois
Commencez dans Paramètres → Plugins → Linear et connectez votre espace de travail. Puis réglez les défauts ennuyeux qui empêchent le chaos plus tard :
- Équipe Linear par défaut : pour que « créer un incident » ne devienne pas un jeu de devinettes de routage à 17h.
- Préfixe de titre : une courte balise comme
support:ou[cx]rend les incidents créés depuis la boîte faciles à scanner dans Linear sans changer la façon dont les ingénieurs travaillent.
Ces deux réglages sont petits, mais ils répondent à la question que chaque agent se pose en silence : « Où est-ce que ça va ? » Si vous les sautez, vous paierez la taxe en incidents mal classés et en doublons.
Pour le détail de configuration et les permissions, utilisez le guide d’intégration Linear d’initdesk. La mise à jour produit qui a livré l’intégration est sur Mises à jour initdesk.
Créer un nouvel incident vs lier un existant
Dans la barre latérale du ticket, vous pouvez soit créer un nouvel incident Linear, soit attacher le ticket à un incident qui existe déjà. Une règle empirique simple :
- Créer quand vous avez un nouveau défaut, une nouvelle demande, ou un fil qui mérite son propre périmètre dans Linear.
- Lier quand l’ingénierie le suit déjà : votre job est d’attacher des preuves (impact client, exemples, urgence) sans faire naître un second ticket que personne ne fusionnera.
Lier, c’est éviter le mode d’échec classique : trois agents ouvrent chacun « L’export échoue pour les clients UE » parce que personne n’a cherché dans Linear d’abord. Même dans une toute petite équipe, cinq secondes de recherche dans Linear avant de créer battent encore le théâtre de triage plus tard.
Ce qui appartient au ticket initdesk avant de cliquer « créer »
Pensez en deux couches : ce que le client doit lire et ce que le produit doit lire.
La réponse côté client doit rester calme et précise : ce dont vous avez besoin d’eux (le cas échéant), ce qui se passe ensuite, et un timing réaliste si vous pouvez l’offrir. Si vous enquêtez encore, dites-le en langage simple : le mystère, c’est ce qui alimente les boucles de réouverture.
Les notes internes (ou un addendum serré que seule l’équipe voit) doivent porter la charge utile de passation :
- Étapes de repro numérotées, y compris type de compte, plan ou rôle si ça compte.
- Environnement : navigateur ou build d’app, OS, heure approximative de l’échec.
- Attendu vs observé en une ligne chacun : les ingénieurs scannent ce schéma vite.
- Une capture ou un court clip quand l’UI est la preuve ; évitez dix pièces jointes que personne n’ouvre.
- Un lien vers le message client est automatique dans l’esprit quand l’incident est créé depuis initdesk. Ce que vous ajoutez, c’est l’interprétation qui transforme le bruit en plan de test.
Quand vous créez l’incident depuis initdesk, le flux prend en charge les champs que les équipes produit attendent (équipe, statut, responsable, abonnés, labels, titre et description) et peut inclure le contexte du ticket plus une référence vers la conversation de support. Votre objectif : rendre l’incident Linear lisible sans ouvrir l’e-mail, pendant que l’e-mail reste le foyer du client.
Gardez les notes internes honnêtes (et un peu ennuyeuses)
Le travail de ton dans Du support porté par le fondateur à une voix reproductible s’applique encore : les notes internes sont l’endroit où vous traduisez un paragraphe frustré en faits.
- Préférez « Les étapes 1 à 4 se reproduisent sur Chrome 124, connecté en admin » à « clairement cassé ».
- Si vous n’êtes pas sûr que c’est un bug, dites « besoin de repro de notre côté » et nommez qui possède la prochaine vérif.
- Si c’est un trou de documentation, dites-le : sinon l’ingénierie chasse un fantôme alors que le vrai correctif est une mise à jour d’article d’aide, ce qui s’accorde naturellement avec Un libre-service qu’on utilise vraiment.
Bouclez la boucle quand Linear avance
Un incident lié n’est pas terminé tant que le client ne sait pas ce qui a changé. L’habitude qui passe à l’échelle :
- Surveillez l’état d’incident qui compte pour vous (corrigé, livré, ne sera pas corrigé) et décidez ce que chacun veut dire en langage client.
- Répondez une fois avec ce qui a été livré, ce qui ne l’a pas été, et la prochaine étape, surtout pour « ne sera pas corrigé », où une raison claire limite les dégâts de réputation.
- Si vous avez livré un changement de comportement, mettez à jour le Centre d’aide la même semaine pour que le prochain ticket ne reparte pas de zéro.
initdesk garde support et produit liés : la conversation qui a démarré le travail doit encore être celle qui le termine, Linear portant le récit ingénierie entre les deux.
Un passage de quinze minutes le lundi (petites équipes)
Si les passations semblent molles, n’ajoutez pas un comité : lancez une revue serrée :
- Ouvrez les incidents Linear créés depuis le support cette semaine. Des titres lisent-ils encore comme des sujets d’inbox plutôt que des symptômes ?
- Prenez trois tickets liés. Chaque description d’incident contient-elle repro, environnement, et attendu vs observé ?
- Listez les incidents fermés comme livrés. Chaque ticket correspondant a-t-il reçu une réponse client finale ?
Si la réponse à (3) est « parfois », ce n’est pas un trou d’outil : c’est un trou de boucle. L’intégration a déjà fait le plus dur : connecter les systèmes. Le facile, c’est un message au humain qui a signalé le problème.
initdesk est un help desk IA pour les petites équipes : boîte de réception partagée, Centre d’aide, et flux Linear optionnel pour garder les fils clients liés au travail produit. Voir Mises à jour produit pour ce qui a été livré récemment, et le guide d’intégration Linear pour la connexion et le comportement des champs. Questions ou récits de guerre bienvenus sur X @initdeskhq.