Participez aux tests de LadVen OSDemander une demo
Aller au contenu principal

Contrôles de protection

Un contrôle de protection est une règle qui empêche d'exécuter une opération tant qu'une condition n'est pas remplie. Par exemple : impossible de faire passer une affaire à l'étape « Contrat » tant que le montant n'est pas renseigné ; impossible de fermer une tâche tant que la liste de contrôle n'est pas terminée. Le contrôle se déclenche au moment de l'opération, affiche un message clair et indique précisément ce qu'il faut corriger.

Les contrôles de protection sont le « fusible » du processus : ils transforment un règlement issu d'un accord verbal en une règle que le portail applique de la même manière à tout le monde.

Ils se configurent à l'adresse /automation/operation-guards, ainsi que depuis l'automatisation CRM dans la section des contrôles.

Quand les contrôles de protection sont nécessaires

Il convient de créer un contrôle là où les collaborateurs « sautent » régulièrement une étape obligatoire :

  • ils ferment une tâche avec une liste de contrôle non terminée ;
  • ils font avancer une affaire dans le pipeline sans renseigner les champs obligatoires ;
  • ils terminent une affaire en gain sans montant ni client ;
  • ils lancent une action sans indiquer un motif obligatoire.

Si l'étape est souhaitable mais pas obligatoire, mieux vaut utiliser une suggestion ou une règle de tâche plutôt qu'un blocage strict.

De quoi se compose un contrôle

Un contrôle se construit à partir de trois parties :

  1. Opération — ce que l'on protège précisément (transition d'étape/de statut ou action).
  2. Condition — ce qui doit être rempli pour que l'opération aboutisse.
  3. Message — ce que verra l'utilisateur si la condition n'est pas remplie.

Formulez d'abord la règle avec des mots : « impossible de faire X tant que Y n'est pas réalisé », et ne configurez le contrôle qu'ensuite.

Quelles opérations peuvent être protégées

Le contrôle s'applique à l'un des deux types d'opérations :

  • transition — changement d'étape d'une affaire ou de statut d'une tâche ;
  • action — bouton ou opération sur une entité (tâche, affaire, projet).

On peut ainsi verrouiller les points les plus à risque : « impossible de gagner une affaire », « impossible de fermer une tâche », « impossible de passer à une étape ».

Portée

Un contrôle possède une portée : toute l'entreprise ou un pipeline spécifique. La portée détermine où la règle s'applique. Un contrôle ciblé sur un seul pipeline ne perturbe pas le travail des autres directions, tandis qu'un contrôle au niveau de l'entreprise fixe un standard obligatoire commun.

Conditions du contrôle

Une condition compare un champ ou un état de l'entité. Sont notamment disponibles :

  • champ rempli / non rempli ;
  • liste de contrôle terminée ;
  • la valeur d'un champ figure dans une liste / n'y figure pas ;
  • comparaison numérique (par exemple, montant supérieur à zéro).

Plusieurs conditions peuvent être combinées pour que l'opération n'aboutisse que si toutes les exigences requises sont satisfaites.

Message de blocage et suggestion

Si la condition n'est pas remplie, l'opération n'aboutit pas et l'utilisateur voit un message de blocage. Un bon message explique non pas « c'est interdit », mais ce qu'il faut faire : « Renseignez le montant de l'affaire avant de passer à l'étape "Contrat" ». Le contrôle peut mettre en évidence le champ concerné ou ouvrir la section appropriée, afin que l'utilisateur comprenne immédiatement où aller corriger.

Le message est l'interface du règlement. Un « Opération interdite » incompréhensible agace ; une suggestion claire fait gagner du temps.

Activation et propriété

Un contrôle n'agit qu'après son activation. Chaque contrôle doit avoir un propriétaire responsable du règlement : les contrôles entravent directement le travail des personnes, c'est pourquoi un contrôle oublié ou trop strict bloque le processus. La liste indique qui a modifié la règle et quand.

États et limites

  • contrôle désactivé — l'opération aboutit sans restriction ;
  • condition remplie — l'opération aboutit normalement ;
  • condition non remplie — l'opération est bloquée et un message s'affiche ;
  • contrôle trop large — il bloque des opérations qu'il ne devrait pas ;
  • pas de droits de gestion sur la portée — le contrôle est accessible en lecture seule.

Bonnes pratiques

  • Ne protégez que les étapes réellement obligatoires, et non tout sans distinction.
  • Formulez le message comme une instruction : ce qu'il faut remplir ou terminer.
  • Utilisez la mise en évidence du champ ou de la section pour orienter l'utilisateur.
  • Limitez la portée du contrôle au pipeline concerné si la règle n'est pas générale.
  • Désignez un propriétaire et révisez les contrôles lorsque le processus évolue.

Erreurs fréquentes

Bloquer une étape non obligatoire. Un contrôle strict là où une suggestion suffit ralentit le travail et entraîne des contournements.

Message incompréhensible. « Opération interdite » n'explique pas quoi faire et provoque des sollicitations du support.

Portée trop large. Un contrôle sur toute l'entreprise casse le travail des directions auxquelles il n'était pas destiné.

Contrôle sans propriétaire. Quand la règle gêne, on ne sait pas à qui s'adresser pour la modifier.

Comment vérifier le résultat

  • lorsque la condition n'est pas remplie, l'opération est effectivement bloquée ;
  • le message explique clairement ce qu'il faut corriger ;
  • la mise en évidence mène au champ ou à la section appropriés ;
  • lorsque la condition est remplie, l'opération aboutit sans entrave ;
  • le contrôle n'affecte pas les opérations situées hors de sa portée.

Scénarios liés