Le résultat attendu : une demande enregistrée une fois, avec les informations utiles, un état visible et une prochaine action définie. Le choix du connecteur vient après la définition de ce parcours.
Décrire ce qui doit arriver dans le suivi
Listez les champs réellement utiles à votre première conversation. Entreprise, contact, objet du projet et contexte suffisent parfois. Un budget peut être inconnu ; un site peut ne pas encore exister. Définissez les cas acceptés avant d’imposer des champs.
Pour chaque information, précisez sa destination dans le CRM, son format et son caractère obligatoire ou facultatif. Les libellés du formulaire et les données stockées doivent rester cohérents. Une valeur absente ne devient ni zéro ni une information inventée.
Choisir ce qui identifie la demande
Une entreprise peut avoir plusieurs projets. Une personne peut envoyer deux demandes différentes. À l’inverse, elle peut appuyer deux fois sur le bouton pour le même projet. Le système doit distinguer ces situations.
Dans le parcours interne NOVARIA, chaque demande possède un identifiant. Il reste le même lorsque le navigateur réessaie le même contenu après une interruption. Le serveur peut alors reconnaître la demande déjà enregistrée, sans créer une seconde fiche. Changer le contenu avec un identifiant déjà utilisé est refusé.
Confirmer après enregistrement
Le visiteur ne doit pas voir « envoyé » uniquement parce qu’il a cliqué. Le succès dépend de l’enregistrement confirmé par le point de réception. En cas de doute, le message indique que l’enregistrement n’est pas confirmé et explique comment réessayer.
Conserver le texte dans l’onglet limite la ressaisie. Cela ne constitue pas une sauvegarde hors ligne durable : fermer l’onglet peut faire perdre le brouillon. Le comportement choisi doit être visible et testé.
Préparer les erreurs avant la mise en ligne
| Test convenu | Pièce à vérifier |
|---|---|
| Une demande valide | Son contenu dans la destination attendue. |
| Un champ invalide | Une erreur compréhensible, aucune fausse confirmation. |
| Une réponse interrompue puis un nouvel essai | Une seule demande pour le même identifiant. |
| Un projet sans site | Une URL absente acceptée si le périmètre le prévoit. |
| Un service tiers indisponible | Un état d’échec visible et une procédure de reprise. |
Ces tests nécessitent des données fictives et un environnement ou un créneau autorisé. Ils ne doivent pas déclencher une campagne, un paiement ou un message destiné à un client réel.
Attribuer la prochaine action
Une fiche bien enregistrée peut rester sans suite. Décidez qui relit les demandes, où apparaissent celles qui nécessitent une réponse et comment une prochaine échéance est convenue. Une date stockée ne crée pas automatiquement une alarme.
Le connecteur n’établit pas le besoin acheteur, le décideur ou le budget. Il apporte du contexte à la personne qui qualifie et vend. L’organisation du suivi doit laisser ces confirmations distinctes des observations automatiques.
Ce qu’il faut transmettre au prestataire
- Le formulaire, le CRM et les fonctionnalités disponibles dans les forfaits actuels.
- Les champs et leurs correspondances.
- Le responsable de réception et les critères de test.
- Les accès limités au nécessaire et les contraintes de conservation.
- Les cas d’erreur, la documentation et le retour arrière attendus.