Demandes avec tâches et approbation

« Un nouveau collègue arrive » n'est pas un ticket unique. C'est un ordinateur portable, deux comptes, une ligne téléphonique et peut-être un accès depuis l'extérieur. Chaque élément appartient à une autre équipe, et tu veux malgré tout un seul dossier qui te dise où en sont les choses.

C'est à cela que sert une demande. C'est un ticket qui crée ses tâches au moment du dépôt, et chaque tâche devient un ticket à part dans l'équipe qui la traite.

Une demande n'est pas une deuxième chose à entretenir. Elle vit sur un modèle de ticket : sous « Settings → Request workflows », tu trouves tous les modèles de ticket, et tu attaches les tâches à l'un d'eux.

Pour chaque tâche, tu remplis quelques champs. « Task » est le nom que le demandeur lit, « Handled by » est l'équipe qui la reçoit, et « Ticket title » et « What the team has to do » remplissent le ticket qui en sort.

Plusieurs tâches peuvent viser la même équipe. Cette équipe reçoit alors plusieurs tickets, pas un seul ticket avec une liste dedans.

Une tâche sans équipe n'est pas proposée du tout. Le champ le dit lui-même : « Not assigned yet — this task is not offered ». Tu peux ainsi enregistrer un plan qui n'est pas encore terminé.

Au-dessus des tâches figure une phrase qui résume tout le plan : ce qui est créé comme réglage d'usine, ce que le demandeur peut modifier, et qui donne la validation. Change un réglage et la phrase se réécrit.

Devant « Ticket title » figure le texte fixe « Parent ticket title - ». Le nouveau ticket commence par le titre de la demande, suivi de ton titre, par exemple « New colleague in accounting - Set up notebook and docking station ». L'équipe spécialisée voit ainsi à quelle demande appartient une tâche. Si tu laisses le champ vide, c'est le nom de la tâche qui suit à la place.

« Main category » et « Subcategory » préremplissent la catégorie du nouveau ticket. Tu n'obtiens que les catégories de l'équipe indiquée dans « Handled by », car c'est là que le ticket est créé. Si tu changes d'équipe, les deux champs sont vidés. Tu renseignes les deux ou aucun, et s'ils restent vides, le ticket est créé sans catégorie.

Le nom de la demande figure au-dessus des tâches. Le crayon à côté te permet de le renommer. Le nom appartient au modèle de ticket, il change donc aussi sous « Settings → Templates » et dans le formulaire de nouveau ticket.

Quand quelqu'un choisit le modèle dans le formulaire de nouveau ticket, l'encadré « What is needed? » apparaît avec une ligne à cocher par tâche.

Il y a trois types, réglés par tâche. « Selectable, off by default » commence vide, « Selectable, on by default » commence coché et peut être décoché, et « Always — cannot be deselected » s'exécute toujours.

Une tâche qui s'exécute toujours est quand même affichée, avec la mention « (always included) ». Le demandeur doit voir ce qui se passe de toute façon.

Sous l'encadré, tu lis ce qui va en sortir : « Each selected item becomes its own ticket for the team that handles it. »

Un client peut lui aussi déposer une demande, tant que le modèle lui est ouvert. L'interrupteur correspondant se trouve sur le modèle.

Le client ne voit alors que sa propre demande. Les tickets des équipes spécialisées lui restent cachés, même si sa demande les a créés : ces tickets contiennent des identifiants et des notes internes. Leurs notes internes n'apparaissent pas non plus dans l'historique de la demande. Quand une équipe spécialisée ferme son ticket, ses pièces jointes sont copiées dans la demande avec la pastille « Internal », et le client ne les voit pas et ne les télécharge pas.

Si une demande arrive par e-mail, elle devient un ticket ordinaire. Tu lances alors le workflow après coup. C'est le rôle du bouton « Start workflow » dans l'en-tête du ticket.

Dans la boîte de dialogue, tu choisis le modèle adapté sous « Template ». En dessous, tu retrouves le même encadré « What is needed? » que dans le formulaire de nouveau ticket. Coche ce que la demande réclame.

Sous « Title », tu ajustes le titre du ticket. Les titres des tâches commencent par lui. En dessous se trouvent les champs supplémentaires du modèle. Saisis-y les informations de la demande. Les champs obligatoires portent une étoile.

Avec « Start », les tâches sont créées exactement comme pour une demande faite depuis le formulaire. Si le modèle exige une approbation, le ticket et ses tâches restent verrouillés jusqu'à ce qu'elle soit donnée.

On ne peut lancer qu'un seul workflow par ticket. Ensuite, le bouton disparaît. Il manque aussi sur les tickets fermés et sur les tickets qui sont eux-mêmes une tâche. Toute personne autorisée à travailler sur le ticket peut le lancer.

Sur la demande elle-même, les tâches sont listées sous « Workflow tasks », avec le compteur à côté, par exemple « 1 of 4 done ».

Chaque ligne montre le nom de la tâche, le numéro de son ticket, l'équipe et la personne responsable, et le nom est un lien vers ce ticket.

« Terminé » vient du statut du ticket, pas d'une coche séparée. Ce qui compte comme fermé dans la liste des tickets compte comme terminé ici. Deux façons de compter la même chose finiraient tôt ou tard par diverger.

Le bloc n'apparaît que sur une demande. Un ticket ordinaire ne l'affiche pas.

Quand une équipe spécialisée ferme son ticket, son « Closing comment » arrive dans la demande. Il y figure comme note interne, et sa première ligne indique le numéro et le nom de la tâche. Le client ne voit pas cette note.

Les identifiants et tout ce que l'agent de la demande doit transmettre ont leur place dans le commentaire de clôture. Tous les autres commentaires de l'équipe spécialisée restent dans son propre ticket. Si l'équipe ferme sans commentaire, aucune note n'est créée.

Une approbation couvre toute la demande, pas chaque tâche isolée. Huit applications font un message au responsable, pas huit.

Tu mets cela en place sous « Approvals » dans le même plan, et la phrase au-dessus énonce la règle : « One approval covers the whole request. Add a second stage only when single tasks need their own release. » Chaque étape a cinq champs : « Name » est le nom de l'étape, « Covers » dit ce à quoi elle s'applique, « Decided by » dit d'où vient l'approbateur, « Approver » contient la personne, et « Remind after (hours) » règle le rappel.

L'approbateur n'a besoin d'aucun compte dans le système de tickets : tu saisis une adresse e-mail et il décide par un lien. Un responsable qui approuve deux fois par trimestre ne coûte donc aucune place d'agent.

Le message contient exactement un lien vers une page. Il n'y a volontairement aucun bouton d'approbation ou de refus dans le message lui-même : un antivirus qui ouvre chaque lien approuverait sinon.

La page porte comme titre le nom de l'étape. Elle montre le numéro et le titre de la demande, le demandeur, et sous « This decision covers » les tâches sur lesquelles porte cette décision, avec un champ de commentaire et les deux boutons en dessous.

Le lien ne dure pas éternellement, et la page nomme l'échéance : « Please decide by … ». Il est valable 14 jours. Ensuite, la page indique seulement que le lien n'est pas valide ou a expiré, et un administrateur renvoie la demande avec « Reassign ».

Une décision ne peut pas être reprise, et la page le dit ensuite : « A decision cannot be changed. »

Certaines tâches ont besoin d'une validation propre. Un accès depuis l'extérieur n'est pas la même chose qu'un ordinateur portable.

Pour cela, tu ajoutes une deuxième étape et tu la choisis sur la tâche sous « Extra approval ». Tant qu'il est indiqué « None — the request approval is enough », l'approbation de la demande suffit. Les deux étapes sont interrogées en même temps, pas l'une après l'autre. Une étape n'est interrogée que si l'une des tâches choisies la concerne. L'étape pour toute la demande est toujours interrogée.

Une tâche est libérée une fois que toutes les étapes qui la concernent ont donné leur accord. Une tâche sans étape propre démarre tout de suite, sauf si l'étape pour toute la demande attend encore. Elle démarre alors dès que la demande est approuvée.

Jusque-là, la tâche est verrouillée. Son ticket est sur « Waiting for approval » et n'a pas de responsable. À la place des boutons de statut, la carte indique « This ticket is waiting for approval and cannot be worked on yet. » Avant cela, aucune voie ne lui attribue de responsable.

Le verrouillage vaut aussi pour les actions groupées sur la liste des tickets. Sélectionne un tel ticket et tu lis la raison : « This ticket is waiting for approval and cannot be worked on yet. »

Le ticket est quand même créé immédiatement, pour que l'équipe spécialisée voie ce qui arrive et que personne n'ait à surveiller la demande.

Tu peux régler une relance par étape, indiquée en heures.

Si aucune réponse n'arrive, le même message repart après ce délai, avec le même lien que le premier. Celui qui a gardé le premier message peut encore s'en servir.

Sans relance, la demande attend simplement, sans redemander.

Ce qui n'existe pas, c'est une validation par expiration. Sous le champ, c'est écrit noir sur blanc : « A request is never approved automatically. If nobody reacts, it keeps waiting. » Un délai qui donnerait son accord tout seul ne serait pas une approbation, ce serait une formalité.

Refuser exige un motif. Sans texte, la page n'accepte pas le refus.

Le champ dit où va le texte : « Comment (required when you reject — the requester will see it) ». Une note interne n'a pas sa place ici.

Le demandeur reçoit un e-mail avec le motif et n'a pas à demander pourquoi rien ne bouge.

Approuver ne demande aucun motif. C'est l'issue attendue.

Si seule une deuxième étape refuse, le refus ne concerne que les tâches de cette étape. Le reste de la demande continue.

Une tâche refusée reçoit le statut « Rejected » et compte comme terminée, pour que la demande ne reste pas suspendue à quelque chose qui n'arrivera jamais.

Dès que la demande est refusée, les autres approbateurs ne reçoivent plus de messages. Leur lien indique alors « This request has already been rejected. Your decision is no longer needed. » Dans la liste sur le ticket, leur étape affiche « No longer needed: the request was rejected. »

Sur la demande, « Approvals » montre une ligne par étape avec l'approbateur, l'état, et pour une demande ouverte la durée d'attente.

Après la décision, la ligne montre quand elle a été prise et avec quel commentaire. C'est la piste d'audit, et elle reste avec le dossier.

Si l'approbateur est en congés, un administrateur transfère la demande à une autre adresse. Le bouton s'appelle « Reassign » et n'apparaît que tant que la demande est ouverte.

Seul un administrateur peut le faire. Un agent qui pourrait réaffecter pourrait se réaffecter la demande et décider ensuite.

La réaffectation crée un nouveau lien, et l'ancien meurt aussitôt, même si quelqu'un l'a transféré.

Le transfert lui-même apparaît dans la même liste : qui l'a fait, quand, de qui vers qui.

Personne ne peut décider au nom d'un autre. Le lien est la seule voie, et la personne qui l'a reçu est consignée sur le dossier.