Demandes web et demandes de visite
Un prospect remplit un formulaire à 23 heures. Si le parcours configuré aboutit, l’équipe peut retrouver une Demande avec ses coordonnées, le bien concerné et les informations de campagne disponibles. Une visite peut aussi être créée dans le calendrier lorsque les conditions de planification sont satisfaites. Ce guide aide les agents de location et les équipes marketing à lire ces données de provenance, à distinguer une préférence de visite d’un rendez-vous créé et à vérifier l’attribution utilisée dans leurs rapports.
Droits nécessaires. L’ensemble REDA - Property Leasing User, ou des autorisations adaptées à votre fonction, couvre le travail concerné. Vérifiez les droits effectifs sur la demande, les champs de l’extension web et les événements associés.
Origine des demandes web
Les pages publiques de recherche et de détail des biens peuvent être intégrées au site marketing. Le parcours décrit propose un formulaire de contact et un formulaire de demande de visite. Une soumission valide peut créer une demande liée au bien ; vérifiez le résultat et les erreurs éventuelles. Pour préparer les pages et leurs fonctions, consultez Publier les biens sur votre site web.
Données enregistrées sur la demande
Les formulaires peuvent renseigner les données suivantes. Les mentions de disponibilité distinguent les valeurs affectées par le parcours des informations qui dépendent des champs saisis, paramètres présents et règles de l’organisation :
| Information ou action du visiteur | Destination | Disponibilité |
|---|---|---|
| Nom, e-mail, téléphone et message saisis. | Prénom, nom, e-mail, téléphone et description. | Selon les valeurs réellement fournies et validées ; tous les champs ne sont pas nécessairement remplis. |
| Formulaire depuis la page d’une unité. | Bien lié à l’unité de la page. | Dans le parcours de page d’unité décrit, si la création aboutit. |
| Valeur affectée par le parcours. | Source de la demande = Web. | Dans ce parcours de création. |
| Parcours de location ou d’achat. | Type d’enregistrement Location ou Vente de bien dans Platform, selon le parcours. | Selon l’action et les types disponibles ; vérifier l’édition installée. |
| En-têtes de la requête web. | Adresse IP web. | Si un en-tête exploitable est présent ; ce n’est pas une preuve d’identité. |
| Page associée à une promotion. | Référence de promotion web de location. | Lorsqu’une promotion est disponible dans la configuration de la page. |
| Demande de visite. | Date demandée, préférence horaire et type de visite. | Selon le formulaire et les valeurs fournies. |
| Lien de campagne avec paramètres. | Les six champs UTM. | Si les paramètres parviennent à la page et à la soumission. |
| Clic publicitaire identifié. | Identifiants de clic Facebook, Google, Microsoft et TikTok. | Si les paramètres correspondants sont reçus. |
| Contexte web. | Identifiant du formulaire, page de destination, URL de provenance et identifiant de session. | Selon les informations collectées et transmises. |
| Planification d’une visite locative avec créneau. | Événement de visite lié à la demande. | Dans le parcours de location avec début et fin transmis et création réussie ; une préférence seule ne suffit pas. |
Le type d’enregistrement oriente le traitement ultérieur. Dans le parcours Platform de référence, l’action de location produit une demande de type Location et l’action d’achat utilise Vente de bien. Vérifiez le type réellement créé avant de qualifier ou convertir la demande.
Création de la visite dans le calendrier
Le parcours peut créer un événement de visite lié à la demande. Dans la référence examinée, cette création exige le parcours de location, le formulaire de planification et des heures de début et de fin. La date souhaitée ou la préférence « matin » ne constitue donc pas à elle seule un rendez-vous confirmé. Les informations de demande de visite sont :
| Champ d’extension de référence | Information recueillie |
|---|---|
| Requested Showing / Tour Date — Date de visite demandée | Date à laquelle le prospect souhaite voir le bien. |
| Requested Showing Tour Preference — Préférence horaire de visite | Préférence de période : Morning (matin), Around Noon (vers midi) ou Afternoon (après-midi), selon les options du formulaire. |
| Requested Showing Type — Type de visite demandé | In-Person (sur place) ou Live Virtual Tour (visite virtuelle en direct), selon les options proposées. |
Un prospect peut ainsi demander une visite virtuelle l’après-midi du 15. L’agent dispose de la date, de la préférence horaire et du mode de visite ; il doit encore vérifier l’événement créé, son créneau et son affectation avant de considérer le rendez-vous comme planifié.
Attribution marketing
Les paramètres conservés sur la demande aident à analyser l’origine des prospects. Ils décrivent ce que la page a reçu ; ils ne prouvent pas à eux seuls une attribution publicitaire complète ou validée par le réseau. Deux groupes d’informations sont utiles :
| Donnée | Interprétation |
|---|---|
| Paramètres UTM : campaign, content, id, medium, source, term | Balises du lien de campagne : campagne, canal, contenu et autres dimensions transmis à la page. |
| Identifiants de clic publicitaire : fbclid, gclid, msclkid, ttclid | Identifiants fournis par les liens des réseaux Facebook, Google, Microsoft et TikTok, lorsqu’ils sont présents et conservés jusqu’à la soumission. |
Une arrivée directe peut ne porter aucun paramètre. À l’inverse, une redirection, un réglage de confidentialité ou une intégration qui ne conserve pas les paramètres peut expliquer une valeur absente après un clic de campagne. Vérifiez le parcours complet avant de conclure à une erreur ou à une origine directe.
Traiter une demande web
Une fois créée, la demande suit le traitement métier habituel. La source Web, le type d’enregistrement et les informations de provenance servent à l’orienter :
- Filtrez les listes ou rapports sur Web pour étudier ces demandes, en vérifiant que les autres parcours utilisent la même convention de source.
- Si un prospect a soumis plusieurs formulaires, examinez les candidats proposés dans Doublons potentiels. Sélectionnez les fiches concernées avant Fusionner les doublons, puis vérifiez les valeurs à conserver. La détection dépend des règles et des accès ; consultez Rechercher et fusionner les demandes en double.
- Lorsque le prospect est prêt, utilisez la conversion adaptée au parcours de location ou de vente. Pour une location, une candidature locative en ligne peut précéder la conversion et doit être vérifiée avant celle-ci.
Deux parcours de réception web
Un formulaire externe, par exemple Webflow ou une autre page de campagne, peut transmettre des paramètres d’attribution via le Data Service. Il faut préparer son adaptateur et ses correspondances. La page d’annonce de référence écrit directement la demande, tandis que Data Service accepte une requête puis traite l’écriture en arrière-plan. Leurs champs et automatisations ne sont pas tous interchangeables : Data Service ne crée pas à lui seul la visite décrite ici.
Exemple : Aisha découvre Meridian Court #101
Aisha clique sur une annonce Google de Meridian Court #101. La page reçoit utm_source=google, utm_campaign=summer-lease et un identifiant de clic Google. Elle demande une visite le samedi matin. Si les paramètres et le créneau sont transmis et que le traitement aboutit, l’équipe vérifie :
| Élément | Valeur attendue dans l’exemple |
|---|---|
| Nom | Aisha Rahman |
| Source et type d’enregistrement | Web / Location dans Platform. |
| Bien | Meridian Court #101 |
| Demande de visite | Samedi, préférence le matin. |
| Attribution | Campagne summer-lease et identifiant Google ; adresse IP si un en-tête exploitable a été reçu. |
| Calendrier | Visite liée pour samedi si le parcours locatif a transmis début et fin et si l’événement a été créé. |
Le rapport de campagne peut classer Aisha sous summer-lease. Avant l’ouverture du bureau, l’agent vérifie la demande et la visite réellement présente dans le calendrier ; il ne déduit pas la création de l’événement de la seule préférence saisie.
Pour aller plus loin
- Publier les biens sur votre site web (RDELS) — préparer les pages et formulaires.
- REDA Data Service : connecter vos formulaires — configurer l’autre parcours de réception.
- Candidatures locatives en ligne (RLA) — préparer le dossier avant conversion en bail.
- Rechercher et fusionner les demandes en double — traiter les soumissions multiples.
Questions fréquentes
Les champs UTM et identifiants de clic dépendent des paramètres reçus et conservés. Une arrivée directe peut ne rien fournir ; une redirection ou un réglage de confidentialité peut aussi retirer ces valeurs. Vérifiez le lien, la page et la transmission avant de conclure.
Le parcours de page peut proposer ces actions. Dans la référence Platform, l’action de location utilise le type Location et l’achat Vente de bien. Vérifiez les actions publiées et le type réellement créé dans votre édition.
Examinez Doublons potentiels, sélectionnez les bons candidats, puis utilisez Fusionner les doublons avec contrôle de la fiche conservée. Pour un formulaire externe, le Data Service peut effectuer une mise à jour si recordId est associé à Id, si l’opération est autorisée et si l’intégration a validé le droit de modifier cette fiche. Il ne déduit pas automatiquement le bon identifiant d’un e-mail.
Elle provient des en-têtes de la requête traitée. Elle peut refléter un intermédiaire réseau et peut être absente ; elle n’authentifie pas la personne et ne prouve pas à elle seule son emplacement ou l’origine réelle de la campagne.
Cet article vous a-t-il été utile ?