Formulaires
Les formulaires LadVen OS recoivent des demandes depuis un site, une landing page, la documentation ou une page externe et les transforment en travail CRM suivi. Ils servent aux demandes de demo, demandes client, consultations, support et autres flux entrants.
Un formulaire doit collecter seulement les donnees utiles pour l'etape suivante : qui contacte, comment repondre, quel est le besoin et ou envoyer la demande.
Quand utiliser les formulaires
Utilisez les formulaires pour collecter des demandes du site, les router vers le bon pipeline CRM, standardiser les champs entrants, verifier les demandes, separer le spam du travail reel et savoir quelle version publiee est active.
Si la demande arrive par e-mail ou chat, ne la copiez pas manuellement sans raison. Liez le message ou la conversation au CRM lorsque cela conserve mieux le contexte.
Choisir le scenario et le responsable
Avant de construire le formulaire, decidez qui possede le scenario : marketing, ventes, support ou operations. Cette personne valide les champs, le consentement, le routage CRM, le premier responsable et la regle de cloture des demandes faibles.
Pour chaque formulaire, fixez l'objectif, la page de placement, la langue principale, les autres langues, les champs obligatoires, le pipeline CRM, l'etape de depart, le controle quotidien et la condition d'archivage.
Scenario de demande de demo
Une demande de demo doit mener vite vers le test du produit. En general, nom, contact professionnel, societe, role, langue preferee et courte description suffisent. Ne demandez pas budgets internes, mots de passe, tokens ou donnees personnelles inutiles au premier pas.
Apres un envoi de test, verifiez qu'il arrive au bon responsable, que le texte est clair, que la langue ne se melange pas et que la source indique la page d'origine.
Demande client ou support
Pour consultation, support ou demande client, ajoutez les champs qui aident a qualifier : sujet, domaine produit, horaire de contact, piece jointe seulement si necessaire et commentaire. Si la demande doit aller au support ou a l'account management plutot qu'aux ventes, utilisez une route et un responsable separes.
Ne melangez pas plusieurs processus dans un formulaire. Demo, demande partenaire et support meritent habituellement des formulaires differents.
Creer le formulaire
Dans le constructeur, renseignez nom, code, langue principale, titre, description, bouton d'envoi et champs. Le nom interne doit parler a l'equipe; titre et description doivent parler a la personne externe.
Les champs doivent etre courts et clairs : nom, contact, societe, question, horaire de contact et commentaire. Si plusieurs langues sont disponibles, verifiez textes et libelles dans chaque langue avant publication.
Champs obligatoires et qualite des donnees
N'ajoutez pas de champs obligatoires inutiles. Plus le formulaire est long, moins il sera envoye. Rendez obligatoire seulement ce qui est necessaire pour repondre ou qualifier.
Un bon formulaire evite les questions doubles, utilise des libelles clairs, evite les abreviations internes, ne demande pas au client de choisir une etape CRM interne et collecte consentement et contact simplement.
Publier et placer
Enregistrer ne modifie pas toujours le site public. Avant publication, controlez apercu, champs obligatoires, langues, apparence, anti-spam, domaines autorises et routage CRM.
Apres publication, placez le formulaire uniquement sur les pages qui doivent recevoir des demandes reelles. Si le formulaire est retire ou archive, verifiez que le site n'a plus de point d'entree actif.
Ne montrez pas de cles actives, contacts reels ou liens prives dans les supports de formation et pendant les demonstrations. Pour une presentation aux collegues, creez un formulaire de test separe avec des donnees sures.
Routage CRM
Choisissez le pipeline, l'etape de depart et les regles pour les nouvelles demandes. Sans route specifique, le formulaire peut suivre les regles generales de la plateforme.
Un bon routage indique qui voit la demande en premier, ou elle apparait, quels champs la qualifient, qui traite les erreurs CRM et quand elle est acceptee.
Demandes et statuts
Controlez les demandes regulierement. Une demande doit etre acceptee, marquee comme spam ou renvoyee apres correction des erreurs CRM. Si elle semble suspecte, ne la mettez pas au travail avant de verifier contact et contenu.
Pour les erreurs CRM, verifiez champs obligatoires, route, droits et donnees client avant de reessayer. Si l'erreur se repete, envoyez au responsable le formulaire, la demande exacte et le comportement attendu.
Localisation et consentement
Si le formulaire existe en plusieurs langues, verifiez titre, bouton, libelles, erreurs, consentement et notification au responsable. La personne doit voir une seule langue pendant tout l'envoi.
Le consentement doit expliquer pourquoi les donnees sont collectees et qui les traite. Ne reutilisez pas un texte legal d'un autre pays ou processus sans verification.
Securite
Ne collectez pas mots de passe, tokens, pieces d'identite, donnees de paiement ou autres informations sensibles inutiles via des formulaires publics. Pour un formulaire client, convenez à l'avance du texte du consentement et de la finalité de la collecte. Controlez domaines autorises et formulaires actifs aussi regulierement que les liens publics de fichiers.
Checklist manager
- Le formulaire a un responsable et un scenario clair.
- Les champs correspondent a la prochaine etape metier.
- Les champs obligatoires sont minimaux.
- Langues, consentement et bouton sont verifies.
- Une demande de test est arrivee dans le bon pipeline CRM.
- Le responsable sait accepter, marquer spam et relancer l'envoi.
- Le site ne contient pas d'ancienne version ou de version archivee.
Erreurs courantes
- Un formulaire sert a toutes les demandes entrantes.
- Le formulaire demande des details que l'equipe peut clarifier plus tard.
- La page de placement n'est pas verifiee apres modification.
- Les demandes sont copiees a la main et perdent leur source.
- Le spam entre dans le pipeline de travail.
- Pour les démonstrations, utilisez des contacts synthétiques et un formulaire de test séparé avec un exemple d’intégration non productif ou masqué ; n’utilisez jamais de vrais contacts ni de code d’intégration actif.
Scenarios pour l'entreprise
- Boite de reception omnicanale
- Pipeline commercial avec taches et documents
- Historique client unifie : CRM, taches, documents, chat
- Tous les scenarios
Sections liees