E-mails de visite immobilière vers une seule feuille,
reports compris
Une confirmation de visite est le seul message du fil qui indique à l'agent de visite comment entrer dans le bien, et ces détails se trouvent dans le corps du message plutôt que dans une pièce jointe. La documentation d'aide de ShowingTime décrit la confirmation comme contenant le type et l'emplacement de la keybox, les instructions de visite et les détails d'accès (ShowingTime). Le guide de la boîte à clés pour BrokerBay envoie les agents au même endroit : ouvrez l'e-mail de confirmation de visite pour trouver le code, qui n'est valable que pour le rendez-vous confirmé. Lu comme un avis de calendrier, le message ressemble à une heure et une adresse. Lu comme un enregistrement d'accès, c'est le document dont dépend le rendez-vous.
Le volume n'est pas un cas isolé. ShowingTime gère près de quatre millions de visites chaque mois sur 1,2 million d'annonces actives (ShowingTime support), et chacune laisse une confirmation quelque part dans une boîte de réception. Les équipes qui tiennent une feuille de visites cherchent à transformer ce flux en un registre qu'elles peuvent trier, exploiter pour leurs rapports et transmettre à un CRM. Le plus difficile n'est pas de lire une adresse. C'est de garder le registre exact après le déplacement d'une visite.
Points clés
- Une seule visite peut générer cinq e-mails, et un seul d'entre eux prouve que vous pouvez entrer dans le bien.
- Un report arrive comme une nouvelle demande, donc l'ancienne ligne conserve une heure qui n'existe plus et semble toujours à jour.
- Quinze minutes de travail sur tableur séparent le journal de la vue courante, et c'est l'étape que la plupart des équipes sautent.
Une confirmation de visite contient les détails d'accès, pas seulement l'heure
Les champs dont une équipe a besoin figurent déjà dans le corps de l'e-mail, générés à partir de la fiche du bien au moment où le rendez-vous est confirmé. Ce qui change d'une plateforme à l'autre, c'est moins l'ensemble des champs que leur libellé, leur ordre, et la présence ou non d'un champ donné dans ce message précis.
| Ce que contient l'e-mail | Où cela se trouve | Ce qui change d'une plateforme à l'autre |
|---|---|---|
| Adresse du bien et numéro MLS | En haut du corps, au-dessus des détails du rendez-vous | Les deux sont presque toujours présents ; le libellé et l'ordre changent, et certains modèles répartissent l'adresse sur deux lignes |
| Date et créneau horaire de la visite | Corps, généralement le bloc le plus en gras | Certains affichent une heure de début et de fin, d'autres une heure de début plus une durée, si bien qu'une heure de fin doit être déduite ou laissée vide |
| Agent de visite et numéro de mobile | Corps, près du bloc rendez-vous | La personne présente peut être un agent de couverture ou de visite plutôt que l'agent acheteur qui a demandé le rendez-vous |
| Agent vendeur et co-agent | Corps, souvent dans une section contact | Le co-agent peut être totalement absent lorsque la fiche a été extraite avant l'ajout de la co-mandat |
| Instructions de visite | Paragraphe du corps, parfois intitulé « Additional Instructions » | Texte libre, et il peut être absent lorsque la fiche a changé après l'extraction MLS unique de la plateforme |
| Type et emplacement de la boîte à clés | Corps, près de la section accès | Supra, SentriLock, Master Lock ou une boîte à combinaison ; la note d'emplacement est rédigée par le côté vendeur et varie énormément |
| Code d'accès ou code journalier | Corps, ou un lien vers l'application de boîte à clés | BrokerBay place le code dans la confirmation ; l'accès SentriLock passe par SentriKey, si bien que l'e-mail peut contenir le rendez-vous et les instructions tandis que le déverrouillage se fait dans l'application |
| Statut : confirmé, reporté, annulé | Objet et corps | L'expéditeur et la mise en page restent presque identiques pour les trois, c'est pourquoi le statut est le champ le plus souvent perdu |
ShowingTime inclut le texte des instructions dans l'e-mail de confirmation, mais ce texte ne peut pas être ajusté au moment où l'agent confirme la demande ; une correction doit être envoyée dans un message séparé, qui apparaît différemment dans la boîte de réception de l'agent de visite (instructions ShowingTime). Chaque message est un instantané, et la correction est un second instantané qui ne ressemble pas au premier.
La confirmation est le registre d'accès pour un rendez-vous. Traitez-la comme un simple avis de calendrier et l'emplacement de la boîte à clés, les instructions et le code restent enfouis dans la boîte de réception.
Une visite génère plusieurs e-mails, et un seul est la confirmation
Un seul rendez-vous peut générer cinq messages avant que quiconque mette les pieds dans la propriété : la demande, la confirmation, un rappel, un report ou une annulation si quelque chose change, et une demande de retour d'information par la suite. Ils proviennent de la même plateforme, avec des objets similaires, et sur ShowingTime, la confirmation peut afficher le nom de l'agent vendeur comme expéditeur plutôt que celui de la plateforme.
Ce volume est familier à quiconque a organisé une tournée du samedi. Un agent acheteur a décrit l'expérience sur r/realtors comme un « BARRAGE d'e-mails vous informant que l'agent a reçu la demande, a vu la demande, a réfléchi à la demande, a mangé un sandwich près de la demande. » Chacun de ces messages est une ligne candidate si le pipeline est construit sur « nouvel e-mail entrant, nouvelle ligne sortante ».
Le rapport 2025 de la NAR sur les tendances générationnelles remet les choses en perspective côté acheteur : les acheteurs ont cherché pendant une médiane de 10 semaines et ont visité une médiane de sept biens (NAR, 2025). Sept biens signifient au moins sept rendez-vous, répartis sur tous les côtés vendeurs et plateformes que ces biens utilisent. La feuille d'un seul bien reçoit donc des messages de nombreux agents différents, avec des habitudes de nommage et des modèles de plateforme différents.
Un e-mail de prospect est une demande de renseignements qui doit devenir une fiche contact. Une confirmation de visite est un rendez-vous qui existe déjà, et la feuille cherche à le refléter, c'est pourquoi le flux de travail des e-mails de prospects immobiliers résout un problème différent. Le rôle de la confirmation est de prouver l'accès pour une fenêtre précise, et un seul des cinq messages le fait.
Si chaque e-mail devient une ligne, la feuille se remplit de demandes ensuite refusées, de confirmations ensuite déplacées et de demandes de retour d'information qui ne comportent aucun détail d'accès. La confirmation est la ligne à conserver. L'annulation est la ligne qui change la vérité. Une colonne Statut est ce qui vous permet de garder les deux sans prétendre qu'il s'agit du même événement.
Là où la feuille et le système de visites cessent de concorder
La feuille et le système de visites divergent rarement parce qu'un champ a été mal lu. Ils divergent à cause de la façon dont les plateformes émettent et révisent les confirmations, et chacune de ces structures produit un type précis de ligne obsolète.
Un report arrive comme une nouvelle demande, donc l'ancienne ligne ne change jamais
Dans ShowingTime, reporter un rendez-vous envoie une nouvelle demande de rendez-vous avec les informations de report à l'agent vendeur pour confirmation (report ShowingTime). La ligne d'origine n'est modifiée par personne. Elle reste dans la feuille avec une heure qui n'existe plus, et elle y reste parce qu'elle semble terminée.
Une ligne obsolète n'a pas l'air obsolète. Elle a une adresse, une heure et un agent, exactement ce qu'a une ligne correcte.
La mise à jour entre en concurrence avec tout le reste un samedi, et une ligne qui semble terminée n'annonce jamais qu'elle est périmée. Aucun message d'erreur n'apparaît pour dire que l'ancienne heure n'a jamais été remplacée.
Le co-agent et les instructions sont extraits une seule fois du MLS, puis cessent d'être mis à jour
ShowingTime effectue une extraction initiale et unique des données de l'annonce, y compris l'agent co-vendeur et les instructions de visite. Les modifications apportées ensuite dans le MLS ne sont pas reprises automatiquement (agent co-vendeur ; instructions). Une annonce qui ajoute un co-agent après sa mise en ligne peut continuer d'envoyer des confirmations avec un champ co-agent vide, et une annonce dont les instructions changent peut continuer d'envoyer les anciennes, voire aucune.
Aucun paramètre d'extraction ne récupère un champ que l'e-mail n'a jamais contenu. Un co-agent vide dans la feuille est un signal concernant la fiche de l'annonce, pas un signal concernant la lecture. La réponse utile consiste à signaler le champ vide et à le corriger dans la plateforme de visite, plutôt qu'à relancer l'extraction en espérant un résultat différent.
Le code d'accès expire avec le rendez-vous pour lequel il a été émis
Le guide de la boîte à clés BrokerBay de Master Lock précise explicitement que le code figurant dans la confirmation n'est valide que pour le rendez-vous confirmé (guide Master Lock Vault, 2022). Cela transforme une ligne en double en échec concret : l'agent de visite ouvre la feuille, lit le code de la ligne précédente, se rend au bien, et la boîte refuse de s'ouvrir.
Une ligne en double coûte une minute de nettoyage. Un code obsolète coûte un trajet, une visite tardive et un acheteur qui attend sur le perron. C'est la raison pour laquelle la feuille a besoin d'une vue courante, et pas seulement d'un journal.
Qui intervient sur une visite, et quels champs chaque rôle détient
Six personnes peuvent intervenir sur un même rendez-vous, et chacune détient une partie différente de l'enregistrement. Concevoir la feuille comme si un seul « vous » gérait tout est la meilleure façon de rater les transmissions.
| Rôle | Ce qu'il fait | Ce qu'il détient dans la feuille |
|---|---|---|
| Agent acheteur | Demande la visite et entretient la relation client ; peut envoyer un agent de remplacement | Le contact côté acheteur, et souvent le nom de la personne qui se présente réellement |
| Agent de visite | Rencontre l'acheteur, déverrouille le bien, le sécurise en partant, fait un retour | Les notes d'accès et le résultat de la visite, si l'équipe les consigne |
| Agent vendeur | Définit les instructions de visite, le mode d'accès et les restrictions sur l'annonce | L'adresse, le numéro MLS, les instructions, le type de keybox et le contact côté vendeur |
| Coordinateur ou assistant vendeur | Confirme les demandes, relance les retours, prépare le rapport hebdomadaire d'activité du vendeur | Le journal lui-même : statut, reports et le caractère actuel ou non d'une ligne |
| Vendeur | Peut confirmer les rendez-vous et recevoir les notifications de visite dans l'application de la plateforme | Rien dans la feuille, mais c'est le destinataire du rapport qui en est tiré |
| Coordinateur de transaction | Prend le relais dès que l'annonce passe sous contrat et constitue le dossier de transaction | Consulte l'activité de visite pour le contexte ; ne tient pas le journal |
Une fois la propriété des champs établie, l'ensemble des colonnes en découle. Le coordinateur vendeur détient le statut et les reports. L'agent vendeur détient les instructions et l'accès, ce qui signifie qu'un champ vide à cet endroit se corrige en amont. L'agent de visite détient les notes de terrain qui n'apparaissent jamais dans la confirmation.
L'ensemble de colonnes qui tient pour ShowingTime, SentriLock et BrokerBay
L'ensemble de colonnes doit décrire un rendez-vous, pas un e-mail. Saisissez ces noms une fois, et le même ensemble lit les trois plateformes car les valeurs sont trouvées par le sens plutôt que par la position dans un modèle fixe.
| Colonne | Pourquoi elle mérite sa place |
|---|---|
| Plateforme | ShowingTime, SentriLock ou BrokerBay ; le premier filtre quand une question de format se pose |
| Numéro de rendez-vous ou de confirmation | La clé la plus propre pour associer un report à son original, quand l'e-mail en affiche un |
| Adresse du bien | Le champ par lequel commence chaque rapport et chaque conversation avec un agent |
| Numéro MLS | Relie la visite à la fiche du bien sans dépendre d'une correspondance d'adresse |
| Date de visite | Séparée de l'heure pour que la feuille trie correctement |
| Heure de début | La valeur dont un agent de visite a réellement besoin à la porte |
| Heure de fin | Souvent dérivable d'une durée ; mérite une colonne car le rendez-vous suivant en dépend |
| Statut | Confirmé, reporté ou annulé ; la colonne qui empêche un journal de prétendre que chaque message est à jour |
| Agent de visite | La personne qui a besoin de l'accès, qui n'est pas forcément l'agent ayant demandé le rendez-vous |
| Mobile de l'agent de visite | Le numéro que le côté vendeur appelle quand la boîte ne s'ouvre pas |
| Agent vendeur | Le détenteur des instructions et la personne à appeler quand elles sont erronées |
| Co-agent | Souvent vide à cause de l'extraction MLS ponctuelle ; un vide ici est une tâche à faire, pas une erreur de données |
| Type et emplacement de la boîte à clés | Supra, SentriLock, Master Lock ou combinaison ; le détail physique qui fait entrer quelqu'un |
| Notes d'accès | Alarme, portail, animaux, emplacement de la boîte à clés ; le champ libre qui évite un second déplacement |
| Instructions de visite | Les conditions du côté vendeur, conservées mot pour mot car reformuler perd la contrainte |
| Prix affiché au moment de la visite | Un instantané, utile dans un rapport vendeur ; pas un champ de prix actuel, donc à libeller à la date de visite |
Décidez délibérément si le code de la boîte à clés doit figurer dans la feuille. Une feuille partagée avec une équipe, un assistant virtuel ou une synchronisation CRM a une diffusion bien plus large qu'un e-mail de confirmation. Si l'équipe a seulement besoin de savoir où se trouve la boîte et que le code est dans la confirmation, une colonne notes d'accès avec « code dans l'e-mail de confirmation » suffit. Si le code doit être stocké, restreignez l'accès à la feuille et supprimez les anciennes lignes une fois le rendez-vous passé. Lorsque la plateforme émet un code journalier, celui-ci expire avec le rendez-vous, donc le reporter n'a aucune valeur opérationnelle. Un code de combinaison statique est un problème différent, et le stocker dans une feuille partagée mérite un examen plus approfondi.
Comment les e-mails atteignent la feuille sans transférer chaque message
Ce que l'on appelle la configuration ShowingTime vers Google Sheets est en réalité une route e-mail : la plateforme envoie une confirmation, une boîte de réception la lit, et la feuille reçoit la ligne. Le lien, c'est la boîte de réception, car aucune des trois plateformes n'écrit les visites dans votre tableur. Une adresse e-mail dédiée plus une règle de transfert remplacent le transfert manuel, et l'extraction lit le corps du message où se trouvent déjà les détails d'accès.
L'Email Inbox d'ImageToTable.ai donne à chaque compte sa propre adresse. Les messages qui y sont envoyés arrivent dans une file de traitement sans que personne ne se connecte, et les deux paramètres qui comptent ici sont ce qu'il lit et de qui il accepte les messages. Par défaut, il lit les pièces jointes réelles et ignore le corps, ce qui est le mauvais réglage pour une confirmation sans pièce jointe utile. Ce défaut existe pour les messages qui contiennent un vrai fichier, cas pour lequel le workflow d'extraction de données d'e-mail par pièces jointes est conçu, et les confirmations de visite sont le cas inverse. Passer à corps uniquement ou pièces jointes et corps fait du message lui-même l'entrée ; le workflow d'extraction du corps uniquement explique ce mode plus en détail.
À partir de là, Custom Column Extraction est ce qui supprime le modèle propre à chaque plateforme. Vous saisissez les noms de colonnes souhaités, comme Property Address, Showing Date, Start Time, Status et Showing Agent, et l'IA trouve chaque valeur en comprenant ce qu'elle signifie plutôt que l'endroit où elle se trouve sur la page. Les noms que vous saisissez deviennent les en-têtes de la sortie. Le même ensemble de colonnes lit une confirmation ShowingTime, une confirmation BrokerBay et un avis de rendez-vous SentriLock sans règle distincte pour chaque format.
Définissez l'ensemble de colonnes une seule fois
Partez des colonnes au niveau du rendez-vous ci-dessus. Omettez les champs qu'aucune plateforme n'envoie, comme le texte de retour, et ajoutez-les plus tard uniquement si un véritable e-mail les contient.
Configurez une règle de transfert automatique pour les e-mails de plateforme
Dans Gmail ou Outlook, transférez les e-mails des expéditeurs de plateforme vers l'adresse de la boîte de réception dédiée. C'est l'étape qui supprime le transfert manuel de chaque confirmation. Une règle par expéditeur de plateforme suffit.
Désactivez le paramètre par défaut « pièces jointes uniquement » de la boîte de réception
Choisissez corps uniquement si les confirmations arrivent sous forme de texte de message, ou pièces jointes et corps si certaines plateformes joignent aussi un PDF. Avec le paramètre par défaut, une confirmation sans pièce jointe produit une ligne vide.
Ajoutez les adresses de plateforme à la liste blanche, pas les noms affichés
Une confirmation ShowingTime peut afficher le nom de l'agent vendeur comme expéditeur alors que l'adresse appartient à la plateforme. Filtrez sur l'adresse, sinon la liste blanche rejettera précisément l'e-mail que vous voulez.
Liez le modèle et activez le traitement automatique
Une fois l'ensemble de colonnes enregistré comme modèle, le traitement automatique lance l'extraction à l'arrivée des e-mails. Sans modèle lié, les messages restent dans la file d'attente jusqu'à ce que quelqu'un les lance manuellement.
Ajoutez au tableur ou exportez pour le CRM
L'add-on Google Sheets ajoute les lignes extraites à la feuille active sans quitter Sheets. Si la destination est un CRM, exportez le lot en CSV ou récupérez-le via l'API ; tous les CRM immobiliers courants importent le CSV.
La même structure de pipeline fonctionne pour une seule annonce ou un lot d'annonces : les lignes s'accumulent dans un seul tableau, la colonne de plateforme séparant les sources. Les mécanismes du transfert e-mail vers tableur, notamment que faire lorsqu'un fournisseur envoie à la fois un corps et une pièce jointe, sont détaillés dans le détail du pipeline e-mail vers feuille.
Conserver une seule ligne par visite après le report
Une ligne par visite nécessite deux couches : un journal en ajout seul et une vue courante. L'extraction ajoute une ligne pour chaque message qu'elle lit. Elle ne modifie ni ne supprime une ligne antérieure, la réconciliation doit donc se faire dans le tableur, pas dans l'extraction.
La première couche est le journal. Chaque confirmation, report et annulation obtient une ligne, et aucune ligne n'est jamais modifiée. C'est la piste d'audit : elle prouve ce que la plateforme a envoyé et quand. La conserver en ajout seul signifie aussi qu'une correction erronée reste visible au lieu d'écraser silencieusement l'original.
La deuxième couche est la vue courante. Elle lit le journal, conserve la dernière ligne active pour chaque rendez-vous et masque les lignes remplacées. Dans Google Sheets, une colonne auxiliaire sur une copie du journal fait le travail : triez par numéro de rendez-vous et par date de statut, puis comptez les lignes antérieures ayant la même clé. Une formule telle que =COUNTIFS($B$2:$B2,$B2)>1 signale chaque ligne après la première, et en filtrant le marqueur sur FALSE, il reste une ligne par rendez-vous.
Si la plateforme émet un nouveau numéro de confirmation pour un report, les anciennes et nouvelles lignes ne partageront pas de clé. Faites plutôt correspondre l'adresse du bien et l'agent de visite, et conservez la ligne dont le statut est le plus récent. Si une annulation arrive, définissez la politique avant la première : soit l'exclure de la vue courante et la laisser dans le journal, soit l'afficher comme annulée pour que le côté vendeur puisse voir pourquoi le créneau a disparu.
Quinze minutes de travail sur le tableur séparent un journal d'une vue courante. C'est aussi l'étape que la plupart des équipes sautent, ce qui explique pourquoi la feuille devient obsolète alors que l'extraction continue de fonctionner parfaitement.
Ce que cela ne fait pas
Le pipeline lit les e-mails et n'exécute pas la visite ; sa limite doit donc être claire avant que quiconque construise un rapport dessus.
- Aucune intégration native à la plateforme. Il n'existe pas de connecteur ShowingTime, SentriLock ou BrokerBay, pas de récupération via API depuis la plateforme de visite, et aucun moyen de réserver, confirmer, reporter ou annuler un rendez-vous depuis la feuille.
- Aucun contrôle du calendrier ni de la boîte à clés. Le pipeline n'écrit pas dans Google Calendar ni Outlook, et il n'ouvre, n'attribue ni ne gère de boîte à clés. Il enregistre ce que la plateforme a envoyé.
- Aucune mise à jour sur place. Un report produit une nouvelle ligne. Conserver une seule ligne à jour par visite relève de l'étape tableur à deux couches ci-dessus, et non d'un comportement automatique.
- Le rapport de la plateforme reste l'enregistrement par annonce. Le Listing Activity Report de ShowingTime inclut les informations sur l'agent de visite, les notes et les retours, et sa version propriétaire omet délibérément les détails de l'agent de visite (Listing Activity Report). Utilisez la feuille pour la vue multi-plateformes, multi-annonces, équipe et CRM que le rapport de la plateforme ne fournit pas, et non comme remplacement de celui-ci.
- La boîte de réception n'est aussi complète que les paramètres de notification. SentriKey envoie les notifications de visite à son Message Center même lorsque l'e-mail est désélectionné (guide SentriKey). Si quelqu'un du côté de l'annonce a désactivé l'e-mail, la confirmation existe mais n'atteint jamais le pipeline.
- Ce n'est pas un CRM. La sortie est un tableur ou du JSON. Follow Up Boss, kvCORE et systèmes similaires importent du CSV, et un envoi direct relève de l'API, pas d'un connecteur intégré.
Le journal s'arrête également là où commence le dossier de transaction. Une fois l'annonce sous contrat, l'activité de visite devient un contexte pour le dossier de documents de clôture, qui a ses propres règles d'exhaustivité et son propre emplacement.
FAQ
Un seul ensemble de colonnes peut-il lire ensemble les e-mails ShowingTime, SentriLock et BrokerBay ?
Oui, tant que les valeurs figurent dans le corps du message. Les trois plateformes utilisent une formulation et un ordre de champs différents, et l'Extraction de colonnes personnalisées trouve chaque valeur par son sens plutôt que par sa position, donc un seul ensemble de noms de colonnes couvre les trois. Une notification qui indique seulement « connectez-vous pour voir votre rendez-vous » et ne contient aucun détail ne peut pas produire de champs, car les valeurs ne sont pas dans le message.
Les confirmations nécessitent-elles une pièce jointe PDF ?
Non. La confirmation est envoyée comme contenu du message plutôt que comme un PDF à détacher, c'est pourquoi le réglage par défaut « pièces jointes uniquement » ne renvoie rien d'utile. Réglez la boîte de réception sur « corps uniquement » ou « pièces jointes et corps » pour que le texte du message soit lu directement.
Peut-il mettre à jour la ligne lorsqu'une visite est reportée ou annulée ?
Non. Chaque message devient une nouvelle ligne. Maintenir une vue courante signifie filtrer le journal en ajout seul pour ne garder que la dernière ligne active par rendez-vous, ce qui correspond à l'approche à deux couches décrite ci-dessus. L'extraction ne modifie ni ne supprime une ligne précédente.
Que se passe-t-il si le co-agent est absent de l'e-mail ?
Le pipeline laissera le champ vide, car la valeur n'y est pas. Cela signifie généralement que la plateforme de visite a récupéré l'annonce avant l'ajout du co-agent, et elle continuera d'envoyer un champ vide jusqu'à ce que le co-agent soit ajouté dans la plateforme de visite. Considérez ce vide comme une tâche à faire côté annonce, et non comme une erreur d'extraction.
Peut-il écrire directement dans Follow Up Boss ou kvCORE ?
Pas nativement. La sortie est un tableur ou du JSON, et le chemin standard est un import CSV dans le CRM. Les équipes qui ont besoin d'un envoi direct utilisent la REST API et un webhook comme passerelle maison.
Est-il sûr de conserver les codes de boîte à clés dans une feuille partagée ?
Généralement non. Une feuille partagée circule plus loin que l'e-mail de confirmation. Stockez l'emplacement de la keybox et l'instruction « code dans l'e-mail de confirmation » à moins que l'équipe ait réellement besoin du code dans la feuille ; si c'est le cas, restreignez l'accès et effacez les lignes après le rendez-vous, car un code journalier est mort une fois le rendez-vous passé.
Une feuille de visites est un registre de rendez-vous, pas une liste d'e-mails. Une fois la feuille indexée sur le rendez-vous, un report cesse d'être une exception et devient un changement de statut.
Ce changement est ce qui rend la feuille utilisable pour le rapport hebdomadaire au vendeur, le tableau de bord de l'équipe et l'import CRM. Testez-la sur une confirmation de chaque plateforme et voyez quels champs reviennent, et lesquels l'e-mail ne contenait jamais. Essayez sur une vraie confirmation de visite.