Le SLA de validation, et ce qu'il se passe lorsqu'il est dépassé

Deux chronomètres, et lequel l'emporte

La plupart des validations ne reçoivent jamais de date saisie. Un producteur envoie un cut et personne n'écrit de date limite, le problème n'est donc pas une date manquée, mais une validation ouverte depuis quatre jours sans que personne ne s'en aperçoive. C'est pourquoi le SLA de validation est mesuré à partir du moment où la validation a été ouverte, par rapport à un objectif. L'objectif par défaut est de 72 heures et la fenêtre d'avertissement par défaut est de 12 heures avant celui-ci.

Si quelqu'un a saisi une date d'échéance, cette date l'emporte. Une validation est dépassée lorsque l'objectif s'est écoulé ou que la date d'échéance est passée, selon la première occurrence, et à risque lorsque l'un ou l'autre se trouve dans la fenêtre d'avertissement. Une tâche de rappel distincte s'exécute toutes les cinq minutes et rappelle les validations dont la date d'échéance est arrivée ou se situe dans les 60 minutes à venir, de sorte qu'une date limite saisie est respectée à l'heure près.

Les étapes ont leur propre chronomètre. Une étape peut comporter un SLA en heures ; une tâche qui y entre déclenche le chronomètre, l'état est correct jusqu'à ce que 80 % de la fenêtre se soit écoulée, à risque à partir de là et jusqu'à la date limite, puis dépassé ensuite. L'état est calculé à partir des horodatages à chaque lecture, il n'y a donc pas de compteur qui puisse prendre du retard.

Ce que fait la vérification toutes les 15 minutes

Une tâche planifiée examine les validations en attente de chaque organisation, de la plus ancienne à la plus récente, jusqu'à 500 par organisation et par exécution, et classe chacune d'elles comme correcte, à risque ou dépassée. Pour chaque dépassement dont le délai d'attente de rappel est écoulé, elle envoie la même relance qu'un producteur enverrait manuellement, et liste les validations qui attendent depuis le plus longtemps dans son propre rapport afin qu'un opérateur puisse voir lesquelles.

La relance est limitée à 50 validations par organisation et par exécution. Un studio qui reprend son activité après une fermeture de deux semaines ne doit pas voir tout son historique relancé en une seule fois ; l'exécution suivante s'occupera du reste.

La tâche n'invente pas d'état d'escalade et n'envoie pas d'email au propriétaire. Ce qu'elle fait est réel et enregistré : un marquage de rappel sur la validation, une ligne d'audit indiquant que le rappel a été envoyé par le système, et un message à la personne qui peut agir.

Qui est relancé

Un rappel ne vaut la peine d'être envoyé qu'à la personne que la validation attend. Pour une validation destinée au client, il s'agit du client, et le client n'a pas de compte, pas de place et pas de cloche de notification dans l'application ; ce qu'il a, c'est un accès au portail. La tâche recherche donc des accès actifs qui peuvent décider de cette validation : des accès avec l'autorisation de valider, non révoqués, non expirés, limités à ce projet ou à l'ensemble du client, et comportant un email ou un numéro de téléphone.

Chaque accès de ce type reçoit le rappel sur les canaux dont il dispose : un email qui nomme la validation, indique depuis combien de jours elle est en attente et renvoie vers la page d'accueil du portail, et un SMS contenant le nom du studio et le lien du portail. Aucun identifiant n'est renvoyé ; le client se reconnecte de la même manière qu'il est entré. L'email est envoyé une fois par accès et par jour, et la validation elle-même fait l'objet d'un rappel au maximum une fois toutes les 12 heures.

Lorsqu'aucun accès client n'est joignable - une validation interne, ou un client dont le seul accès est un code remis en main propre sans email ni téléphone - le rappel se rabat sur les responsables de la tâche via la cloche de l'application, qui est la propre liste du studio. C'est le seul cas où le studio doit relancer le client lui-même, et la cloche l'indique.

La relance manuelle, et la trace qu'elle laisse

Un producteur peut relancer une validation manuellement depuis la validation elle-même. C'est le même chemin que prend la tâche planifiée : le marquage de rappel est écrit, une ligne d'audit enregistre qui a cliqué, et le message est envoyé aux mêmes accès. La différence dans le journal réside dans l'auteur : une personne pour la relance manuelle, le système pour la relance planifiée.

Le délai d'attente de 12 heures s'applique aux deux. Un second rappel manuel au cours de cette période est refusé avec un message indiquant que la validation a déjà fait l'objet d'un rappel récemment, plutôt que d'envoyer un doublon au client. Un rappel sur une validation qui n'est plus en attente est également refusé.

Le marquage est écrit avant l'envoi du message, de sorte qu'une panne du fournisseur de messagerie n'annule jamais un rappel ; l'enregistrement indique qu'un rappel a été tenté, et l'exécution suivante pourra réessayer après le délai d'attente.

Lire le SLA dans les analyses

Le chronomètre du SLA alimente les analyses qu'un studio consulte sur son activité. La vue des goulots d'étranglement indique le temps médian qu'une tâche passe à chaque étape, ce qui permet de traduire une étape de review client lente par un chiffre plutôt que par une impression. Le rapport hebdomadaire du propriétaire présente la même image, et le score de risque d'un projet en énumère les raisons, de sorte qu'un projet en attente d'un client depuis trois jours au-delà de l'objectif s'explique de lui-même.

Le décompte de ce qui est en attente d'un client est extrait des validations qui ont réellement été présentées à un client avec un lien de décision, de sorte qu'une validation interne ne gonfle jamais le nombre d'attentes client.

Définir l'objectif

L'objectif de 72 heures et l'avertissement de 12 heures sont les valeurs par défaut avec lesquelles la vérification s'exécute. Les SLA d'étape sont définis par étape sur le workflow, en heures, et un workflow proposé par l'intégration de l'IA comporte un tableau de SLA par étape qui n'est appliqué qu'après examen et validation par le studio ; une étape que le tableau ne nomme pas ne conserve aucun chronomètre, car un chronomètre que personne n'a choisi est pire que pas de chronomètre du tout.

Une date d'échéance saisie sur une validation individuelle est l'instruction la plus précise et l'emporte sur tout le reste. Si un client a promis une réponse pour jeudi, saisissez jeudi.

• Par défaut : 72 heures à compter de l'ouverture, avertissement 12 heures avant.
• Vérifié toutes les 15 minutes ; rappels des dates d'échéance toutes les 5 minutes avec 60 minutes d'avance.
• Un rappel par validation toutes les 12 heures ; un email par accès et par jour.