Résumé

  • Les champs du ticket source ne sont pas repris dans le ticket de destination, même si les anciens commentaires restent consultables dans le ticket fermé.
  • Il faut distinguer la clôture administrative, la règle de calcul du rapport et la visibilité des commentaires : aucune ne démontre seule un meilleur service.

La priorité ne se fusionne pas toute seule

Deux demandes concernent peut-être le même problème sans le décrire avec la même gravité. Si elles sont réunies dans Zendesk, quelle priorité devient celle du dossier de travail ? La documentation donne une réponse plus précise qu’une promesse de consolidation : les champs du ticket source, notamment ses étiquettes, son type, sa priorité et son statut, ne sont pas transférés. Les champs renseignés dans le ticket de destination sont ceux qui sont conservés.

Choisir la destination revient donc à choisir un point de départ documentaire. Ce n’est pas nécessairement un mauvais choix. Cela signifie simplement que l’opération ne réalise pas, à elle seule, un arbitrage entre toutes les classifications antérieures. Une équipe ne devrait pas lire la priorité finale comme la preuve d’une réconciliation automatique.

L’exemple de deux demandes de gravité différente reste ici hypothétique. Aucun compte client ni ticket privé n’a été examiné. Il sert à rendre visible une conséquence de la règle : une justification opérationnelle peut être nécessaire pour expliquer pourquoi ce ticket, avec ses valeurs, devient le dossier commun.

Pour l’acheteur d’un service logiciel, l’enjeu n’est pas un supplément de prix supposé. Les dossiers d’assistance servent à comprendre les problèmes récurrents, à organiser le travail et à apprécier le service reçu. La possibilité de réunir des demandes ne suffit pas à garantir que leurs différences resteront interprétables dans les informations utilisées ensuite.

Cette distinction évite aussi de rejouer le seul débat sur le coût des sièges ou sur une résolution facturée par un outil d’IA. Le sujet est ici la provenance des champs et le périmètre des preuves après fusion. Une organisation peut maîtriser ces débats commerciaux et néanmoins attribuer au ticket conservé des propriétés qu’il n’a jamais héritées.

Une histoire accessible n’est pas une copie complète

Zendesk précise que les anciens commentaires restent consultables dans le ticket fermé par la fusion. Il serait donc inexact de parler d’un effacement de toute l’histoire. Mais un accès à l’ancien dossier ne transforme pas le nouveau en copie intégrale de ses commentaires et de ses champs.

Dans l’interface ordinaire, le dernier commentaire public du ticket source apparaît dans la fenêtre de fusion. L’agent peut le modifier ou le retirer ; sinon il figure dans le commentaire du ticket de destination, avec un lien vers le ticket fermé. Les autres commentaires antérieurs ne sont pas directement ajoutés au nouveau ticket.

Le lecteur dispose ainsi d’un parcours de consultation particulier. Celui qui suit le lien peut retrouver des échanges que celui qui se contente du ticket actif ne verra pas immédiatement. Ce n’est pas la même chose que perdre ces échanges. Ce n’est pas non plus la même chose que les intégrer au dossier de travail.

Les pièces jointes suivent une autre mécanique dans la documentation de l’API : celles du ticket source sont copiées vers la destination et peuvent être incluses dans le commentaire de destination. Une pièce copiée, un commentaire historique accessible par lien et un champ non transféré constituent trois formes différentes de continuité.

Le responsable de la fusion doit comprendre ces formes au lieu de les ranger sous une formule générale de « conservation des données ». Une procédure peut conserver des éléments utiles tout en changeant la manière dont ils sont lus, classés et mobilisés. La question pratique est ce qu’un futur lecteur pourra raisonnablement déduire du dossier commun.

Le rapport commence par une sélection

Le ticket source reçoit l’étiquette closed_by_merge. Zendesk propose une recette Explore permettant d’exclure les tickets ainsi fermés. Sa documentation indique également que les champs du ticket fermé par la fusion ne permettent pas de produire les rapports correspondants. Cette limite doit rester décrite à son périmètre documentaire : elle ne prouve pas la disparition physique de toutes les données ni l’impossibilité de toute analyse indépendante.

Exclure les sources fusionnées peut être pertinent pour compter les dossiers de travail distincts. Cela ne répond pas nécessairement à une question sur toutes les demandes entrantes. Le logiciel fournit une manière de sélectionner ; l’organisation doit encore choisir ce que le résultat prétend mesurer.

La FAQ sur les tickets résolus en une seule réponse renforce cette nécessité. Elle définit cette population par des tickets résolus ou fermés ayant moins de deux réponses et précise que les commentaires de fusion entrent dans le calcul par défaut. Elle explique aussi comment écarter les tickets fusionnés.

Il serait excessif d’affirmer qu’une fusion embellit toujours ce taux. Selon les échanges antérieurs, les commentaires, les filtres et le calcul retenu, l’effet peut être différent. Aucune variation de taux n’est mesurée dans cette recherche. Le constat solide est qu’une comparaison réclame une règle de population et un traitement des commentaires comparables.

Le rapport ne devient pas faux parce qu’il exclut certains tickets. Il devient difficile à interpréter lorsque cette exclusion est oubliée dans le récit du résultat. Une liste plus courte peut refléter une organisation différente des dossiers ; elle ne démontre pas, à elle seule, une diminution du travail nécessaire ou une amélioration pour les clients.

Réunir les dossiers peut réunir les publics

Les destinataires constituent une frontière distincte. Lorsque les CC sont activés, Zendesk permet de fusionner des tickets de demandeurs différents : le demandeur du ticket source devient CC du ticket de destination et les CC des tickets d’origine sont également ajoutés. Sans CC activés, la règle ordinaire impose le même demandeur.

Rendre un commentaire de fusion interne ne supprime pas, par cette seule action, les personnes ajoutées à la conversation. À l’inverse, l’ajout de destinataires ne signifie pas que toutes les anciennes notes internes deviennent publiques. L’audience du ticket et la visibilité d’un commentaire sont deux contrôles qu’il faut examiner séparément.

L’interface ordinaire permet de choisir un commentaire public ou interne. Le parcours fondé sur les suggestions de tickets liés propose un choix de visibilité pour le demandeur et les CC. Il faut vérifier le résultat dans le parcours effectivement utilisé, plutôt que supposer un réglage identique dans toutes les interfaces.

Même vider le champ de texte n’est pas une garantie d’absence de commentaire. Zendesk indique que le dernier commentaire source peut alors être utilisé comme commentaire mis à jour. La bonne vérification porte sur le texte final et son public, non sur le simple fait d’avoir effacé le texte proposé.

L’API documente ses propres valeurs de confidentialité : les commentaires de fusion sont privés par défaut, avec des paramètres permettant certaines modifications. Les cas de tickets privés et de canaux sociaux précisés dans la documentation imposent des restrictions particulières. Ces règles ne doivent pas être transformées en valeur universelle pour toutes les interfaces.

Un avertissement ne vaut pas une autorisation générale

L’interface avertit lorsqu’une fusion concerne des organisations, des marques ou des demandeurs différents. La documentation actuelle de l’API ajoute que la séparation des marques, lorsqu’elle est activée, limite la fusion à une même marque. Un avertissement ne démontre donc pas que toutes les frontières peuvent être franchies.

Les rôles des agents et les permissions de fusion, notamment dans les comptes Enterprise, font également partie du cadre. L’autorité d’organiser les dossiers n’est pas une autorité indifférenciée sur les champs, les publics et les frontières de marque. Elle doit être exercée dans les conditions documentées.

L’API renvoie un objet de suivi de tâche et met le travail de fusion en traitement. Sa documentation invite à en vérifier l’achèvement. Il ne faut pas prétendre que la première réponse porte toujours un état d’attente : un exemple actuel peut déjà montrer une tâche terminée. Une demande acceptée, une fusion achevée et un problème client résolu restent trois résultats distincts.

Zendesk décrit la fusion comme définitive et irréversible. L’accès à l’historique reste utile pour comprendre la décision ; il ne recrée pas la disposition précédente des dossiers. La prudence appropriée est donc une politique de preuve avant consolidation, pas une accusation de perte de données ou d’incident que les sources ne permettent pas d’établir.

Sources