En bref
La rétention des connaissances du support consiste à garder au sein de l'équipe ce que sait votre équipe de support, aussi bien quand les agents l'oublient que quand ils partent avec. La plupart des équipes y voient un problème de formation. C'est surtout un problème de stockage. Les réponses de votre meilleur agent vivent dans des macros personnelles, des fils Slack et sa propre tête, et votre helpdesk est conçu pour supprimer ou masquer deux de ces trois endroits.
Certains détails m'ont surpris. Dans Zendesk, rétrograder un agent qui part supprime ses macros personnelles. Front ne peut pas convertir un modèle privé en modèle partagé. HubSpot verrouille les modèles non partagés pour tous les autres, et l'offre gratuite de Slack supprime les messages de plus d'un an. Rien de tout cela n'est un bug. C'est la façon dont chaque outil est conçu, et cela signifie que la rétention doit être une habitude que vous construisez tant que les gens sont encore là.
Ce qui marche : faire du partage le réglage par défaut pour les macros, capturer les réponses des tickets au moment où elles naissent, donner à chaque article un responsable et une date de révision, mener une transmission de connaissances sur 30 jours quand quelqu'un donne son préavis, et mettre la réponse dans le ticket pour que personne n'ait à s'en souvenir. Un coéquipier IA de helpdesk comme eesel aide pour ce dernier point, car il apprend de vos anciens tickets, et la façon dont répondait votre meilleur agent reste dans la file après son départ.
Qu'est-ce que la rétention des connaissances du support ?
La rétention des connaissances du support est l'ensemble des habitudes et des outils qui empêchent une équipe de support de perdre ce qu'elle sait. Elle couvre deux problèmes différents qu'on amalgame souvent :
- Les agents oublient. Une nouvelle recrue suit deux semaines de formation produit, tombe sur les cas particuliers un mois plus tard et ne se rappelle plus quel article les traitait. Elle redemande à un senior.
- Les agents partent. Votre agent le plus expérimenté démissionne, et avec lui partent les contournements, le contexte du type « ce client a toujours besoin de X » et les réponses qu'il a peaufinées pendant trois ans.
La plupart des conseils sur la rétention portent sur le premier problème : répétition espacée, quiz, formations de rappel. Cela aide un peu. Mais d'après mon expérience dans la file de support d'eesel, c'est le second problème qui fait vraiment mal, et la solution des deux se révèle la même. On ne fait pas retenir plus de choses aux gens. On fait apparaître la réponse là où ils travaillent, pour que se souvenir compte moins.
C'est un proche cousin de la gestion des connaissances pour les équipes de support, mais la rétention pose une question plus étroite : si cette personne disparaissait demain, que ne saurions-nous plus répondre ?
Pourquoi les équipes de support perdent leurs connaissances plus vite que la plupart
Le support est un métier à fort turnover avec une longue traîne de questions rares. Cette combinaison est rude pour les connaissances. Ce qui est courant est écrit parce que cela revient chaque jour. Ce qui est rare (la migration de facturation de 2023, l'unique intégration qui plante sur une offre précise) est résolu une seule fois par celui qui l'a pris en charge, et la réponse reste dans ce ticket et dans la mémoire de cette personne.
Un agent de centre d'appels sur Reddit a décrit ce que le fort turnover fait à la mémoire d'une équipe :
"the staff cycle pretty often since it's a minimum wage call centre job. It's never going to be long term for many people so like most places after time people slowly start forgetting who implemented what and just assume."
Lors d'un appel commercial eesel, une société française de services informatiques du secteur public, sur Freshdesk, nous a raconté presque exactement cette histoire. Elle traite environ 3 000 tickets par mois de dépannage ERP complexe avec six agents, et deux de ses agents les plus seniors partaient cette année-là. Toute la raison de notre échange était de mettre ce savoir dans quelque chose qui reste. J'entends une version de cela dans la file toutes les quelques semaines. L'équipe a généralement des milliers de documents (cette société en avait plus de 10 000). Ce qui lui manque, c'est une copie de la façon dont ses seniors répondent vraiment.
Il y a une seconde fuite, plus discrète : les réponses données dans Slack. Une question arrive, quelqu'un la pose dans un canal, un senior répond avec l'explication parfaite, et le ticket est clos avec une version courte. La bonne réponse vit dans Slack, où la personne suivante n'ira pas la chercher.
Où les connaissances du support fuient réellement
C'est la partie que je voudrais que plus de gens connaissent avant le dernier jour d'un agent. Chaque helpdesk a ses règles sur ce qui arrive aux affaires d'une personne qui part, et elles ne sont pas identiques. J'ai parcouru le centre d'aide de chaque éditeur pour voir ce qui survit vraiment.
| Outil | Ce qui arrive aux réponses personnelles d'un agent qui part | Ce qui disparaît d'autre |
|---|---|---|
| Zendesk | Rétrogradation : "Agents' personal views and macros are deleted" (source) | Données CSAT de l'agent ; tableaux de bord Explore non partagés une fois supprimé |
| Freshdesk | Réponses prédéfinies personnelles : "others cannot access the personal folder" (source) | Les rapports vont à la corbeille ; les planifications "permanently deleted" (source) |
| Front | Les modèles privés ne peuvent pas être partagés ; il faut "copy the content and recreate it" (source) | Les données de la boîte individuelle sont détruites "after a delay of a few days" à la suppression (source) |
| HubSpot | L'utilisateur supprimé "must have shared their sales templates prior to removal" (source) | Supprimer (et non désactiver) le retire des rapports |
| Help Scout | Les réponses enregistrées appartiennent à la boîte de réception, pas à la personne (source) | Les workflows qui y font référence deviennent inactifs (source) |
| Gorgias | Les macros sont valables pour tout le compte, gérées par les admins et les responsables (source) | Ses statistiques sont supprimées avec l'utilisateur ; les événements de tickets de plus de 12 mois ne sont pas conservés (source) |
| Slack (gratuit) | Sans objet | 90 jours visibles ; les données de plus d'un an sont supprimées (source) |
Trois lignes méritent un examen plus attentif.
Zendesk. Le parcours de départ recommandé par Zendesk est de rétrograder, puis de suspendre. C'est le bon choix pour l'historique des tickets (les tickets clos gardent l'agent comme assigné, et ses articles gardent son nom). Mais cette même rétrogradation supprime chaque macro personnelle créée par l'agent. Si votre meilleur agent gardait 40 macros personnelles pour les cas bizarres, elles disparaissent le jour où vous le rétrogradez. J'ai écrit davantage sur cette distinction dans mon guide des macros personnelles ou partagées. La bonne démarche est de revoir et de promouvoir les bonnes avant la rétrogradation, pas après.
Front et HubSpot. Les deux gardent les modèles privés privés, ce qui est excellent pour la confidentialité et mauvais pour la rétention. Dans Front, il n'y a aucun bouton de conversion. Quelqu'un doit ouvrir chaque modèle privé et le recréer en modèle partagé, une tâche à faire tant que l'auteur est encore là.
Slack. Si votre équipe tourne sur Slack gratuit, l'offre gratuite vous limite aux 90 derniers jours d'historique et, depuis le 26 août 2024, Slack supprime les messages et fichiers de plus d'un an. Les canvas et les listes ont la même limite d'un an. Un fil vieux de deux ans où votre senior a expliqué le cas particulier de facturation n'est pas seulement difficile à retrouver. Il a disparu.
Un dernier point qui mord au moment des bilans : Gorgias ne garde que les 12 derniers mois d'événements de tickets, et supprimer un utilisateur supprime ses statistiques. La solution de contournement de Gorgias elle-même est de remplacer l'e-mail de connexion de l'utilisateur par un e-mail fictif avant de le supprimer, pour que son historique reste dans vos rapports.
Comment retenir les connaissances du support : 6 habitudes qui marchent
Aucune n'exige un nouvel outil. Il s'agit surtout de l'endroit où l'on consigne les réponses et de qui en est responsable.
1. Faites du partage le réglage par défaut pour les macros et les réponses enregistrées
Les macros personnelles sont l'endroit où vos meilleurs agents rangent leur meilleur travail, et ce sont les premières à disparaître. Fixez une règle simple : si vous avez utilisé une macro personnelle plus de trois fois, elle est promue en macro partagée. Dans Zendesk, demandez à chaque agent de parcourir sa liste personnelle une fois par trimestre, et exportez vos macros pour voir ce qui est déjà partagé. Help Scout et les macros Gorgias règlent surtout cela par conception, puisque les réponses appartiennent à la boîte de réception ou au compte. Dans Freshdesk, sortez les bonnes des dossiers personnels vers des réponses prédéfinies partagées.
Cela améliore aussi la bibliothèque partagée. Une macro qu'un agent a écrite pour lui-même est généralement plus proche de ce que les clients demandent vraiment que celle rédigée en réunion de préparation. Mon guide sur la gestion des macros explique comment éviter que la bibliothèque ne devienne un fourre-tout une fois que vous aurez fait cela.
2. Capturez les réponses pendant que le ticket est ouvert
Le moment le moins coûteux pour noter quelque chose, c'est quand vous venez de le résoudre. C'est l'idée centrale du Knowledge-Centered Service (KCS), la méthode publiée par le Consortium for Service Innovation. Son Solve Loop dit "capture in the workflow", y compris les mots du client lui-même. La phrase du Consortium sur ce qui vaut la peine d'être gardé est une que je répète souvent : "If the issue is worth solving, it is worth saving."
La plupart des helpdesks ont un raccourci pour cela :
- Zendesk permet aux agents de créer ou de demander des articles du centre d'aide depuis un ticket à partir de Suite Growth (source).
- Freshdesk transforme n'importe quelle réponse en brouillon de base de connaissances si vous mettez
kbase@yourcompany.freshdesk.comen copie cachée, sur toutes les offres (source). - L'agent de base de connaissances de HubSpot (bêta, Pro et Enterprise) rédige des articles à partir de tickets clos, en exige au moins cinq et coûte 200 crédits HubSpot par article (source).
Ne visez pas des articles léchés. Le KCS lui-même prévient que "up to 80% of KCS articles will rarely or never be reused", donc un brouillon rapide qui existe vaut mieux qu'un article parfait que personne n'a eu le temps d'écrire. Si vous voulez la méthode complète, mon article sur le transfert de connaissances offshore explique comment fonctionne la licence KCS pour une nouvelle équipe.
3. Sortez les bonnes réponses de Slack
Choisissez une habitude et tenez-vous-y : quand un fil Slack répond à une question de support, quelqu'un le déplace vers la base de connaissances interne avant la clôture du ticket. Une réaction emoji partagée (un 📌 ou un 📝) qui signifie « cela doit devenir un article » fonctionne mieux qu'un document de politique à ce sujet.
Ou inversez la logique et amenez la base de connaissances dans Slack, pour que les gens y posent leurs questions et obtiennent la réponse documentée. C'est ce que fait un bot IA pour Slack branché sur vos documents. Simployer, une entreprise de 350 personnes en Suède, en Pologne et en Norvège, exploite un bot dans Slack sur Confluence, et son équipe a dit que l'accès à la documentation "through the Slack interface has been very well-received by employees" (étude de cas).
4. Mettez la réponse dans le ticket
C'est l'habitude qui règle la moitié « les agents oublient ». Les gens n'oublient pas par négligence. Ils oublient parce que l'article est à trois clics dans un autre onglet, alors que le ticket est juste là. Une réponse qui apparaît dans le ticket est utilisée. Une réponse dans un wiki est retenue, parfois.
C'est à cela que servent les outils d'assistance aux agents (j'ai comparé séparément les meilleurs outils d'assistance aux agents) : ils suggèrent l'article, la macro ou un brouillon complet là où l'agent est en train de taper. Jon Miron, Director of Support and Operations chez Yellowdig, a joliment résumé l'effet sur les nouvelles recrues : "a new customer success hire joked that our eesel AI bot was their best friend during onboarding and interviewing" (étude de cas). C'est la rétention en action : la recrue n'a pas besoin de retenir la réponse, car l'IA l'a trouvée pour elle. Si la montée en compétence est votre principale inquiétude, mon article sur le temps de montée en compétence des agents de support présente les chiffres.
Un responsable informatique sur Reddit a dit la même chose de l'autre côté. Si la base de connaissances est difficile à consulter là où travaillent les agents, les gens se rabattent sur leur mémoire :
"If your searching capabilities do not allow for quick matching or suggestions to the agents then why would they use a KB versus relying on personal knowledge?"
5. Donnez à chaque article un responsable et une date de révision
Les connaissances ne sortent pas seulement par la porte. Elles deviennent aussi obsolètes pendant que tout le monde est encore là. Un article écrit par quelqu'un parti il y a deux ans, sans aucun nom dessus, est le plus dangereux : il a l'air officiel et personne ne le vérifie.
Certains outils aident, moyennant finance :
- La vérification d'articles de Zendesk permet de définir des règles qui remettent les articles à l'état non vérifié selon un calendrier (deux semaines, six mois, un an), avec des e-mails de rappel. Elle est réservée à Enterprise. Et attention au piège : si vous rétrogradez le propriétaire d'un article sans réaffecter ses articles, Zendesk précise qu'il "will still receive article verification emails."
- Front propose des révisions d'articles planifiées à partir de Professional, avec un rappel quotidien pour les articles à échéance (source).
- Confluence Premium et Enterprise peuvent filtrer les pages par propriétaires désactivés et changer le propriétaire de 100 pages au maximum à la fois (source).
- Guru a changé son réglage par défaut en janvier 2026 : les nouvelles collections sont par défaut sur "Does not expire", sans rappels, et Guru s'appuie sur ses agents de connaissances IA pour les contrôles de qualité (source). Si vous comptiez sur les rappels de vérification de Guru, vérifiez vos collections récentes.
Sur les offres sans rien de tout cela, un tableur avec l'article, le responsable et la prochaine date de révision fait l'affaire. L'incontournable : quand quelqu'un part, ses articles reçoivent un nouveau propriétaire dès son dernier jour. Mon guide pour repérer le contenu obsolète du centre d'aide propose un moyen plus rapide de trouver les pires cas.
6. Surveillez les questions auxquelles personne ne sait répondre
La dernière habitude est de repérer les lacunes quand elles s'ouvrent, pas six mois plus tard. Quand un agent expérimenté part, le premier signe est souvent un groupe de tickets qui traînent plus longtemps, sont plus escaladés ou sont rouverts. Étiquetez-les et, une fois par mois, transformez le groupe principal en article. J'ai présenté les rapports à surveiller dans mon guide de l'analyse des lacunes de connaissances du support.
Une transmission de connaissances sur 30 jours quand un agent donne son préavis
Même avec de bonnes habitudes, une démission est le moment où l'on découvre ce qu'on n'a pas capturé. Voici le plan que je suivrais pour un agent senior avec quelques semaines de préavis. Comprimez-le si vous n'en avez que deux.
- Jour -30 : listez ce que seul l'agent sait. Demandez-lui directement : « Pourquoi les gens viennent-ils te voir ? » Puis passez en revue ses 90 derniers jours de tickets pour repérer les sujets que personne d'autre ne traite. Vous obtiendrez une liste de 10 à 20 éléments. Cette liste est tout le projet.
- Jour -21 : travaillez en binôme sur ses tickets les plus difficiles. Confiez les catégories délicates à un successeur et demandez à la personne qui part de relire les réponses, pas de les écrire. On apprend plus en corrigeant un brouillon qu'en lisant un document.
- Jour -14 : transformez ses réponses en macros et articles partagés. Parcourez ses macros personnelles et réponses enregistrées et promouvez celles qui valent la peine d'être gardées. Rédigez de courts articles internes pour chaque élément de la liste du jour -30. Restez sommaire. S'il avait des centaines de réponses, vous pouvez aussi générer des macros à partir d'anciens tickets au lieu de toutes les lire.
- Jour -7 : transmettez les fils ouverts et les relations. Réaffectez les tickets ouverts un par un avec une note, pas en bloc au groupe. Dans Help Scout, faites toute réaffectation par workflow avant la disparition du compte, car il n'y a "no way to do this" une fois l'utilisateur supprimé.
- Jour 0 : occupez-vous du compte en dernier. Réaffectez la propriété des articles, déplacez les tableaux de bord Explore ou les rapports qu'il possède, puis rétrogradez ou désactivez. Dans Zendesk, rétrogradez et suspendez plutôt que de supprimer. Dans Gorgias, remplacez l'e-mail de connexion par un e-mail fictif avant de supprimer pour que ses statistiques restent.
L'étape que les gens sautent est la discrète : qui entretient ce que cette personne entretenait, et où c'est stocké. Dans le même fil Reddit, l'agent du centre d'appels expliquait que l'essentiel du matériel de formation reposait sur des guides qu'il avait créés lui-même et hébergés sur son propre domaine. Après que le compte est passé à un nouveau centre d'appels et que son domaine a expiré, la nouvelle équipe a perdu le "80% part of the training pack." Un autre commentateur a résumé :
"Love how everyone took your knowledge base and its regular updates for granted and no one at any level questioned who was maintaining that or where."
La liste de contrôle du jour 0 de votre helpdesk
L'ordre de la dernière étape compte plus que ce que l'on croit, et il diffère selon l'outil. Voici ce qu'il faut sauvegarder avant la disparition du compte.
Avant son dernier jour : ce qu'il faut sauvegarder dans votre helpdesk
Choisissez votre outil pour voir ce qui disparaît quand le compte d'un agent part, et dans quel ordre agir. Le tout issu du centre d'aide de chaque éditeur.
- Passez en revue ses macros personnelles et recréez les utiles en macros partagées.
- Réaffectez la propriété de ses articles, sinon les e-mails de vérification continuent de lui arriver.
- Déplacez ou partagez les tableaux de bord Explore qu'il a créés. Ceux qui ne sont pas partagés sont irrécupérables une fois l'utilisateur supprimé.
- Réaffectez les tickets ouverts avec une note. Les tickets clos le gardent comme assigné.
- Rétrogradez en utilisateur final, puis suspendez. Ne supprimez pas.
- Demandez-lui de copier les réponses prédéfinies personnelles utiles dans un dossier partagé.
- Recréez les rapports qu'il a créés (la désactivation les envoie à la corbeille) et les planifications (supprimées définitivement).
- Réaffectez les tickets ouverts et en attente avec du contexte. Sinon, ils atterrissent dans la file non assignée.
- Désactivez plutôt que de supprimer. Supprimer efface son affectation sur les tickets et les articles.
- Ouvrez chaque modèle privé utile et recréez-le en modèle partagé.
- Sortez tout ce qui est important de sa boîte individuelle. Elle est détruite quelques jours après la suppression du coéquipier.
- Bloquez ou supprimez le coéquipier et ajoutez la nouvelle recrue comme nouveau coéquipier. Front déconseille de réutiliser l'ancien identifiant.
- Faites-lui partager ses modèles avant sa suppression.
- Réaffectez ses tickets. Les propriétaires supprimés apparaissent comme "Deactivated/Removed" sur le ticket.
- Désactivez si vous voulez que son historique reste dans les rapports. Supprimer le retire des rapports.
- Réaffectez ses conversations ouvertes avant de supprimer l'utilisateur.
- Mettez à jour les workflows qui le référencent. Ils deviennent inactifs à la suppression.
- Les réponses enregistrées appartiennent à la boîte de réception, elles restent donc. Les réponses et notes passées restent aussi.
- Réaffectez d'abord ses tickets ouverts et en pause. La suppression les désassigne.
- Remplacez son e-mail de connexion par un e-mail fictif avant de supprimer, pour que ses statistiques restent dans vos rapports.
- Les macros sont valables pour tout le compte, il n'y a donc pas de macros personnelles à sauver.
- Transférez dès maintenant dans votre base de connaissances les fils de support qui valent la peine d'être gardés, pas au moment du départ de quelqu'un.
- Désactiver un membre ne supprime pas ses messages ni ses fichiers, ses fils restent donc consultables.
- Supprimer un canal supprime ses messages sur toutes les offres. Archivez plutôt.
Si vous n'avez pas 30 jours, les étapes 1 et 3 sont celles à protéger. La liste et les macros sont ce qui continue de servir quand la personne est partie. Et si ce plan commence à ressembler à l'intégration de vos nouveaux agents à l'envers, c'est voulu. Les mêmes éléments alimentent les deux.
Erreurs courantes
- Traiter la rétention comme un projet de formation. Davantage de sessions de rappel ne règleront pas un savoir qui n'existe que dans la tête d'une personne. Écrivez-le d'abord, puis choisissez un logiciel de formation si vous en avez encore besoin.
- Supprimer d'abord le compte de l'agent. Dans la plupart des helpdesks, l'ordre compte. Si vous supprimez avant de réaffecter, vous perdez l'historique, les statistiques ou la possibilité de réaffecter.
- Compter sur l'archive des tickets pour se souvenir à votre place. Les tickets sont consultables en théorie. En pratique, personne ne retrouve le bon d'il y a deux ans, et certains outils rognent l'historique selon un calendrier (les planifications de suppression de tickets de Zendesk existent à partir des offres Team et ne touchent que les tickets archivés, qui sont archivés 120 jours après leur clôture).
- Rédiger lentement des articles parfaits. Une note interne sommaire aujourd'hui vaut mieux qu'un article soigné le trimestre prochain. La gestion de la base de connaissances est itérative.
- Laisser le document de transmission dans le drive de la personne qui part. S'il est dans son dossier personnel, il peut disparaître quand son compte est supprimé. Mettez-le dans un espace partagé dès le premier jour.
Comment eesel aide à garder les connaissances du support dans l'équipe
Je vais être franc sur la raison pour laquelle ce sujet me touche : dans la file de support d'eesel, « nous perdons notre agent senior, l'IA peut-elle apprendre ce qu'il sait ? » est l'une des raisons les plus fréquentes pour lesquelles on nous contacte. Et la fonctionnalité la plus demandée lors de nos appels commerciaux, de loin, est l'entraînement sur d'anciens tickets. Comme l'a dit un cofondateur d'eesel après une série de démos : "People really, really, really want to train on past tickets."
C'est l'angle de la rétention. Le coéquipier IA de helpdesk d'eesel rejoint votre helpdesk existant et apprend de ce que votre équipe possède déjà. Dans Zendesk, la connexion complète lit votre centre d'aide, vos macros et vos anciens tickets, et sait donc déjà comment votre équipe répond avant de traiter le moindre ticket. Cela inclut la façon dont répondait votre senior, dans les réponses qu'il a réellement envoyées, ce qui continue de servir après son départ. Il se connecte aussi à Confluence, Google Drive, Notion et à des sites web, pour que ce qui est dispersé se retrouve au même endroit.
Quelques éléments correspondent directement aux habitudes ci-dessus :
- La réponse dans le ticket. eesel peut rédiger des réponses sous forme de notes internes pour qu'un agent les relise, et n'importe qui peut mentionner
@eeseldans une note interne pour obtenir un brouillon à la demande. Les nouvelles recrues interrogent l'IA au lieu d'interrompre le senior. - Les corrections restent. Quand vous corrigez l'agent, il inscrit la correction dans ses propres instructions, de sorte qu'une règle que votre senior explique une fois devient une règle suivie par chaque brouillon futur. C'est du savoir tacite transformé en règle écrite que vous pouvez lire et modifier.
- Les lacunes sont signalées. Les rapports d'eesel suivent les lacunes de connaissances, c'est-à-dire les questions auxquelles il n'a pas pu répondre à partir de vos documents, et ses skills peuvent rédiger les articles manquants pour que vous les relisiez.
- Questions-réponses internes dans Slack. Le même coéquipier répond aux questions internes dans Slack avec la source en lien, et le dit quand il ne trouve pas quelque chose.
Gcore, une société de cloud et d'hébergement de plus de 500 employés, applique exactement cette répartition : un bot destiné aux clients sur son centre d'aide public et un bot agent interne entraîné sur les macros Zendesk internes et "the entire history of past tickets." Son équipe dit que le bot interne aide les agents à rédiger des réponses "based on what's worked before, and even get new team members up to speed faster" (étude de cas).
Ce qu'eesel ne fait pas : il ne remplace pas les paramètres de départ de votre helpdesk. Promouvez les macros personnelles et réaffectez les propriétaires d'articles dans votre helpdesk avant le dernier jour de quelqu'un, car eesel ne peut apprendre que de ce qui est encore là. Tarifs : l'offre gratuite comprend 100 crédits sans carte, et les offres Teammate démarrent à 299 $ par mois pour 500 crédits, un ticket comptant pour un crédit quel que soit le nombre de réponses nécessaires. Les places sont illimitées, tous les agents peuvent donc l'utiliser.
Essayez eesel avant votre prochaine démission
Si les meilleures réponses de votre équipe vivent dans la tête d'une seule personne et dans un tas de macros personnelles, essayez eesel. Il se branche sur Zendesk, Freshdesk, Gorgias, Front ou Help Scout en quelques minutes, apprend de vos anciens tickets et documents, et continue de répondre comme votre meilleur agent le faisait une fois qu'il est passé à autre chose. L'offre gratuite comprend 100 crédits et toutes les intégrations.
Comment garder les connaissances quand un agent de support part ?