CRM et automatisation : suivre les prospects, les devis et les relances

• Retrouver l'origine et l'historique d'une demande
• Attribuer les relances à la bonne personne
• Mesurer les délais et les ventes, du contact au client

Le besoin apparaît souvent avant le choix d'un logiciel : plusieurs personnes rappellent le même prospect, personne ne sait si un devis a été envoyé, ou la direction recompte les ventes à la main. Nous partons de ces situations concrètes pour dessiner le circuit d'une demande, depuis son arrivée jusqu'à sa conclusion. À chaque étape, une personne doit savoir ce qu'elle a à faire et retrouver les renseignements nécessaires.

Le premier livrable est une carte du fonctionnement attendu : sources de contacts, étapes commerciales, critères de passage et actions autorisées. Une demande de dépannage ne suit pas le même chemin qu'un contrat annuel. Les mélanger dans une seule colonne « prospects » rend les indicateurs difficiles à interpréter.

Un CRM peut compléter WordPress, Shopify, un autre CMS ou une application sur mesure. Il ne remplace pas automatiquement le site public, ses pages éditoriales ou son référencement. Une migration de CMS répond à une autre décision, que nous pouvons traiter dans le même projet si elle est nécessaire.

La bonne solution dépend du nombre d'utilisateurs, des étapes de vente, des droits d'accès et des logiciels déjà payés. Nous examinons d'abord ce que votre environnement sait faire. Une automatisation native peut suffire à transmettre un formulaire ; elle sera moins adaptée à plusieurs bases aux règles contradictoires. Le choix inclut les possibilités d'export et le coût des fonctions réellement nécessaires.

Sur petit écran, faites défiler le tableau horizontalement.

HubSpot, Pipedrive, Zoho, Odoo ou une solution existante peuvent être étudiés selon leur adéquation au besoin. Cette liste décrit des possibilités techniques ; elle n'implique aucun partenariat ni certification revendiquée par Gloria. La compatibilité effective est vérifiée lors du cadrage.

Prenons une entreprise de rénovation fictive. Ses demandes proviennent du formulaire, du téléphone et de recommandations. Le commercial reçoit une adresse, un type de chantier et parfois des photos. Le problème n'est pas de collecter davantage de données : il faut retrouver le dossier, vérifier la zone d'intervention et organiser la suite sans perdre le contexte.

Le parcours proposé crée ou retrouve une fiche, conserve la provenance connue et place le dossier à l'étape « besoin à confirmer ». Une règle peut proposer un responsable selon la zone. Après validation du commercial, la demande passe à « visite à prévoir », puis « devis envoyé ». Une date de prochaine action accompagne chaque dossier ouvert. Une demande hors périmètre reçoit un statut distinct au lieu de gonfler le nombre d'opportunités.

L'automatisation prépare les tâches et transmet les informations. Le professionnel reste responsable du diagnostic, du prix et de l'engagement pris auprès du client. Avant d'activer une relance extérieure, nous validons son texte, son déclencheur, les exclusions et l'arrêt dès qu'une réponse arrive. Ce scénario sert de démonstration, sans constituer une référence client ni un résultat déjà obtenu.

« Relancer les devis » n’est pas une consigne suffisamment précise pour automatiser. Un prospect peut avoir répondu au téléphone, demandé un délai ou refusé le projet. Le scénario ci-dessous prolonge l’exemple de l’entreprise de rénovation fictive : il montre les informations à conserver et la décision laissée au commercial.

La fiche du dossier montre une personne responsable et une prochaine action

Dossier illustratif R-024 : rénovation de salle de bains, visite réalisée, devis version 2 envoyé, responsable « commercial désigné », prochaine action « vérifier la réponse avant rappel ». La date d’envoi, la dernière interaction et le délai convenu avec le prospect sont des champs distincts. Un nouveau devis remplace le précédent dans le suivi ; il ne déclenche pas une deuxième série de rappels.

Sur petit écran, faites défiler le tableau horizontalement.

Un appel non renseigné peut fausser la relance : le processus doit le prévoir

Un connecteur ne sait pas ce qui s’est dit sur un téléphone non relié au CRM. La procédure indique donc comment enregistrer un appel, une réponse reçue ailleurs ou une demande de report. Dans ce scénario, le rappel est d’abord une tâche interne avec validation humaine. Un envoi automatique éventuel nécessite un périmètre supplémentaire : texte approuvé, canal autorisé, exclusions, règles d’arrêt et contrôle de réception. Les automatismes restent désactivables.

Lors de l’essai, on envoie deux fois la même demande, on modifie le devis, on saisit une réponse avant l’échéance et on interrompt la connexion. Le compte rendu doit permettre de retrouver une seule opportunité, la bonne version et la cause d’une tâche annulée ou bloquée. L’historique conserve les actions utiles au diagnostic sans recopier inutilement les pièces confidentielles.

Si ce flux est retenu au devis, les livrables comprennent la fiche de règle, les champs à renseigner, les scénarios d’essai et la procédure de reprise. Licences CRM, connexions et maintenance sont identifiées séparément. Le bénéfice se vérifie en suivant les devis sans prochaine action et le temps passé à rechercher leur état, puis les décisions commerciales réellement obtenues.

Une migration de contacts se prépare sur un échantillon représentatif. Nous identifions les champs indispensables, les données obsolètes et les rapprochements possibles entre personne, entreprise et opportunité. Une adresse e-mail partagée ne suffit pas toujours à identifier un client ; une correspondance incertaine doit pouvoir être revue avant fusion.

Le document de correspondance explique où vont les coordonnées, les notes, les statuts, les dates et les pièces jointes. Il précise aussi ce qui ne sera pas repris. Conserver un historique complet peut demander davantage de travail qu'importer une liste de contacts : les limites d'export et les possibilités du logiciel d'arrivée sont donc vérifiées avant engagement.

Nous prévoyons une sauvegarde, un essai d'import, un contrôle des volumes et une vérification de dossiers réels autorisés ou anonymisés. Les règles de priorité sont écrites : quel système fait foi pour une adresse, un statut ou un montant ? La correction d'un champ ne doit pas être annulée au prochain échange entre logiciels.

Les premiers flux portent souvent sur l'entrée d'une demande, la création d'une tâche, le changement d'étape ou la transmission d'un dossier validé. Nous décrivons pour chacun le déclencheur, les conditions, l'action et les cas d'arrêt. Un rendez-vous annulé ne doit pas continuer à produire des rappels ; un formulaire envoyé deux fois ne doit pas créer deux opportunités identiques.

Selon le besoin, nous utilisons les fonctions du logiciel, une plateforme d'automatisation ou une connexion API spécifique. Les échanges importants disposent d'un suivi des erreurs et d'une procédure de reprise. Le responsable doit pouvoir savoir qu'un transfert a échoué au lieu de découvrir plusieurs semaines plus tard qu'une demande a disparu.

Les accès sont limités aux données nécessaires. Les environnements d'essai et de production sont séparés lorsque les outils le permettent ; les clés privées restent côté serveur. Les messages commerciaux, traitements de données et durées de conservation sont cadrés selon votre contexte. Installer un connecteur ne rend pas, à lui seul, toute l'organisation conforme.

Avant le déploiement, nous relevons une situation de départ sur une période représentative : délai avant première réponse, proportion de demandes avec responsable et prochaine action, temps de saisie, dossiers sans nouvelle et transformation des opportunités pertinentes en clients. Les définitions restent identiques après mise en service. Comparer un mois calme à un pic saisonnier sans correction donnerait une conclusion trompeuse.

Exemple de calcul illustratif : 200 dossiers mensuels demandent chacun quatre minutes de ressaisie. Réduire cette opération à une minute libérerait dix heures par mois. Ce potentiel doit être diminué du temps de contrôle, de traitement des exceptions et d'administration. Une heure libérée est une capacité disponible ; elle n'est une économie financière que si elle réduit réellement une dépense ou permet une activité utile supplémentaire.

Pour évaluer le retour sur investissement, nous rapprochons les gains observables des coûts de configuration, de formation, de licences et de maintenance sur la même période. Le tableau de bord distingue les gains constatés des hypothèses. Une hausse des ventes dépend aussi de l'offre, de la demande et du travail commercial ; elle n'est pas automatiquement attribuée au CRM.

La recette suit des situations de travail : nouvelle demande, contact déjà connu, changement de responsable, opportunité perdue, dossier rouvert et départ d'un utilisateur. Nous testons aussi un champ manquant, un doublon et une interruption de connexion. La réussite d'une démonstration ne suffit pas si personne ne sait reprendre un dossier bloqué.

Vous recevez les règles de fonctionnement, la liste des accès, les correspondances de champs et un guide des opérations courantes. Les personnes concernées vérifient les écrans avec leurs propres tâches : retrouver une information, préparer un rappel, exporter une liste autorisée, consulter leurs indicateurs. Les irritants constatés pendant cet essai sont corrigés avant généralisation.

Le lancement peut commencer avec un groupe ou un seul flux. Les critères d'acceptation, la personne qui valide et les conditions de retour à l'organisation précédente sont fixés à l'avance. Après livraison, nous précisons qui administre les utilisateurs, modifie les règles et surveille les alertes, avec une maintenance optionnelle définie au devis.

Pour chiffrer votre projet, nous avons besoin de connaître vos outils, le nombre d'utilisateurs, le volume de données et deux ou trois parcours représentatifs. La difficulté vient des règles, de la qualité de l'historique, des droits et des connexions. Le nombre d'écrans ou de contacts ne résume donc pas le travail à réaliser.

Le devis distingue l'analyse, la configuration, la reprise de données, les automatisations, les essais et la prise en main. Il identifie les abonnements éditeurs et les coûts variables éventuels : opérations d'automatisation, stockage, messages ou API. Les comptes et conditions de sortie sont convenus pour vous permettre de retrouver vos données et la documentation.

Les bases de sites à 290, 590 et 990 € HT concernent des périmètres standards ; elles ne comprennent pas un déploiement CRM sur mesure. Le domaine reste souscrit, payé et renouvelé par vos soins, avec raccordement initial possible par Gloria. Hébergement et maintenance sont définis séparément. Décrivez votre circuit commercial actuel pour cadrer un premier lot mesurable.

Faut-il changer notre CRM pour automatiser ?

Pas nécessairement. Nous vérifions d'abord ses fonctions et ses possibilités d'échange. Un outil existant peut être simplifié et relié au site. Le changement devient pertinent si les limites importantes ne peuvent pas être résolues raisonnablement.

Peut-on démarrer avec une seule automatisation ?

Oui. Transmettre les demandes du site avec un responsable et une prochaine action constitue souvent un premier lot concret. Il permet de tester les données, l'usage et la mesure avant d'étendre le périmètre.

Les relances sont-elles toutes envoyées automatiquement ?

Nous choisissons le niveau d'automatisation avec vous. Certains messages restent des brouillons ou des tâches à valider. Les envois prévus doivent avoir des règles d'arrêt, des exclusions et un responsable identifié.

À qui appartiennent les licences et les données ?

Les titulaires des comptes, les droits d'administration et les possibilités d'export sont précisés au devis. Les licences restent soumises aux conditions de leur éditeur. La remise de la documentation et des accès prévus fait partie de la livraison.