Tu peux connecter un formulaire web au CRM via un formulaire natif du CRM, un connecteur compatible ou une intégration sur mesure. Le travail consiste à décider ce qui est enregistré, comment reconnaître un contact existant et qui prend en charge la demande.
Une même personne peut écrire aujourd’hui pour un service et revenir le mois suivant pour un autre. Tu dois conserver les deux demandes et garder une fiche contact cohérente. C’est la règle à définir avant d’activer la connexion.
Sépare la personne, la demande et l’opportunité
Dans le CRM, chaque donnée a une fonction :
- Contact : qui écrit et comment vous pouvez le joindre.
- Demande : ce qui a été demandé dans un envoi précis, depuis quel formulaire et à quel moment.
- Opportunité commerciale : le dossier que vous allez évaluer et suivre, si cette demande entre dans le processus de vente.
Les noms et les types d’enregistrements changent selon le logiciel. La demande peut être enregistrée comme une activité, un prospect, une requête ou un enregistrement dédié. L’essentiel est de pouvoir retrouver son contenu sans remplacer l’ancien.
Il n’est pas non plus nécessaire de transformer chaque message en opportunité. Une demande de support d’un client actuel peut nécessiter une tâche pour le service client ; une demande de devis, une revue commerciale. Définis cette destination pour chaque formulaire.
Décide quels champs vont où
Avant de choisir le connecteur, prépare un tableau simple avec la personne qui traite les demandes. Voici un point de départ :
| Donnée du site | Destination et règle |
|---|---|
| Nom, email et téléphone | Fiche du contact, avec une règle pour reconnaître les enregistrements existants. |
| Service demandé et message | Demande précise, en conservant le texte original. |
| Date et identifiant de l’envoi | Enregistrement de la demande pour reconnaître les réessais. |
| Formulaire et page d’origine | Contexte de cette demande : contact général, service ou campagne. |
| Campagne, si elle est collectée | Champ séparé de la source initiale du contact. |
| Préférences exprimées dans le formulaire | Champs spécifiques, en respectant la valeur choisie par la personne. |
Décide aussi quelles données le formulaire peut mettre à jour. Un champ vide ne devrait pas effacer un téléphone déjà vérifié par l’équipe. Une nouvelle demande ne devrait pas non plus changer par défaut le commercial qui suit une relation en cours.
Le site et le CRM doivent partager les mêmes valeurs pour les listes déroulantes. Si « Maintenance » est renommé sur le site, vérifie la règle qui attribue ces demandes. Les changements de design peuvent aussi avoir un impact sur la connexion.
Choisis la connexion selon ton formulaire et ton CRM
Formulaire natif du CRM. C’est une bonne option si tu peux l’intégrer au site et qu’il correspond au design et aux champs dont tu as besoin. Par exemple, les formulaires web de Pipedrive permettent d’insérer un formulaire et de recevoir les données sous forme de prospects ou de deals. La fonction fait partie de LeadBooster : il faut vérifier sa disponibilité dans le compte.
Connecteur entre les outils actuels. Cela peut convenir si tu veux garder le formulaire et qu’une intégration compatible existe. Vérifie les actions qu’elle permet : rechercher un contact, le mettre à jour, enregistrer une demande et attribuer une tâche. Le fait de voir le logo de ton CRM dans un catalogue ne confirme pas que toutes ces étapes sont couvertes.
Intégration sur mesure. Elle convient quand il y a des règles propres, plusieurs systèmes ou un formulaire personnalisé. Elle demande de vérifier les interfaces de connexion disponibles, les permissions et la maintenance. La proposition doit expliquer ce qui se passe si l’un des systèmes cesse de répondre.
Dans les trois cas, le résultat se valide depuis le CRM : bon contact, demande complète et une personne responsable de son suivi.
Un exemple : trois envois, deux demandes et un contact
Ana demande des informations sur un service. La connexion met du temps à répondre et le même envoi est traité à nouveau. Quelques jours plus tard, Ana revient pour poser une question sur un autre service. C’est un exemple illustratif pour concevoir l’intégration.
Le résultat attendu serait :
| Ce qui arrive | Comment cela devrait être traité |
|---|---|
| Première demande d’Ana | Reconnaître ou créer son contact, enregistrer la demande et assigner la prochaine étape. |
| Réessai technique du même envoi | Récupérer le résultat précédent, sans créer une autre demande ni une autre tâche. |
| Nouvelle demande d’Ana sur un autre service | Conserver le contact et enregistrer une nouvelle demande avec son propre contexte. |
| Correspondance douteuse avec une autre fiche | Laisser l’association en attente pour vérification. |
Pour distinguer les deux premiers cas, chaque envoi a besoin d’une référence qui se maintient pendant les réessais. Si une autre référence est générée à chaque tentative de connexion, elle ne sert plus à reconnaître l’opération d’origine.
L’identification du contact dépend du CRM. HubSpot documente la déduplication par email : lorsqu’un formulaire arrive avec l’email d’un contact existant, l’information est ajoutée à cette fiche. Cette règle ne remplace pas la décision sur ce qu’il faut faire de chaque demande.
Vérifie les exceptions : adresses partagées par plusieurs personnes, changements d’email ou formulaires qui demandent seulement un téléphone. HubSpot explique aussi que ses formulaires sans email peuvent associer les envois via des cookies ; sur un appareil partagé, cela peut relier des envois de personnes différentes. Il faut tester la configuration réelle du compte.
Désigne un responsable et récupère les erreurs
Une demande enregistrée a besoin d’une prochaine étape : vérifier les besoins, appeler ou préparer une réponse. Convenez de qui la reçoit, du délai interne et de qui couvre une absence.
Pour les incidents, demande une vue qui permette de répondre à trois questions : ce qui est entré, ce qui a été enregistré et ce qu’il reste à faire. Si le contact a été créé mais que la tâche a échoué, le réessai doit reprendre cette étape en attente.
Le message affiché sur le site doit lui aussi être précis. Tu peux afficher « Nous avons bien reçu votre demande » lorsqu’elle est conservée de manière sécurisée pour être traitée, même si le CRM est temporairement en attente. Si rien n’a été enregistré, le visiteur a besoin d’un message d’erreur et d’une alternative pour contacter l’équipe.
Où l’IA peut aider
L’IA peut servir à résumer de longs messages ou à proposer une classification quand la demande arrive en texte libre. Conserve l’original avec le résumé et laisse les doutes dans une file de relecture.
Pour copier un email, reporter une option sélectionnée ou attribuer un formulaire à une équipe, des règles définies suffisent. Le premier pilote doit vérifier que toutes les informations sont conservées et qu’elles arrivent à la bonne personne.
Si tu ajoutes une classification par IA, teste des demandes qui mentionnent plusieurs services et des messages ambigus. Une catégorie proposée peut aider l’équipe ; fusionner des fiches ou écarter des demandes exige des contrôles spécifiques.
Que demander lors du test final
Fais le test avec un nouveau contact, un contact existant, un envoi répété et une interruption du CRM. Vérifie aussi une demande avec des champs optionnels vides et une autre qui doit aller au service client.
Dans chaque cas, ouvre le résultat et vérifie : message complet, contact associé, source, responsable et tâche en attente. Ensuite, mesure combien de temps il faut pour traiter les demandes et combien nécessitent une correction. Tu pourras ainsi évaluer le fonctionnement avec tes propres données.
Si tu hésites sur le point de départ, notre guide sur comment choisir le premier processus à automatiser t’aide à organiser les priorités.
Chez Digency, nous connectons les sites et les outils grâce à des automatisations sur mesure. Dis-nous quel formulaire et quel CRM tu utilises, et nous définissons ce qui doit se passer depuis l’arrivée d’une demande jusqu’au traitement par l’équipe.
Couverture : illustration générée par IA.
