Signalements multiples et incidents collectifs

Coche les lignes dans la liste des tickets et clique sur « Multiple report ». Le bouton devient utilisable à partir de deux lignes cochées.

La boîte de dialogue demande d'abord : « Which ticket stays? » Le ticket le plus ancien est présélectionné, pour que le délai coure depuis le premier contact du demandeur et non depuis sa seconde tentative. Tu peux en choisir un autre.

En dessous figure le sens avec les deux numéros : « #11 will be closed and moved into #10. » Avant le clic, il est donc clair quel ticket reste.

Tout suit : les commentaires, les pièces jointes et la description du second signalement. La description devient un commentaire sur l'original, avec son auteur d'origine et sa date. La boîte de dialogue indique les nombres à l'avance.

Le temps saisi est déplacé, pas copié. Sinon, le même travail figurerait sur deux tickets et serait facturé deux fois.

Le second signalement n'est pas supprimé. Il est fermé et renvoie désormais à l'original, et son numéro reste valable.

Le demandeur ne reçoit pas d'e-mail séparé. Il est sur l'original et y voit tout. Le signalement fermé porte un commentaire qui nomme l'original, et il peut le lire.

Il n'y a pas d'annulation. C'est pourquoi tout figure dans la boîte de dialogue avant que tu cliques sur « Merge ».

Ensuite, l'historique des deux tickets consigne qui a fusionné quoi et quand.

Le demandeur a l'ancien numéro de ticket dans sa boîte aux lettres. Il ne sait rien de la fusion de deux signalements et répond au message qu'il a.

Cette réponse arrive dans l'original. Le système suit la référence que porte le signalement fermé.

C'est pourquoi un signalement fusionné n'est jamais supprimé. Sans lui, la référence n'existerait pas et la réponse n'arriverait nulle part.

Toute personne qui a participé à l'ancien signalement peut aussi écrire sur l'original. La vérification se fait sur le ticket nommé dans le message.

Si tu sélectionnes des tickets de personnes différentes, la boîte de dialogue ne les prend pas. Elle nomme chaque ligne refusée et son motif avant que tu cliques.

Le motif se lit : « Different requester — this is an incident, not a multiple report. » Il t'indique aussi où aller à la place.

C'est le garde-fou le plus important de toute la fonction. Si tu fusionnais trente signalements de trente personnes, vingt-neuf d'entre elles perdraient leur ticket et n'auraient jamais de nouvelles.

L'identité du demandeur est décidée d'abord par l'adresse e-mail du ticket. S'il n'y en a pas, c'est un nom tiers dans le champ « User » qui décide, et le même nom compte comme la même personne. Sinon, c'est le compte qui a créé le ticket qui compte.

C'est pourquoi le garde-fou vaut aussi pour les appels téléphoniques. Si un agent enregistre deux appels, les deux tickets ont été créés par lui. Des appelants différents restent malgré tout des appelants différents, parce que leurs noms sont dans le champ.

Si le demandeur ne peut pas être déterminé d'un côté, c'est refusé également. Inconnu n'est pas la même chose que la même personne.

D'autres motifs apparaissent dans le même encadré. Un incident collectif ne peut pas être fusionné. Un original fermé ne reprend plus rien. Et un signalement qui a déjà ses propres signalements ne suit pas, pour qu'aucune chaîne ne se forme.

Quand le serveur de fichiers tombe, vingt personnes le signalent. Chacun de ces signalements est un dossier à part avec son propre demandeur. Fusionner serait faux ici, car dix-neuf personnes perdraient leur ticket.

Coche les signalements et clique sur « Group into incident ». La boîte de dialogue propose trois voies : les ajouter à un incident collectif déjà ouvert, déclarer l'un des tickets sélectionnés comme l'incident collectif, ou créer un nouvel incident collectif avec son propre titre.

Si l'équipe a déjà un incident collectif ouvert, cette voie est présélectionnée. C'est la plus fréquente : la panne est connue depuis longtemps, seuls de nouveaux signalements continuent d'arriver.

Chaque ticket rattaché garde son demandeur, son statut et son propre délai. Rien ne disparaît. L'incident collectif ne regroupe que la réponse.

Tous les signalements d'un incident collectif doivent appartenir à la même équipe. Si une panne touche deux équipes, chacune a son propre incident collectif. Sinon, la résolution d'une équipe viderait la file de l'autre.

Tu peux aussi rattacher les retardataires depuis le ticket isolé. Si l'équipe a un incident collectif ouvert, une indication apparaît en haut avec « Assign » et « Not related ». Le système ne rattache jamais rien de lui-même : un ticket rattaché à tort recevrait une résolution qui ne le concerne pas, et serait fermé au passage.

Le ticket d'incident collectif indique combien de signalements y sont rattachés. Les tickets rattachés portent à leur tour le numéro de leur incident collectif, dans la liste et dans la carte de droite.

« Resolve incident » ferme l'incident collectif et répond à tous les signalements d'un coup. Le texte de résolution est obligatoire : c'est tout l'intérêt de la fonction, car il part vers toutes les personnes concernées.

Chaque ticket rattaché reçoit le texte comme commentaire public, est mis dans le statut choisi, et son demandeur reçoit son propre e-mail. Aucun envoi groupé, cela exposerait les adresses de toutes les personnes concernées.

Le message qui suit indique combien de tickets ont été fermés et combien de demandeurs ont été prévenus. Les deux nombres sont séparés, parce qu'un ticket sans adresse joignable reçoit un commentaire et un statut, mais pas d'e-mail.

Un ticket auquel tu as répondu et que tu as fermé toi-même entre-temps n'est pas touché. Il n'est pas fermé une seconde fois et on ne lui écrit pas de nouveau.

Tant que des signalements ouverts sont accrochés à un incident collectif, il ne peut pas être fermé par le changement de statut habituel. Sinon, vingt personnes resteraient sans réponse, en silence.

La boîte de dialogue et le ticket d'incident collectif portent tous deux la case « Also show as a banner on the sign-in page ». Grâce à elle, tout le monde apprend la panne avant d'écrire un ticket de plus.

La bannière figure sur la page de connexion et dans le système une fois connecté. Elle nomme « Known incident » et le titre de l'incident collectif ; ce titre est donc un texte destiné aux clients.

Si plusieurs annonces sont actives, elles s'affichent l'une sous l'autre. Une maintenance annoncée pour samedi ne chasse pas la panne du jour, ni l'inverse.

Si quelqu'un crée quand même un nouveau ticket, la réponse automatique nomme l'incident collectif. Cela vaut pour un ticket déjà rattaché et pour chaque nouveau ticket de cette équipe, tant que l'incident collectif est ouvert et annoncé. Cela demande l'envoi d'e-mails.

Une fois l'incident collectif résolu, la bannière disparaît d'elle-même. Personne n'a à penser à la désactiver.

Sur la page « Maintenance and incident notices », tu peux voir quel incident collectif tourne actuellement comme bannière. L'interrupteur de cette page concerne la maintenance planifiée et ne s'applique pas aux incidents collectifs.