Utilisez ce modèle
Un excellent support commence par une excellente documentation des tickets. Avec Trupeer, vous pouvez gagner des heures sur la documentation de support en partant d’un ticket client gratuit et d’un modèle de résolution, en le personnalisant avec vos directives de marque, puis en transformant les tickets résolus en études de cas vidéo pour la base de connaissances de support.
La plupart des équipes support ont un système de ticketing rempli de tickets, mais ne savent pas vraiment ce qui ne fonctionne pas. Tout est classé dans « Autre », les notes de résolution indiquent « corrigé », et le rapport mensuel affiche le volume, sans rien d’autre.
C’est un problème de conception des champs, pas de reporting. Ce modèle couvre les deux parties d’un ticket : l’enregistrement que vous saisissez, qui détermine ce que vous pourrez apprendre, et les réponses que vous envoyez, qui déterminent l’expérience client.
Télécharger le modèle de ticket et de résolution
Format | Idéal pour |
|---|---|
Excel (.xlsx) | Le journal des tickets, avec catégories, codes de résolution et onglets de reporting |
Word (.docx) | Le formulaire de ticket, le rapport de résolution et les modèles de réponse |
Des formulaires de ticket imprimables et remplissables pour les demandes sur place ou le service terrain | |
Google Sheets | Un journal partagé pour les petites équipes sans outil d’assistance |
Google Docs | Les modèles de réponse, à copier dans vos réponses préenregistrées pour l’assistance |
Gratuit, modifiable, sans filigrane. Si vous avez déjà un outil d’assistance, utilisez la liste des champs et la formulation des réponses, et ignorez le journal.
Comment personnaliser ce modèle dans Trupeer
Étape 1 : Ouvrir la section Modèles
Accédez à la section Modèles depuis la navigation principale.
Étape 2 : Sélectionner et ouvrir un modèle
Cliquez sur n’importe quel modèle avec lequel vous souhaitez travailler pour l’ouvrir.
Étape 3 : Développer l’affichage du modèle
Si nécessaire, développez l’affichage du modèle pour voir clairement la mise en page complète et les détails.
Étape 4 : Modifier le modèle
Cliquez sur Modifier pour commencer à modifier le modèle sélectionné.
Dans l’éditeur, vous pouvez :
Ajouter de nouvelles sections
Définir ou mettre à jour des règles de mise en forme
Ajouter un logo et ajuster sa position ainsi que les paramètres associés
Étape 5 : Enregistrer votre modèle personnalisé
Après avoir effectué toutes les modifications nécessaires, cliquez sur Enregistrer pour stocker le modèle mis à jour comme le vôtre.
Étape 6 : Aperçu et ajustements fins du modèle
Lorsque vous souhaitez voir à quoi ressemble votre modèle personnalisé, ouvrez l’Aperçu.
À partir de l’écran d’aperçu, vous pouvez continuer à effectuer des ajustements directement si nécessaire, afin de garantir que le modèle s’affiche exactement comme vous le souhaitez.
Avec un ticket client et un modèle de résolution, vous pouvez :
Gagner du temps sur la rédaction : évitez la page blanche grâce à une structure conçue pour la documentation des tickets.
Standardiser la qualité du support : des champs intégrés garantissent que chaque ticket capture les informations clés.
Rester fidèle à votre marque : appliquez votre logo, vos polices et vos couleurs grâce au kit de marque de Trupeer.
Construire une base de connaissances plus solide : les tickets résolus deviennent de futurs articles d’aide et des runbooks.
Repérer les tendances : des tickets standardisés facilitent l’identification des problèmes récurrents.
Toucher des équipes internationales : traduisez les modèles de tickets en 65+ langues en un clic.
Les deux parties d’un modèle de ticket
L’enregistrement. Ce qui est saisi : qui, quoi, quand, le niveau d’urgence, la catégorie, ce qui a été corrigé. Cette partie est invisible pour le client et détermine tout ce que vous pourrez apprendre ensuite.
Les réponses. Ce que le client reçoit à chaque étape : accusé de réception, mises à jour, notification d’escalade, résolution, suivi. C’est cette partie sur laquelle il vous juge.
Les équipes ont tendance à investir dans la deuxième partie et à négliger la première, c’est pourquoi le reporting du support produit si souvent des graphiques de volume sans apporter d’insight. Les deux sont inclus dans ce modèle.
Les champs du formulaire de ticket
Chaque champ doit mériter sa place. Chacun de ceux que vous ajoutez ralentit la saisie, et les champs que personne n’utilise se remplissent de données inutiles.
Saisi à la réception
Champ | Pourquoi il existe |
|---|---|
ID du ticket | Référence pour tout le reste |
Date et heure de création | Démarre l’horloge SLA |
Canal | E-mail, téléphone, chat, portail, sur place. Indique où la demande arrive réellement |
Nom du demandeur et contact | À qui répondre |
Compte ou organisation | Regroupe les tickets par client, là où les schémas apparaissent |
Produit, service ou système | Ce qui ne fonctionne pas |
Catégorie | Voir ci-dessous. Le champ le plus important |
Description | Dans les mots du client, sans reformulation |
Priorité | Déduite de l’impact et de l’urgence, pas choisie librement |
Assigné à | Un nom, jamais une équipe |
Statut | Ouvert, en cours, en attente du client, résolu, clôturé |
Saisi à la clôture
Champ | Pourquoi il existe |
|---|---|
Code de résolution | Ce qui l’a réellement corrigé. Voir ci-dessous |
Notes de résolution | Suffisamment pour que la personne suivante puisse le refaire |
Cause racine | Quand elle est connue. Optionnelle par ticket, essentielle en agrégé |
Délai de première réponse | Mesuré, pas estimé |
Délai de résolution | En excluant le temps d’attente du client |
Rouverte | Oui ou non. Un ticket rouvert n’a pas été résolu |
Article de base de connaissances créé ou mis à jour | Le champ qui s’accumule |
Confirmation client | Ont-ils accepté que c’était corrigé |
Ces deux derniers champs de saisie et de base de connaissances sont les plus souvent manquants, et ce sont eux qui font la différence entre une file d’attente et un système qui s’améliore.
Une catégorisation qui fonctionne vraiment
La catégorie est le champ qui détermine si vos données de ticket ont une quelconque valeur, et elle est presque toujours mal conçue.
Deux niveaux, pas quatre. Catégorie et sous-catégorie. Les hiérarchies plus profondes produisent des étiquetages incohérents, car les agents cessent de lire au-delà du deuxième menu déroulant.
Entre huit et quinze catégories principales. Moins et tout devient « Autre ». Plus et personne ne peut trouver la bonne.
Nommez les catégories d’après ce que le client a vécu, pas d’après la structure interne. « Impossible de se connecter » plutôt que « Plateforme d’identité ».
Pas de « Autre ». Ou si vous devez en avoir un, examinez-le chaque mois et transformez les éléments récurrents en vraies catégories. Un groupe « Autre » au-dessus de cinq pour cent signifie que votre taxonomie est incorrecte.
Catégorisez dès le premier contact, et laissez l’agent le modifier à la clôture si finalement ce n’est pas ça. La catégorisation a posteriori se fait toujours dans la précipitation et est toujours fausse.
Révisez la taxonomie chaque trimestre. Les catégories deviennent obsolètes à mesure que le produit évolue.
Un ensemble de départ viable pour la plupart des équipes support : accès et connexion, facturation et paiements, configuration et paramétrage, comment faire, ne fonctionne pas comme prévu, problème de données, intégration, performances, demande de fonctionnalité, bug, changement de compte, annulation.
Les codes de résolution
L’équivalent côté clôture, et encore plus souvent négligé. Les notes de résolution rédigées en texte libre ne peuvent pas être comptées.
Code | Signifie | Ce que cela vous apprend |
|---|---|---|
Corrigé par le support | L’agent l’a résolu directement | Résolution normale |
Corrigé par l’équipe engineering | Nécessite un changement de code ou de configuration | Volume de défaut produit |
Erreur utilisateur ou mauvaise compréhension | Le produit fonctionnait, mais l’attente ne correspondait pas | Manque de documentation ou d’UX |
Documentation fournie | La réponse existait déjà | Problème de trouvabilité, pas de base de connaissances |
Contournement fourni | Le problème sous-jacent persiste | Backlog caché. Surveillez celui-ci |
Doublon | Même problème qu’un autre ticket | Gonfle le volume si ce n’est pas suivi |
Aucun défaut identifié | Impossible de reproduire | Besoin d’un seuil avant de devenir un schéma |
Retiré par le client | S’est résolu tout seul ou n’était plus nécessaire | Souvent synonyme de réponse lente |
Hors périmètre | Ce n’est pas quelque chose que vous prenez en charge | Vérifiez si cela devrait l’être |
Deux de ces codes sont de l’or diagnostique. Un taux élevé de documentation fournie signifie que votre contenu existe, mais qu’il n’est pas trouvable. Un taux élevé de contournement fourni signifie que vous accumulez des problèmes non résolus qui vont revenir.
Priorité : comment la définir
La priorité doit être déduite, pas choisie. Si on laisse les agents la sélectionner librement, tout sera marqué comme prioritaire, car chaque client est urgent à ses propres yeux.
Faible urgence | Urgence moyenne | Forte urgence | |
|---|---|---|---|
Faible impact | P4 | P4 | P3 |
Impact moyen | P4 | P3 | P2 |
Fort impact | P3 | P2 | P1 |
L’impact correspond au nombre de personnes concernées et à la gravité. Un seul utilisateur gêné, c’est faible. Une équipe entière bloquée, c’est élevé.
L’urgence correspond au délai nécessaire pour résoudre. Un problème cosmétique est faible, quel que soit le nombre de personnes qui le voient. Un délai bloqué est élevé.
Publiez la matrice et les objectifs de réponse pour chaque niveau, afin que la priorité soit un calcul plutôt qu’une négociation.
Le cycle de vie du ticket
Étape | Que se passe-t-il | Ce que le client reçoit |
|---|---|---|
Créé | Ticket créé, catégorisé, priorisé | Accusé de réception avec référence et délai attendu |
Assigné | Propriétaire nommé | Rien, sauf si le propriétaire change |
En cours | Traitement en cours | Mise à jour si le délai promis est dépassé |
En attente du client | Bloqué en attendant des informations | Demande claire, plus une fenêtre d’auto-clôture indiquée |
Escaladé | Transmis selon la matrice | Notification de qui en est désormais responsable et du moment où il répondra |
Résolu | Correctif appliqué, en attente de confirmation | Message de résolution décrivant ce qui a été fait |
Clôturé | Confirmation client ou auto-clôture arrivée à échéance | Enquête de satisfaction optionnelle |
Rouverte | Le problème s’est reproduit ou n’a pas été corrigé | Accusé de réception indiquant que ce n’est pas résolu |
L’état « en attente du client » doit inclure une fenêtre d’auto-clôture définie, généralement de cinq à dix jours ouvrés avec un rappel avant. Sans cela, les tickets restent ouverts indéfiniment et vos indicateurs de délai de résolution deviennent sans signification.
Modèles de réponse par étape
La formulation que les clients voient réellement. Gardez chaque réponse courte et remplacez les champs réservés par des valeurs réelles plutôt que de les laisser génériques.
Accusé de réception
Merci de nous avoir contactés. Votre référence est [ID] et je m’en occupe maintenant. Je reviens vers vous d’ici [time] avec une mise à jour, même si je n’ai pas encore une réponse complète à ce moment-là.
La dernière partie compte. Promettre une mise à jour plutôt qu’une résolution, c’est une promesse que vous pouvez tenir.
Mise à jour du statut
Une brève mise à jour concernant [ID]. J’ai [what you have done] et je suis maintenant [what is next]. Je m’attends à ce que ce soit résolu d’ici [time]. Rien n’est nécessaire de votre part à ce stade.
Envoyez ceci avant que le client ne relance. Une mise à jour spontanée vaut plus qu’une réponse rapide à une relance.
Demande d’informations
Pour avancer, j’ai besoin de [specific thing]. Une fois que je l’ai, je devrais pouvoir [outcome]. Si je n’ai pas de retour d’ici [date], je clôturerai le ticket, et vous pourrez répondre à tout moment pour le rouvrir.
Demandez une seule chose. Trois demandes dans un seul message produisent de manière fiable une seule réponse.
Notification d’escalade
J’ai escaladé ce dossier à [name or team] car [reason]. Ils vous contacteront d’ici [time]. Votre référence reste inchangée : [ID], et je reste en copie.
Dites pourquoi. Une escalade sans raison donne l’impression que le dossier circule.
Résolution
Ce dossier est désormais résolu. La cause était [cause] et j’ai [what you did]. Vous devriez maintenant voir [expected outcome]. Si cela se reproduit, répondez à ce message et il reviendra directement vers moi.
Nommez la cause. « C’est corrigé maintenant » ne donne aucune confiance aux clients quant au fait que cela restera corrigé.
Suivi de résolution
Je fais un point sur [ID] depuis [date]. Tout fonctionne-t-il toujours comme prévu ? Si ce n’est pas le cas, répondez simplement ici.
Deux à trois jours plus tard, et uniquement pour tout ce qui était significatif ou récurrent.
Panne ou problème généralisé
Nous sommes au courant de [issue] qui affecte [scope] et nous y travaillons actuellement. Je vous ferai un point d’ici [time], quel que soit l’avancement. Vous n’avez rien à faire.
Proactif, pour tous ceux qui sont concernés, avant qu’ils ne vous contactent.
Excuses après un incident de service
Vous aviez raison de le signaler et je suis désolé. [What went wrong], et c’est de notre faute. J’ai [action taken] et [what prevents recurrence]. S’il reste quelque chose à traiter, dites-le moi et je m’en occupe.
Précis, sans se défausser, et indique ce qui empêche que cela se reproduise.
Le rapport de résolution
Pour tout ce qui est significatif, l’enregistrement de clôture doit contenir plus qu’une note. Le modèle inclut un rapport de résolution couvrant :
Référence et dates du ticket. Ce que le client a signalé, dans ses mots. Ce qui se passait réellement, ce qui est souvent différent. Cause racine. Ce qui a été fait pour le corriger. Si un contournement a été utilisé et si le problème sous-jacent persiste. Délai de première réponse et délai de résolution. Si cela s’est reproduit. Ce qui a été modifié pour empêcher la récidive, ou une note indiquant que rien n’a été fait. Article de base de connaissances créé ou mis à jour.
Ce dernier couple est ce qui transforme un ticket résolu en amélioration. La plupart des notes de clôture s’arrêtent à ce qui a été fait, ce qui n’aide la personne suivante que si elle retrouve le ticket.
Ce que les données de ticket vous permettent de faire
À condition que les champs soient correctement remplis :
Trouver les cinq catégories les plus volumineuses et corriger la plus importante. En général, la plus grande est un problème de documentation ou de produit, plutôt qu’un problème de support.
Comparer le volume aux codes de résolution. Un volume élevé avec un code « documentation fournie » correspond à un problème de trouvabilité du contenu, pas à une capacité de support.
Surveiller le taux de contournement, qui correspond à votre backlog caché.
Vérifier le taux de rouverture par agent et par catégorie. Un taux de rouvertures élevé signifie que les tickets sont clôturés plutôt que résolus.
Analyser le mix des canaux dans le temps. La croissance du téléphone signifie souvent que le libre-service s’est cassé quelque part.
Croiser par compte. Un client qui ouvre des tickets dans la même catégorie à répétition est confronté à un problème de formation ou de configuration, pas à une mauvaise chance.
Suivre séparément la première réponse et la résolution. Elles ont des causes différentes et des correctifs différents.
Rien de tout cela n’est possible sans une catégorisation rigoureuse dès la réception, c’est pourquoi ce champ reçoit le plus d’attention dans ce modèle.
Modèles de help desk, service desk et tickets
Help desk | Service desk | Support client | |
|---|---|---|---|
À qui ça s’adresse | Au personnel interne, généralement l’IT | Au personnel interne, avec un catalogue de services plus large | Aux clients externes |
Focus | Résolution rapide | Demandes, incidents, changements, problèmes | Questions produit et problèmes |
Cadre | Informel | Souvent aligné ITIL | Variable |
Champs supplémentaires | Actif, appareil | Service, référence de changement, CI | Compte, abonnement, commande |
La liste des champs et la formulation des réponses de cette page fonctionnent pour les trois. Les service desks qui fonctionnent avec ITIL devront ajouter des références de changement et de problème, et la distinction entre incident et demande y compte d’une manière qui ne s’applique pas au support client.
Comment le mettre en place
Concevez d’abord les catégories, avec les personnes qui les utiliseront. Huit à quinze, deux niveaux, nommés d’après ce que le client a vécu.
Définissez les champs requis à la réception, et gardez la liste courte. Chaque champ ralentit la première réponse.
Construisez la matrice de priorité et publiez-la avec des objectifs de réponse.
Définissez les codes de résolution avant la mise en ligne, pas après six mois de texte libre.
Définissez la fenêtre d’auto-clôture pour l’attente du client.
Chargez les modèles de réponse comme réponses préenregistrées et modifiez la formulation pour qu’elle ressemble à votre équipe.
Formez spécifiquement à la catégorisation. C’est le champ le plus souvent mal fait et celui qui compte le plus.
Révisez le groupe « Autre » chaque mois pour le premier trimestre.
Réalisez des rapports sur les catégories et les codes de résolution, pas seulement sur le volume.
Revisitez la taxonomie chaque trimestre.
Bonnes pratiques
Catégorisez dès le premier contact, corrigez à la clôture.
Gardez les champs requis de réception au minimum nécessaire pour que le ticket soit exploitable.
Déduisez la priorité de l’impact et de l’urgence plutôt que de laisser les agents choisir.
Utilisez des codes de résolution, pas du texte libre, pour tout ce que vous voulez compter.
Promettez une mise à jour plutôt qu’une résolution.
Envoyez des mises à jour avant que le client ne relance.
Indiquez la cause dans le message de résolution.
Définissez une fenêtre d’auto-clôture pour l’attente du client.
Enregistrez si un article de base de connaissances a été créé.
Faites des rapports par catégorie et par code de résolution.
Erreurs courantes
Une catégorie « Autre » qui absorbe un tiers des tickets.
Des hiérarchies de catégories à quatre niveaux que les agents cessent de lire.
Des catégories nommées d’après les équipes internes plutôt que d’après les symptômes côté client.
Une priorité choisie librement, donc tout est élevé.
Des notes de résolution en texte libre sans éléments comptables.
Pas de suivi des contournements, donc les problèmes non résolus disparaissent.
Une attente du client sans auto-clôture, ce qui gonfle indéfiniment le nombre de tickets ouverts.
Des messages de résolution qui disent « corrigé » sans préciser ce qui n’allait pas.
Aucun suivi sur les problèmes significatifs.
Un reporting uniquement sur le volume, qui montre à quel point vous êtes occupés et rien sur les raisons.
Une catégorisation a posteriori à la fin du mois.
Transformez les tickets résolus en éléments que les clients peuvent résoudre eux-mêmes
Ouvrez le modèle dans Trupeer AI, appliquez votre kit de marque pour que tout ce qui s’adresse aux clients corresponde, puis modifiez directement chaque section. La configuration se trouve dans le guide du modèle.
Regardez à nouveau le tableau des codes de résolution. « Documentation fournie » signifie que la réponse existait déjà et n’a pas pu être trouvée. « Corrigé par le support », à répétition, dans la même catégorie, signifie que la réponse n’existe pas encore. Les deux sont des problèmes de contenu qui apparaissent comme un volume de support, et les deux se corrigent de la même manière.
Quand un agent résout quelque chose pour la quatrième fois, enregistrez-le une fois. Trupeer AI génère l’article écrit et une vidéo de présentation narrée à partir du même passage, afin que le prochain client puisse regarder le correctif plutôt que d’ouvrir un ticket. Traduisez-le en 65+ langues, et conservez l’ensemble dans votre base de connaissances pour qu’il soit trouvable au moment où quelqu’un est bloqué. Utilisez les mêmes enregistrements pour la formation des agents.
Enregistrez-le. Mettez-le à votre marque. Traduisez-le. Trupeer it.
Questions fréquentes
Existe-t-il un modèle gratuit de système de ticketing ?
Oui. La version Excel fonctionne comme un journal complet de tickets pour les petites équipes sans outil d’assistance, avec catégories, priorité, codes de résolution et onglets de reporting. Si vous avez déjà un système d’assistance, prenez la liste des champs et les modèles de réponse et ignorez le journal.
Existe-t-il un modèle de ticket d’assistance dans Word ?
Oui. Le fichier Word contient le formulaire de réception du ticket, le rapport de résolution et tous les modèles de réponse, afin que vous puissiez imprimer le formulaire ou copier la formulation dans vos réponses préenregistrées pour l’assistance.
Existe-t-il un modèle de ticket de service dans Excel ?
Oui, et Excel est la version que la plupart des équipes trouvent la plus utile. Une ligne par ticket avec les champs de réception et de clôture, des menus déroulants pour la catégorie, la priorité et le code de résolution, plus des onglets qui résument le volume par catégorie et par type de résolution.
Existe-t-il un modèle de ticket de service dans Word ?
Oui. La version Word inclut un ticket de service imprimable adapté au service terrain ou au support sur place, avec des lignes de signature pour le travail effectué et l’acceptation du client.
Existe-t-il un modèle de formulaire de ticket de service IT ?
Oui. La version IT du formulaire de réception ajoute une référence d’actif ou d’appareil, le système concerné, ainsi qu’un champ de référence de changement pour les service desks qui suivent un processus formel de changement.
Existe-t-il un modèle HTML ou Bootstrap gratuit pour un système de tickets de support ?
Non, et il vaut mieux être direct à ce sujet. Ces demandes concernent du code front-end pour construire une interface de ticketing, ce qui est un atout de développement web plutôt qu’un document. Cherchez un thème de tableau de bord admin Bootstrap, ou utilisez une plateforme d’assistance existante, car construire un système de ticketing à partir d’un modèle est généralement plus coûteux que ce que cela semble une fois que vous tenez compte de l’authentification, du routage des e-mails et de la logique SLA. Ce que cette page vous fournit, ce sont la conception des champs et la formulation des réponses, dont vous aurez besoin quel que soit le type d’interface dans laquelle vous les intégrez.
Qu’est-ce qu’un modèle de résolution de ticket ?
Deux choses selon le contexte. Le message de résolution envoyé au client pour expliquer ce qui n’allait pas et ce qui a été fait, et l’enregistrement de résolution saisi en interne avec le code de résolution, la cause racine et le délai de résolution. Les deux sont inclus ici, et le second est ce qui rend vos données de ticket exploitables.
Quels champs un ticket de support doit-il contenir ?
À la réception : ID du ticket, date, canal, demandeur, compte, produit ou service, catégorie, description dans les mots du client, priorité, propriétaire et statut. À la clôture : code de résolution, notes de résolution, cause racine si elle est connue, délais de réponse et de résolution, si le ticket a été rouvert, et si un article de base de connaissances a été créé.
Comment faut-il catégoriser les tickets de support ?
Deux niveaux, huit à quinze catégories principales, nommées d’après ce que le client a vécu plutôt que d’après la structure interne. Catégorisez dès le premier contact et autorisez la correction à la clôture. Évitez le groupe « Autre », ou examinez-le chaque mois et transformez les éléments récurrents en vraies catégories.
Que sont les codes de résolution et pourquoi sont-ils importants ?
Un ensemble fixe de valeurs qui décrit comment un ticket a été résolu : corrigé par le support, corrigé par l’équipe engineering, documentation fournie, contournement fourni, erreur utilisateur, doublon, aucun défaut identifié. Ils sont importants car les notes de résolution en texte libre ne peuvent pas être comptées, et deux de ces codes en particulier vous indiquent où se trouvent vos vrais problèmes.
Comment définir la priorité d’un ticket ?
Déduisez-la de l’impact et de l’urgence à l’aide d’une matrice publiée plutôt que de laisser les agents choisir librement. L’impact correspond au nombre de personnes concernées et à la gravité. L’urgence correspond au délai nécessaire pour résoudre. Publiez la matrice avec des objectifs de réponse afin que la priorité soit un calcul plutôt qu’une négociation.
Que doit contenir un message de résolution de ticket ?
Ce qui était la cause, ce que vous avez fait, ce que le client doit voir maintenant, et comment vous recontacter si le problème se reproduit. Nommer la cause est la partie la plus souvent oubliée, et c’est ce qui donne au client confiance dans le fait que le correctif tiendra.
Combien de temps faut-il attendre avant de clôturer un ticket ?
Cinq à dix jours ouvrés en attente du client, avec un rappel avant la clôture et une déclaration claire indiquant que répondre rouvrira le ticket. Sans fenêtre d’auto-clôture, le nombre de tickets ouverts gonfle indéfiniment et les indicateurs de délai de résolution cessent d’avoir un sens.
Puis-je personnaliser ce modèle de ticket et de résolution ?
Oui, toutes les versions sont entièrement modifiables. Les catégories et les codes de résolution sont les éléments qui doivent être les vôtres, et ils sont fournis comme un ensemble de départ à modifier plutôt que comme une adoption en bloc. Dans Trupeer AI, vous pouvez aussi appliquer votre kit de marque pour que les messages et articles destinés aux clients correspondent.
