Actions groupées sur la liste des tickets

La liste des tickets a une colonne de cases à cocher tout à gauche. Elle est là pour les administrateurs et les agents. Un client ne la voit jamais.

La case de la ligne d'en-tête sélectionne toutes les lignes de la page que tu regardes. Elle ne sélectionne pas l'ensemble du résultat. S'il t'en faut davantage, resserre le filtre : un filtre est une façon plus honnête d'énoncer une quantité qu'une case qui couvrirait aussi des tickets que tu ne vois pas.

La sélection s'efface dès que tu changes de page, que tu filtres, que tu cherches ou que tu changes d'équipe. Aucune sélection ne voyage ainsi alors qu'elle n'est plus à l'écran.

La liste de l'image ne montre pas tous les tickets. En haut à droite, à côté de « Filter », figure le mot « active », et à côté « Reset » : les tickets fermés sont masqués, parce qu'une action groupée vise les dossiers encore en cours. Une sélection ne couvre jamais que ce que la liste montre à cet instant.

Dès la première coche, une barre apparaît au-dessus de la liste. Elle affiche « 20 selected », à côté « Clear selection » et les boutons « Change status », « Assign », « Assign to me » et « Apply template ». Plus à droite se trouvent « Multiple report » et « Group into incident » ; ces deux-là concernent les signalements en double et sont expliqués dans le bloc suivant.

« Change status » ouvre une petite boîte de dialogue. Tu choisis le statut cible, et la ligne en dessous dit aussitôt à combien des tickets sélectionnés il s'applique.

Si le statut cible exige un commentaire, une zone de texte apparaît. En dessous figure le nombre de tickets auxquels le texte est destiné. Il va à chaque ticket modifié, pas seulement au premier.

Tous les statuts n'apparaissent pas dans la liste. Les statuts système manquent, parce que personne ne les pose à la main. « Waiting for other team » manque également : ce statut crée un sous-ticket pour une équipe cible, et tu choisis cette équipe par ticket. Dans un lot, il n'y aurait qu'une seule saisie pour cela.

Un ticket sans responsable t'est attribué quand tu changes son statut sur la page de détail. Dans un lot, cela n'arrive pas : « fermer 30 tickets » voudrait sinon dire en silence « 30 tickets attribués à moi » et 30 e-mails.

Cette boîte de dialogue ne change rien d'autre. La priorité, la catégorie et tout le reste se règlent en lot par un modèle de réponse.

« Assign » ouvre la liste des agents. Les agents absents restent sélectionnables et ne sont que signalés comme tels, exactement comme sur un ticket isolé.

« Assign to me » est la même boîte de dialogue avec ton propre nom présélectionné. C'est un raccourci, pas une deuxième voie, et les mêmes règles s'y appliquent.

Une attribution peut envoyer un e-mail à l'agent. Il faut pour cela Professional et l'interrupteur « Send assignment e-mails » de l'équipe. Les messages lors d'une attribution à soi-même sont désactivés par défaut. La boîte de dialogue en indique le nombre à l'avance : « This sends 11 e-mail(s) to the selected agent. » Onze tickets font onze messages.

L'agent doit appartenir à l'équipe du ticket concerné. Une sélection qui couvre deux équipes ne peut donc pas être confiée d'un seul tenant à une seule personne. Ce n'est pas une limite de l'action groupée : la même règle s'applique sur un ticket isolé.

Une attribution ne peut pas être remise sur « personne ». Cela n'existe pas sur un ticket isolé, cela n'existe donc pas non plus dans un lot.

« Apply template » applique un modèle de réponse à tous les tickets sélectionnés. Chaque ticket reçoit le même commentaire qu'il recevrait si tu appliquais le modèle à la main.

La liste propose les modèles de toutes les équipes présentes dans la sélection. Un modèle apparaît dès qu'il convient à au moins un ticket sélectionné ; à combien il convient vraiment, c'est l'aperçu qui le dit ensuite.

Le serveur résout les variables par ticket, chaque client reçoit donc sa propre formule d'appel et son propre numéro de ticket. L'indication dans la boîte de dialogue le dit également.

Les actions du modèle sur les champs s'exécutent avec, et ses pièces jointes sont copiées sur chaque ticket.

Dans un lot, toutes les actions du modèle s'exécutent. Tu ne peux en retirer une que sur un ticket isolé ; si tu ne veux pas d'une action, utilise un modèle qui ne l'a pas.

S'il n'existe aucun modèle pour les équipes de la sélection, la boîte de dialogue le dit : « No reply template is available for the teams of the selected tickets. »

Les trois boîtes de dialogue affichent la même ligne avant que quoi que ce soit ne se passe : « Applies to 19 of 20 selected ticket(s) ».

En dessous figure l'encadré « Will be skipped » avec une ligne par ticket qui ne suit pas, chacune nommant le numéro du ticket et le motif. Tu lis donc avant le clic pourquoi le nombre est plus petit que ta sélection.

Après l'exécution, il est indiqué « 19 changed, 1 skipped » et le même encadré devient « Not changed ». Le contenu est le même ; il a seulement cessé d'être une prévision pour devenir un constat.

Les motifs sont ceux du ticket isolé. Un ticket est déjà dans le statut cible. La transition n'est pas autorisée depuis son statut actuel. Il appartient à une équipe dont tu n'es pas responsable. L'agent choisi ne fait pas partie de son équipe. Il attend une approbation. C'est un incident collectif avec des signalements ouverts. C'est un ticket principal avec un sous-ticket ouvert.

Les tickets sautés restent sélectionnés, les tickets modifiés non. Un deuxième essai avec une autre cible est donc à un clic, et personne n'a à deviner lesquels sont encore en suspens.

L'aperçu est un deuxième avis, pas une autorisation. Quand l'action s'exécute, le serveur vérifie de nouveau chaque ticket : un ticket peut changer entre l'affichage et le clic.

Un appel accepte au maximum 200 tickets. Avec 20 lignes par page, on en est loin.

Une case d'envoi de message n'apparaît que pour les modèles qui en envoient un, et seulement si le canal de messagerie est ouvert. Elle est vide par défaut, une action groupée n'écrit donc rien vers l'extérieur tant que tu ne l'as pas cochée.

Si le canal est fermé, le motif prend la place de la case : soit l'envoi d'e-mails est désactivé, soit les boîtes aux lettres des équipes sélectionnées n'envoient pas les messages liés aux actions de ticket. Tu le lis avant le clic, pas après dans le résultat.

Dès que tu la coches, un avertissement orange apparaît avec le nombre : « This sends 20 e-mail(s) to customers. » Le nombre vient de l'aperçu et correspond au nombre de tickets auxquels le modèle convient réellement.

Changer le statut et attribuer n'écrivent jamais aux clients. L'attribution envoie bien un e-mail, mais à l'agent. Appliquer un modèle en lot est la seule voie sur laquelle un message au client naît.

L'envoi dépend du canal de messagerie et donc de Professional. S'il est désactivé, aucun message ne part et l'historique n'en mentionne pas non plus. Il ne prétend jamais à une remise qui n'a pas eu lieu.

Chaque changement fait par une action groupée apparaît dans l'historique du ticket isolé. Il y ressemble à n'importe quel autre changement, avec une ancienne et une nouvelle valeur.

Le demandeur voit ces lignes également. Pour lui, un changement de statut est le même événement, qu'il ait été déclenché seul ou en lot. Le cacher ne serait pas plus discret, seulement pire.

Une attribution groupée écrit la ligne avec la nouvelle personne responsable. Pour un ticket qui était sur « Open », une deuxième ligne suit avec le statut, parce que le ticket attribué passe alors à « Assigned ».

S'y ajoute une ligne interne qui porte la référence de l'exécution. Cette référence permet de retrouver plus tard tous les tickets de la même exécution. Le demandeur ne voit pas cette ligne.

Chaque ligne nomme la personne qui a déclenché l'action groupée.

Un ticket sauté ne reçoit aucune entrée, pas même une sur la tentative. Ce qui n'a pas eu lieu n'apparaît pas dans l'historique.