Stack de support B2B sur Slack — le workspace du client est l'interface, jamais le registre

Le support en canaux partagés gagne pour une raison : le client ne quitte jamais l’endroit où il travaille déjà. Et il échoue pour la même raison. Un message Slack n’a pas de file, pas de propriétaire, pas d’horloge et — si le workspace du client est sur le plan gratuit de Slack — pas de mémoire au-delà de 90 jours d’historique de messages. Le fil où vous avez promis un correctif expire avant la conversation de renouvellement où cela compte.

Ce stack repose sur une seule règle : Slack est l’interface, et rien d’autre. Le registre, l’horloge, la trace côté engineering et la connaissance vivent à un endroit que vous contrôlez. Chaque composant ci-dessous existe pour sortir l’un de ces quatre éléments du canal.

Deux conditions à vérifier avant de chiffrer quoi que ce soit. Slack Connect exige que chaque organisation participante soit sur un plan payant — le plan de votre client est son problème jusqu’à ce qu’il devienne le vôtre, et en Enterprise+ les partenaires en plan gratuit rejoignent sans upgrade. Un seul canal Slack Connect accueille jusqu’à 250 organisations, très au-delà de tout compte que vous piloterez ainsi.

La forme

• Slack est la surface que votre client a déjà ouverte. Rien dans ce stack ne lui demande de se connecter à un portail, et c’est là tout l’argument commercial. Depuis l’Europe, slack.com/pricing affiche en EUR : Pro à 6,75 € par utilisateur/mois en paiement annuel (8,25 € en mensuel), Business+ à 15 € en annuel (18 € en mensuel). Vous payez par siège interne, quel que soit le nombre d’invités externes présents dans les canaux.
• Pylon est le registre et l’horloge. Il surveille les canaux clients connectés — publics, privés et canaux Slack Connect initiés par votre client —, regroupe les messages liés et ouvre un issue suivi sans que personne tape de commande. Les Internal Threads donnent aux collègues sans siège Pylon un endroit pour traiter cet issue dans Slack, synchronisé dans les deux sens. Il porte trois SLA d’issue (première réponse, réponse suivante, résolution) plus des Team SLAs, qui démarrent quand l’issue est assigné à cette équipe et non à la création — ainsi un solutions engineer qui garde un fil une semaine ne brûle pas le chiffre du support. Les Support Hours empêchent les soirées et les week-ends de gonfler les dépassements, et un dépassement déclenche une notification Slack dans le canal de votre choix.
• Linear prend la moitié du ticket que le support ne peut pas clore. Depuis le module latéral de Pylon ou le bouton Create Ticket 📦 du canal de triage, un issue client devient un issue Linear avec un titre rédigé par l’IA. Les commentaires Linear reviennent en notes internes dans Pylon et les réponses Pylon repartent en commentaires Linear. Pylon intègre un module dans l’issue Linear pour que l’engineering lise quel compte est bloqué sans ouvrir un outil de support. Activez la configuration Customer Requests : la demande s’attache à une fiche client Linear portant revenue, tier, taille et statut, ce qui transforme « trois comptes enterprise veulent ça » en chiffre dans la réunion de priorisation plutôt qu’en anecdote.
• Notion est le runbook interne, pas la KB côté client. La knowledge base de Pylon et ses issues passés sont réindexés en direct ; le contenu externe ajouté en Training Data est une URL publique ou une URL de base crawlée, réindexée tous les 7 ou 30 jours selon le plan, et Notion n’est pas une source documentée. Les deux faits pointent dans la même direction. Une page Notion privée n’atteint jamais l’agent, et un Notion Site publié pour le crawl répond avec une politique de remboursement que vous avez changée il y a trois semaines. Les réponses côté client appartiennent à la KB de Pylon ; Notion garde les runbooks internes, les arbres d’escalade et le contexte de compte que votre équipe lit et que vos clients ne lisent pas.
• L’agent IA est un embranchement, pas un choix par défaut. Le Support Agent, le Slack Agent et les Connectors de Pylon sont chacun marqués beta, avec un accès limité aux participants de la beta dans la documentation de Pylon elle-même. Prévoyez l’une des deux voies : entrer dans la beta, ou amener le vôtre. La voie « amenez le vôtre » est documentée — webhooks pour les événements d’issue et de message, l’API REST pour les réponses et l’écriture de champs, et un serveur MCP hébergé sur mcp.usepylon.com (OAuth 2.0 via AuthKit, conditionné à un rôle MCP Access pour les utilisateurs Member ou Admin) exposant search_issues, get_issue, get_issue_messages, create_issue, update_issue, search_accounts, get_account, update_account, get_contact, get_user et get_me, avec des limites de débit par outil et par organisation renvoyant 429. Pointez Claude vers cette surface pour rédiger la réponse et rassembler le contexte ; c’est toujours un humain qui publie dans le canal du client.

Passations nommées

1. Le client écrit dans le canal partagé → Pylon ouvre un issue suivi → l’horloge du SLA démarre. Pas de commande /ticket, pas de portail, aucun changement de comportement demandé au client.
2. L’issue est routé vers une équipe → le Team SLA démarre là. Le SLA global continue de courir depuis la création, si bien que vous voyez l’expérience client et la performance de l’équipe comme deux chiffres distincts.
3. Le support ne peut pas corriger → Create Ticket 📦 → un issue Linear plus un Customer Request sur la fiche du compte. L’ingénieur obtient le contexte du compte intégré ; le product manager obtient une liste de demandes pondérée par revenue.
4. L’issue Linear est terminé → l’issue Pylon est notifié et passe en « On You ». Quelqu’un retourne dans le canal et annonce au client que son bug est livré. C’est l’étape qui meurt dans toutes les versions maison de Slack plus Jira, et celle dont les clients se souviennent.
5. Un issue se ferme sans article derrière → marquez-le comme nécessitant un article → il atterrit dans la file Gaps → Copilot le rédige → sa publication dans la KB Pylon le réindexe en direct. Pylon génère aussi des sujets pour les questions récurrentes que votre documentation connectée ne couvre pas, et c’est le backlog qu’on traite réellement.
6. Un champion quitte le canal → Pylon le signale dans le canal de triage de ce compte et indique si la personne est encore dans l’entreprise. L’alternative, c’est de l’apprendre pendant un call de renouvellement.

Base de coûts

Une équipe support et CS de 8 sièges couvrant environ 60 canaux clients :

• Slack : Business+ à 15 € par utilisateur/mois en annuel. Pour 8 sièges support, cela fait environ 1 440 €/an, même si en pratique Slack est déjà une ligne à l’échelle de l’entreprise.
• Pylon : sur devis. usepylon.com/pricing redirige vers la prise de démo, traitez donc chaque chiffre comme une ancre de négociation et non comme un devis. Derniers tarifs publiés : Starter 59 $, Professional 89 $, Enterprise 139 $ par siège/mois en facturation annuelle, avec un minimum de 3 sièges (7 en Enterprise). Les AI Assistants ajoutaient 50 $/siège/mois, les AI Agents démarraient à 100 $/mois et montaient avec le volume d’issues sur 30 jours, et Account Intelligence tournait à 10 $ par compte client/mois avec un minimum de 50 comptes. Huit sièges Professional ancrent autour de 8 500 $/an ; avec les Assistants, on approche 13 300 $ ; 60 comptes d’Account Intelligence ajoutent environ 7 200 $ par-dessus.
• Linear : le plan Free couvre 2 équipes et 250 issues, ce qu’une vraie organisation d’engineering dépasse en un trimestre. Basic coûte 10 $ par utilisateur/mois en annuel ; Business coûte 16 $ et c’est le palier qui porte Linear Asks, les équipes privées avec invités, et les connecteurs Zendesk et Intercom. Customer Requests existe sur tous les plans, Free compris, mais en Free vous ne pouvez les créer que manuellement ou depuis Slack.
• Notion : Free, Plus à 9,50 € ou Business à 19,50 € par membre/mois. Si vous publiez une partie du workspace en Notion Site sur votre propre domaine, comptez 8 $ par mois et par domaine en paiement annuel.

Le total pour huit sièges support atterrit grosso modo entre 16 000 $ et 26 000 $ par an, dont Pylon représente 60 à 80 %. La question budgétaire porteuse n’est pas quels outils — c’est quels add-ons Pylon vous activez réellement.

Variantes et quand permuter

• Jira au lieu de Linear quand l’engineering tourne déjà sur Jira et n’en bougera pas. Vous conservez les passations 3 et 4 via l’intégration ticketing de Pylon, vous perdez la fiche client Linear, et la liste de demandes pondérée par revenue doit être reconstruite dans des champs Jira ou un tableur. Ne migrez pas l’engineering pour gagner une fonction de support.
• Microsoft Teams au lieu de Slack Connect quand vos clients sont des maisons Microsoft. Pylon traite Teams comme un canal de premier plan et le reste du stack ne change pas. Cette permutation se décide par l’endroit où vivent vos clients, pas par préférence.
• Fin (Intercom) comme couche de résolution quand vous voulez un agent facturé dès aujourd’hui plutôt qu’attendre une place en beta chez Pylon. Fin facture à l’outcome et amène son propre modèle de sources de connaissance ; l’argumentaire complet sur l’audit de ce compteur est dans le stack d’agent de support IA, la bonne page si votre vraie question est l’économie de la déflexion.
• Retirez Notion si vos runbooks vivent déjà dans la KB Pylon en collections internes. Un second domicile de la connaissance se justifie seulement quand des équipes hors support y écrivent.

Ce que ce stack ne remplace pas

Ce n’est pas une plateforme CS. Health scores, forecast de renouvellement et automatisation de playbooks sont un achat distinct — voir le stack de rétention CS. Ce n’est pas de la communication d’incident : un canal Slack Connect est le mauvais endroit pour annoncer une panne à 60 comptes, et une status page reste nécessaire. Ce n’est pas un programme de QA — noter les conversations que ces canaux produisent, c’est le contrôle qualité du support. Et ce n’est pas de l’analytics produit ; rien ici ne vous dit si le client devenu silencieux utilise encore la fonctionnalité.

Règles d’adéquation

Le bon choix quand le support est B2B et par compte nommé, que plus de la moitié de l’inbound arrive dans des canaux partagés Slack ou Teams, que vous exploitez entre 20 et 300 canaux clients, et que l’engineering est déjà dans Linear. L’économie tient parce que vous payez par siège support, pas par contact.

Le mauvais choix dans trois cas. Volume anonyme ou grand public via un widget web — un modèle centré compte se chiffre mal face à un trafic sans compte. Moins d’une dizaine de canaux clients, où Slack plus le plan gratuit de Linear plus un alias email partagé ne coûte rien et ne perd rien. Et des SLA contractuels audités par le juridique de votre client : confirmez que les définitions et le reporting SLA de Pylon collent aux termes de votre MSA avant de résilier le helpdesk en place, car « première réponse » dans un contrat et « première réponse » dans un outil de support ne sont pas toujours le même événement.