Automatisation et processus metier
L'automatisation dans le CRM sert a faire executer le travail repetitif de maniere identique et sans controle manuel: une nouvelle demande recoit immediatement un responsable, le passage a une etape declenche la tache requise, le client recoit un e-mail base sur un modele, et avant la cloture les conditions obligatoires sont verifiees. Une bonne automatisation accelere le processus et le rend previsible; une mauvaise modifie silencieusement les donnees au point que l'equipe ne comprend plus ce qui s'est passe.
L'automatisation se gere dans la section automatisation du CRM (/crm/automation). C'est le travail de l'administrateur du processus, et non une action quotidienne du commercial.
De quoi se compose l'automatisation
Le CRM propose plusieurs outils, et il est important de ne pas confondre leur role:
- Les regles-robots se declenchent apres un evenement (opportunite creee, etape modifiee, champ modifie) et executent des actions.
- Les controles avant operation se declenchent avant une operation et empechent de la terminer tant qu'une condition n'est pas remplie.
- Les processus metier decrivent un scenario en plusieurs etapes avec des conditions, des attentes et des taches pour les personnes.
- Les modeles d'e-mail stockent le texte des messages externes envoyes par les robots et les processus.
Regles-robots
Une regle repond a la question « que fait le systeme apres un evenement ».
- Evenement (declencheur): creation d'une opportunite, entree dans une etape, modification d'un champ ou lancement manuel.
- Conditions: pour quelles valeurs la regle se declenche; les conditions peuvent etre combinees par « et »/« ou ».
- Actions: une chaine d'etapes — attribuer un responsable, faire passer a une etape, modifier un champ, creer une tache, envoyer une notification, envoyer un e-mail au client, lancer un processus, et d'autres.
- Embranchement: « si — sinon » a l'interieur de la regle pour les differents cas.
- Planification de l'etape: immediatement, avec un delai ou a une heure precise.
- Politique d'erreur: poursuivre ou arreter la chaine en cas d'echec d'une etape.
Chaque regle possede un perimetre d'action (toute l'entreprise, un pipeline ou une etape) et une priorite. Plus le perimetre est large, plus il faut verifier attentivement la regle avant de l'activer.
L'historique d'execution montre ce que la regle a reellement fait: le statut de chaque execution, les etapes realisees et le resultat de la remise des notifications. C'est l'outil principal d'analyse lorsque l'automatisation ne s'est pas comportee comme prevu.
Controles avant operation
Un controle avant operation est une condition qui doit etre remplie avant une operation: par exemple, un champ obligatoire renseigne, une checklist terminee ou un passage entre etapes autorise. Si la condition n'est pas remplie, l'operation est bloquee, et l'utilisateur voit un message clair et une indication de ce qu'il faut corriger.
Un controle avant operation n'est pas de la bureaucratie, mais une protection du resultat: il empeche de clore une opportunite sans raison ou de la faire passer a une etape sans les donnees necessaires. Le message du controle doit expliquer ce qu'il faut faire concretement.
Modeles d'e-mail
Les modeles d'e-mail stockent les messages externes recurrents adresses au client. Un modele actif devient disponible pour l'action « E-mail au client » dans les regles et les processus. On peut inserer dans le modele les donnees de l'opportunite et du client, si bien qu'un seul e-mail fonctionne pour de nombreuses situations.
Avant utilisation, verifiez le modele sur une opportunite de test: les donnees sont-elles correctement inserees et ne reste-t-il pas d'emplacements vides.
Processus metier
Un processus metier decrit un scenario en plusieurs etapes: etapes-actions, conditions, attentes d'un evenement, taches pour les personnes, boucles et branches paralleles. Les processus se construisent dans un editeur visuel ou les etapes sont reliees en un schema.
Avant le lancement, il convient de verifier le processus et de l'executer en mode test pour s'assurer qu'il suit le chemin attendu. Un processus lance possede un etat et un historique d'etapes; un processus bloque peut etre arrete. Les taches pour les personnes qu'un processus genere sont rassemblees dans une liste distincte et executees manuellement.
Ce qui compte pour le controle
- Chaque regle, processus et modele doit avoir un sens clair des son nom et un proprietaire.
- Avant d'activer une regle importante, verifiez le resultat attendu et testez sur des donnees sures.
- L'automatisation ne doit pas changer en cachette le responsable, l'echeance ou le statut: si une action peut susciter une interrogation, ajoutez une entree ou une notification claire.
- Reexaminez periodiquement les regles inutilisees et trop larges.
- Analysez l'historique d'execution lorsque le resultat differe de l'attente.
Comment analyser le lancement d'une regle
Lorsqu'une regle ne s'est pas comportee comme prevu, ne la desactivez pas tout de suite — lisez d'abord l'historique d'execution. Il montre ce qui s'est exactement passe et fait gagner des heures de suppositions.
Dans l'historique, pour chaque lancement, on voit:
- le statut du lancement: reussi, partiel, en erreur, ignore ou en cours;
- quelles etapes ont ete executees et a quelle etape la chaine s'est arretee;
- le resultat de la remise des notifications et des e-mails: a qui ils ont ete envoyes, a qui non et pourquoi;
- l'origine: quel evenement et sur quelle opportunite a declenche la regle.
Ordre d'analyse:
- Trouvez le lancement concerne par opportunite et par horodatage.
- Regardez si la chaine est allee jusqu'au bout ou si elle s'est arretee a une etape.
- Si une etape est en erreur, lisez-en la cause: le plus souvent des donnees manquantes, des droits insuffisants ou un destinataire indisponible.
- Corrigez la cause (donnees, droits, modele, perimetre d'action) et, si necessaire, relancez la regle manuellement.
- Si la regle se declenche trop souvent ou au mauvais endroit, resserrez la condition et le perimetre d'action plutot que de desactiver toute l'automatisation.
Un resultat partiel n'est pas forcement une panne: une partie des actions a pu volontairement ne pas s'appliquer a cause des conditions. L'important est de distinguer un saut attendu d'une veritable erreur, et l'historique d'execution suffit pour cela.
Etats que l'on peut voir
- absence de droits pour consulter ou modifier l'automatisation;
- regle desactivee;
- le resultat attendu indique que le lancement est impossible;
- un lancement manuel est en cours;
- l'historique montre une erreur ou un resultat partiel d'execution;
- un controle avant operation a bloque l'operation avec un message clair;
- processus arrete ou termine.
Une partie des ecrans d'automatisation et de processus metier n'est actuellement pas localisee pour toutes les langues de l'interface, et certains ecrans techniques affichent des informations techniques. C'est une limitation connue du produit. Elle n'affecte pas le sens de cet article, mais les captures d'ecran localisees de ces ecrans ne sont pas publiees avant correction.
Bonnes pratiques
- Donnez aux regles et aux processus des noms clairs et un proprietaire.
- Verifiez le resultat attendu et testez avant l'activation.
- Ne laissez pas l'automatisation changer en cachette le responsable, l'echeance ou le statut.
- Rendez les messages des controles avant operation clairs: quoi corriger, et non un simple « interdit ».
- Verifiez les modeles d'e-mail sur une opportunite de test avant une utilisation massive.
- Reexaminez regulierement les regles et desactivez celles qui sont superflues.
Erreurs frequentes
Activer une regle a perimetre large sans verification. Elle se declenche la ou il ne faut pas et cree des actions superflues.
Changer en cachette le responsable ou l'echeance par automatisation. L'equipe perd la comprehension de qui est responsable de quoi.
Creer un controle avant operation avec un message obscur. L'utilisateur voit une interdiction mais ne sait pas quoi corriger.
Utiliser un modele d'e-mail sans verifier l'insertion des donnees. Le client recoit un e-mail avec des emplacements vides ou les donnees d'autrui.
Lancer un processus sans execution de test. Il suit un chemin inattendu, et analyser les consequences coute plus cher que de verifier a l'avance.
Comment verifier le resultat
- le nom, le perimetre, la condition, les actions et le proprietaire de la regle sont clairs;
- l'historique d'execution confirme que la regle a fait ce qui etait attendu;
- le controle avant operation ne bloque que ce qu'il doit et explique la correction;
- le modele d'e-mail insere correctement les donnees sur une opportunite de test;
- le processus metier a passe une execution de test et suit le chemin attendu.