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.

remarque

L'automatisation CRM ne se limite pas aux ventes : la pipeline selectionnee peut servir des affaires commerciales ou des demandes de service. Dans les exemples surs, utilisez Delivery window — demo pour une demande de service et Rebranding — demo pour une affaire commerciale ; n'utilisez ni donnees reelles, ni identifiants, ni montants, et ne modifiez pas les donnees.

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, lancement manuel, ainsi que les evenements de l'echange de documents (voir ci-dessous).
• Si la liste des déclencheurs affiche des codes au lieu de noms lisibles, n'activez pas la règle à l'aveugle. Confirmez le sens de l'événement avec le responsable du processus et attendez un libellé clair et localisé.
• 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.
• Si une action utilise un montant ou une devise, vérifiez séparément la devise de l'opportunité et le résultat attendu. Avant l'activation, assurez-vous que la règle utilise les données monétaires et le format attendus par votre équipe.
• 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'accès au CRM ne garantit pas l'accès à l'automatisation de la pipeline ou de l'étape sélectionnée. Lorsqu'un périmètre délégué refuse l'accès, la page affiche la raison et ne charge pas la liste des règles : ce n'est pas une liste vide. Vérifiez la pipeline et l'étape choisies et demandez l'accès correspondant au responsable de la politique.

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.

Declencheurs de l'echange de documents

Flux conceptuel, pas une capture d’interface ni une preuve des données du portail.

Si l'echange de documents est raccorde dans le portail, les regles disposent des evenements propres a ce flux :

• Contrepartie liee (echange de documents) — un document entrant a ete rapproche d'un client dans le CRM ;
• Fichiers de l'echange de documents importes — les documents et les copies signees ont ete charges du cote du portail ;
• Document acheve (echange de documents) — l'echange sur le document a atteint son etat final ;
• Erreur d'import de l'echange de documents — le chargement a echoue.

Cela permet de relier l'echange de documents au travail des personnes plutot que de le surveiller a la main : a l'achevement d'un document, faites passer l'opportunite a l'etape suivante ou creez une tache d'execution ; en cas d'erreur d'import, avertissez aussitot le responsable. L'erreur d'import merite particulierement une regle : sans notification, on la remarque quand le client reclame un document jamais recu.

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 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.

Ce qui compte lors du parametrage :

• Le blocage affiche toutes les raisons a la fois. Si une operation enfreint plusieurs controles, l'utilisateur les voit en une seule liste, chacune sur sa propre ligne. Redigez les messages pour qu'ils se lisent bien les uns a cote des autres : courts, precis, sans formules vagues du type « impossible ».
• Le message doit nommer la correction, et non l'interdiction : « renseignez le motif de cloture », et non « le passage est interdit ».
• Le formulaire defile jusqu'au champ concerne et le met en evidence lorsque le controle vise un champ precis. Rattachez le controle a un champ quand c'est possible — l'utilisateur trouve ainsi tout de suite l'endroit a corriger.
• L'exception connue est le motif de cloture : la mise en evidence n'y conduit pas. Si votre controle exige un motif de cloture, indiquez dans le message ou le renseigner.

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.

Verifiez l'insertion avec un objet CRM synthetique selectionne, et non avec une fiche reelle : l'apercu a besoin de l'ID de l'entite CRM synthetique selectionnee et de son contexte d'objet. Utilisez Delivery window — demo pour une demande de service ou Rebranding — demo pour une affaire commerciale ; gardez cette verification en lecture seule.

• Le bouton « Variables » ouvre le catalogue des insertions disponibles, regroupees par sens ; la variable choisie est inseree dans le texte.
• Le bouton « Verifier » apparait des que le texte contient des variables et affiche le bloc « Apercu » : ce que deviendra le message, ainsi que les erreurs et avertissements d'insertion.

Servez-vous de l'apercu avant d'activer la regle. Il attrape precisement ce qui fait partir des e-mails bancals : une faute dans le nom d'une variable, une insertion inexistante dans ce contexte, et des vides la ou les donnees manquent.

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.

Si l'historique n'affiche qu'un identifiant de service sans nom lisible de l'opportunite ni resultat, ne considerez pas l'execution comme verifiee. Verifiez le titre, le statut et le resultat compréhensibles pour les personnes concernées.

Ordre d'analyse:

1. Trouvez le lancement concerne par opportunite et par horodatage.
2. Regardez si la chaine est allee jusqu'au bout ou si elle s'est arretee a une etape.
3. Si une etape est en erreur, lisez-en la cause: le plus souvent des donnees manquantes, des droits insuffisants ou un destinataire indisponible.
4. Corrigez la cause (donnees, droits, modele, perimetre d'action) et, si necessaire, relancez la regle manuellement.
5. 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 et enumere toutes les conditions non remplies;
• l'apercu du modele a signale une erreur ou un avertissement d'insertion;
• processus arrete ou termine.

remarque

Une partie des ecrans d'automatisation et de processus metier n'est actuellement pas localisee pour toutes les langues de l'interface. C'est une limitation connue du produit : avant une demonstration, verifiez que les noms d'actions et les messages sont clairs pour votre equipe.

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 » — et rappelez-vous qu'ils peuvent s'afficher en liste avec d'autres.
• Verifiez l'insertion dans le modele avec l'apercu avant d'activer la regle.
• 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. L'apercu dans le champ du modele montre le resultat et les erreurs en quelques secondes — sans lui, le client recoit un e-mail avec des emplacements vides ou les donnees d'autrui.

Rediger le message d'un controle avant operation comme s'il etait le seul. L'utilisateur peut voir plusieurs messages a la fois ; des formules vagues dans une liste commune ne disent pas ce qu'il faut corriger.

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;
• l'apercu du modele montre le texte fini sans erreur d'insertion ni emplacement vide;
• le processus metier a passe une execution de test et suit le chemin attendu.

Scenarios associes

Carte conceptuelle, pas une capture d’interface ni une preuve des données du portail.

• CRM: vue d'ensemble
• Pipelines et etapes
• Opportunites et demandes
• Taches
• Processus de travail
• Automatisation