La note interne dit ce qu’un agent pense vraiment du dossier
Un ticket de support est l’un des rares endroits où trois voix cohabitent dans un même objet. Le client décrit son problème avec ses mots, parfois avec sa colère, et il y colle de lui-même son numéro de commande ou son adresse. Un agent lui répond en public. Le même agent écrit en note interne ce qu’il pense vraiment du dossier, et le client ne voit jamais cette troisième voix.
C’est aussi l’archive la plus utile qu’une IA puisse lire dans une entreprise qui vend quelque chose. Elle contient chaque panne que votre produit a provoquée, chaque contournement qui a fonctionné, et le vrai motif derrière les remboursements. Un agent qui arrive lundi met des mois à acquérir ce que cette archive sait déjà.
Les deux choses sont vraies en même temps. La question utile porte donc sur les tickets qu’une IA peut lire et sur les personnes pour lesquelles elle travaille.
Ce que porte le ticket, et ce qu’une IA branchée reçoit
Chaque ligne se vérifie en ouvrant un ticket dans votre propre Zendesk.
| Ce que porte le ticket dans Zendesk | Ce qu’une IA branchée reçoit |
|---|---|
| La description écrite par le client | Le même texte, en tête du ticket |
| Une réponse publique de votre agent | Le même texte, étiqueté comme public |
| Une note interne de votre agent | Le même texte, étiqueté comme interne |
| Une réponse insérée par une macro | Le texte inséré, jamais la macro qui l’a produit |
| Une pièce jointe envoyée par le client | Rien du tout |
| Le groupe qui traite le ticket | Rien dans le texte, ce groupe sert à décider qui a le droit de lire |
La mise en forme des commentaires n’est pas conservée. Le connecteur demande à Zendesk la version en texte simple d’un commentaire, et c’est celle-là qui entre.
Le groupe qui traite le ticket décide qui peut le relire
Zendesk assigne un ticket à un groupe, et un groupe rassemble des agents. C’est la seule permission d’origine sur laquelle il y a quelque chose à reprendre, et le connecteur ne s’appuie sur rien d’autre. Il déploie le groupe en agents, identifie chaque agent dans votre organisation, et range le ticket dans le service dont ils relèvent tous.
Quand ils n’en relèvent pas tous, le ticket n’est rangé dans aucun service et attend la décision d’un administrateur. Il en va de même quand le groupe est vide, quand un de ses agents n’est pas identifiable chez vous, et quand la liste de ses membres revient sans que l’on sache s’il manquait une page.
Le cas qui surprend est celui du ticket sans groupe. Dans Zendesk, c’est le ticket le plus largement visible, celui que tous vos agents peuvent ouvrir. Dans votre Kastel, c’est le moins lisible de tous, parce qu’une visibilité générale ne désigne aucun service en particulier. Un administrateur peut évidemment le ranger, et cette décision est enregistrée comme le reste de ce que votre entreprise décide de son savoir.
Une dernière précision décide de l’ampleur d’un incident. Chaque groupe est lu séparément. Quand la clé d’accès ne peut pas lire un groupe précis, seuls les tickets de ce groupe attendent un administrateur, et le passage continue pour les autres. Quand la clé est révoquée, le passage entier s’arrête et le signale comme un problème d’accès. Cette clé n’apparaît dans aucune URL, aucun journal ni aucun en-tête de fichier, et notre page sécurité décrit où elle est gardée. Intercom, qui traite la même matière, résout la question autrement.
Le ticket, sa réponse publique et sa note interne
Le connecteur porte sur les tickets de Support, et sur rien d’autre de votre compte Zendesk.
Les pièces jointes sont exclues pour une raison concrète. Un client joint une capture d’écran sans regarder ce qu’il y a autour de l’erreur, et cela va du relevé bancaire ouvert dans un autre onglet à la conversation privée restée visible. Le texte du ticket suffit à comprendre le dossier.
Le premier passage remonte tout votre historique de tickets
Zendesk sait dire ce qui a changé depuis la dernière fois, ce qui est plus rare qu’on ne le croit parmi les outils métier. Le premier passage part donc du début de votre historique, sans fenêtre de quelques mois, et les suivants ne relisent que ce qui a bougé.
Le curseur qui marque cette position n’avance jamais au-delà d’un ticket qui a échoué. Quand un ticket échoue, la position se fige avant lui, et le passage suivant le reprend avec tout ce qui le suit dans le flux. Un ticket déjà lu et inchangé ne coûte rien à revoir.
Un ticket que vos agents suppriment passe au statut supprimé dans Zendesk. Le connecteur cesse alors de le lire, et le rapprochement suivant le compte comme absent de votre compte.
Reste un angle mort qu’il vaut mieux nommer. Un changement de composition de groupe ne modifie la date de mise à jour d’aucun ticket, et Zendesk n’émet aucun événement pour ce changement. Le rattrapage se fait donc au passage de rapprochement, qui relit l’ensemble des tickets et recalcule le service de chacun.
Ce que ce connecteur ne fait pas
Il ne protège pas les notes internes de vos agents. Elles entrent avec le ticket, étiquetées comme internes, et elles sont lisibles par le service du groupe qui traite ce ticket, exactement comme la réponse publique. Le groupe décide pour le ticket entier, jamais commentaire par commentaire. Si vos agents écrivent sur un client des choses qu’un collègue du même service ne devrait pas relire, c’est une habitude à traiter avant de brancher quoi que ce soit.
Il ne travaille pas dans Zendesk. Aucun ticket n’est créé, commenté, réassigné ni fermé, et le transport utilisé n’expose qu’une seule opération, la lecture. Une IA branchée peut vous dire ce qu’un ticket contient, elle ne peut pas y répondre.
Il ne corrige pas un changement de droits à la seconde. Entre deux passages de rapprochement, un ticket dont le groupe a changé de composition garde le service qui lui avait été attribué. La fenêtre est courte et elle existe, et nous préférons l’écrire que la laisser découvrir.
Un ticket supprimé dans Zendesk n’est pas effacé de votre Kastel. La copie déjà lue y est signalée comme disparue à la source et conservée, lisible par les mêmes personnes qu’avant, jusqu’à ce qu’un administrateur déclenche l’effacement. Sur une source qui porte les mots d’un client, cela mérite d’être su avant qu’une demande d’effacement arrive plutôt qu’après.
Voyez comment un contenu est rangé avant d’y brancher une IA.
La page produit décrit la couche de contexte que vos IA interrogent, la façon dont un contenu se range dans un service, et ce qu’un administrateur décide. Le cœur de Kastel est gratuit en self-host, avec tous ses connecteurs.
Voir le produit
