Workflow de validation pour agences, avec une boîte de réception unique pour chaque décision

Une matrice de validation : qui décide quoi, et avec quelle autorisation

Fixez-la une fois, avant le premier lancement, et chaque discussion ultérieure sur qui aurait dû valider quelque chose sera plus courte. Le tableau énonce ce que la console applique aujourd’hui, ligne par ligne.

Par défaut, un membre de l’équipe de l’agence peut consulter, créer et modifier les ressources et les plans de la Bibliothèque, ce qui signifie qu’il peut soumettre des plans pour validation mais ni les approuver ni publier. Une demande de lancement d’une campagne d’e-mails ou de SMS exige aussi que le demandeur détienne l’accès au CRM, que les membres de l’équipe n’ont pas par défaut. Les administrateurs de l’agence détiennent toutes les autorisations. Un administrateur peut accorder « Approve » ou « Publish » à un responsable, une personne à la fois ou au moyen d’un modèle d’autorisations, et un collègue n’agit que sur les clients auxquels il est affecté. Les décisions de congés ne peuvent pas du tout être déléguées.

Auteur de la soumission, relecteur, validateur, personne autorisée à publier et demandeur, en mots simples

Les mêmes cinq mots reviennent sur chaque onglet. Chacun ne veut dire qu’une chose.

Auteur de la soumission (« Submitter »)

La personne qui envoie un plan en validation. Elle modifie et soumet, et elle ne peut pas approuver son propre plan, sauf si elle est administrateur de l’agence.

Relecteur (« Reviewer »)

La personne qu’un auteur de soumission nomme sur un plan. Le nom est indicatif : il choisit qui est prévenu et qui détient la tâche de relecture, et n’importe quelle personne qui valide peut quand même décider.

Validateur (« Approver »)

Toute personne qui détient l’autorisation « Approve » pour le client. Les validateurs décident des relectures de la Bibliothèque et des validations de plans.

Personne autorisée à publier (« Publisher »)

Toute personne qui détient l’autorisation « Publish » pour le client. Elle lance les plans approuvés, décide des demandes de lancement et demande aux clients de relire les ressources de la Bibliothèque.

Demandeur (« Requester »)

La personne qui a demandé un lancement sans l’autorisation « Publish ». Elle peut annuler sa propre demande tant qu’elle attend.

Sortir les validations du chat et des e-mails en quatre étapes

Les gens continuent de valider là où ils discutent déjà. Un déploiement réussit quand la boîte de réception est plus simple que le message : commencez donc par un client et un seul type de décision.

1. 1

   Listez les oui que vous donnez aujourd’hui

   Pendant une semaine, notez chaque validation qui se fait par chat ou par e-mail : une création, une landing page, une campagne, un lancement, un jour de congé. Classez-les dans les quatre catégories que contient la boîte de réception, et laissez le reste là où il est.

2. 2

   Nommez les validateurs par client

   Choisissez qui valide les plans et qui publie pour chaque client, accordez ces autorisations et affectez ces personnes au client. Un collègue qui n’est pas affecté à un client ne verra pas son travail dans la boîte de réception.

3. 3

   Menez un client pendant deux semaines

   Demandez aux auteurs de soumission de nommer un relecteur et de mettre le motif dans la note. Quand quelqu’un réclame un oui dans le chat, répondez que c’est dans la boîte de réception et décidez-y. La tâche de relecture, la cloche et un e-mail préviennent déjà le relecteur : la plupart l’apprennent donc sans relance.

4. 4

   Faites de la boîte de réception le seul oui

   Au bout de deux semaines, basculez le client suivant. Dites à l’équipe qu’un lancement sans plan approuvé est de toute façon refusé par la console, et commencez chaque journée sur l’onglet « All » (tous), en traitant un compteur supérieur à zéro comme la première tâche.

Ce dont vous protège « Changed since approval » (modifié depuis la validation)

L’avertissement n’est pas un reproche. Il marque le moment où un plan a cessé d’être celui sur lequel quelqu’un s’était accordé.

La comparaison porte sur trois éléments : le plan lui-même, les modèles d’e-mail de la Bibliothèque qu’envoie un plan e-mail, et toute audience enregistrée derrière un plan e-mail, SMS ou payant : la définition de l’audience et, pour une liste fixe, les personnes qui en font partie. La modification de l’un quelconque d’entre eux compte, y compris celle d’un modèle que d’autres campagnes partagent. Un segment défini par des règles peut encore correspondre à d’autres personnes le jour de l’envoi sans rendre la validation caduque. Une soumission en attente qui a été modifiée pendant qu’elle attendait ne peut pas être approuvée, et sa ligne dit qu’il faut la soumettre de nouveau.

Deux limites méritent d’être connues. Si un plan est modifié après la programmation d’un lancement, le répartiteur de lancements compare de nouveau juste avant d’agir, et le lancement échoue alors avec une explication claire sans que rien soit envoyé. Et les ressources de la Bibliothèque fonctionnent autrement : une ressource porte un statut de relecture au lieu d’une empreinte de contenu, si bien que modifier une ressource approuvée laisse sa relecture telle qu’elle était. Rouvrez la relecture quand le travail change.

Un passage de dix minutes dans la boîte de réception pour la personne qui valide

La boîte de réception est conçue pour être vidée par le haut. Cet ordre place d’abord les décisions qui bloquent les autres.

1. 1

   Commencez par l’onglet « All »

   Lisez les compteurs des onglets. Si le sélecteur de l’en-tête a restreint le filtre client à un seul compte, élargissez-le d’abord, pour que rien n’attende derrière un filtre que vous aviez oublié.

2. 2

   Prenez d’abord les demandes de lancement

   Quelqu’un attend pour publier. Lisez les contrôles et la ligne de conséquence, puis approuvez ou refusez avec un motif. Un contrôle en échec apparaît dans la boîte de dialogue et bloque l’approbation.

3. 3

   Puis les plans

   Ouvrez chaque plan depuis sa ligne. Une ligne signalée comme modifiée après la soumission ne peut pas être approuvée : demandez donc une nouvelle soumission plutôt que d’attendre. Demandez des modifications avec une note qui nomme ce qu’il faut changer.

4. 4

   Puis la Bibliothèque

   Ouvrez chaque relecture telle que le client la verra. Approuvez, demandez des modifications, ou passez outre la validation, ce qui consigne que personne n’a relu la ressource et ne s’affiche pas comme approuvé. Épinglez un commentaire à l’endroit que vous visez.

5. 5

   Terminez par les congés et « Also waiting » (également en attente)

   Les administrateurs décident des congés en dernier, avec un motif pour chaque refus. Si la carte « Also waiting » montre des entrées de feuille de temps ou des révisions de scripts de réservation, ouvrez la Feuille de temps ou Scripts de réservation depuis ses liens.

Trois habitudes gardent le passage court : soumettre avec une note, nommer un relecteur, et décider dans la boîte de réception plutôt que dans le chat. La boîte de réception se relit chaque fois que vous revenez sur l’onglet et une fois par minute tant qu’elle reste ouverte : vous pouvez donc la laisser ouverte et retrouver un compteur à jour.

Ce que le workflow de validation laisse de côté, pour que personne ne suppose qu’il le fait

Une file de décisions n’est digne de confiance que si ses bords sont clairs.

• La boîte de réception n’envoie aucun rappel et n’escalade pas. La soumission d’un plan fait sonner la cloche et envoie un e-mail au relecteur, ou à toutes les personnes qui valident pour le client quand aucune n’est nommée, et crée une tâche de relecture à échéance dans trois jours : la date de cette tâche dans Projets est donc la relance. Le résumé du matin, envoyé les jours ouvrés par défaut, liste aussi les relectures de la Bibliothèque, les entrées de temps et les congés qui vous attendent, mais pas les plans ni les demandes de lancement. Une soumission dans la Bibliothèque prévient les personnes qui valident et ne crée aucune tâche. Un élément attend qu’une personne le décide.
• À part l’e-mail, elle ne publie ni n’envoie rien à votre place aujourd’hui. Un lancement payant, social ou SMS est enregistré comme fait à la main : la validation crée une tâche et un export de la spécification figée, et quelqu’un le marque comme lancé, publié ou envoyé. Un lancement d’e-mails est l’exception : lui, il envoie.
• Elle ne décide ni des feuilles de temps ni des scripts de réservation. Ceux-ci sont comptés sous « Also waiting » et décidés dans leurs propres outils.
• Ni les plans, ni les lancements, ni la boîte de réception ne sont montrés aux clients. Un client voit les ressources de la Bibliothèque que vous partagez avec lui, dans le portail, et relit celles que vous lui demandez de relire.
• Elle montre à chacun les clients qu’il peut voir. « Approve » et « Decline » (refuser) n’apparaissent que là où il détient l’autorisation, une ligne de plan ou de lancement en attente qu’il ne peut pas décider dit qui le peut, et l’onglet « Time off » (congés) n’apparaît que pour les administrateurs.
• Elle ne lance pas une seconde fois un plan dont le lancement est terminé. Pour l’envoyer de nouveau, dupliquez le plan et faites approuver la copie. Un lancement échoué, annulé ou refusé peut être retenté.

Relecture client : où s’insère l’approbation du client

Les plans et les lancements sont des décisions internes. La validation du client s’applique aux ressources de la Bibliothèque que vous partagez avec lui.

1. 1

   Approuvez d’abord en interne

   Une ressource peut être partagée avec un client une fois qu’un validateur de l’agence l’a approuvée ou a passé outre la validation. Les ressources déjà partagées avant l’existence des validations sont étiquetées comme partagées et jamais bloquées.

2. 2

   Partagez, puis demandez la relecture

   Une personne disposant de l’autorisation « Publish » partage la ressource et demande la relecture du client, avec une note facultative que le client voit avec la demande. Les commentaires marqués comme partagés sont visibles du client aussi.

3. 3

   Le client répond dans le portail

   Un administrateur du portail approuve, et tout membre du portail peut demander des modifications. Les deux se font sur la ressource telle que le client la voit, avec des commentaires qu’il peut épingler à l’endroit qu’il vise.

4. 4

   Annulez, rouvrez ou redemandez

   Le client peut annuler une approbation dans l’heure. Après une demande de modifications, vous modifiez et redemandez. Vous pouvez retirer la demande tant qu’elle est chez le client, et rouvrir la relecture une fois qu’elle a été approuvée ou dispensée.

Dans la boîte de réception, ces ressources se rangent sous « With the client » (chez le client) dans l’onglet « Library » tant que le client ne les a pas approuvées, puis sous « Decided » (décidé). Si le client demande des modifications, elles restent sous « With the client » jusqu’à ce que vous redemandiez ou retiriez la demande. La relecture client exige le portail client, inclus avec les formules Scale et Enterprise. Les visuels sont un cas fréquent, et la gestion des créations montre comment les versions et la relecture se rangent sur la création elle-même.