Importer vos logements et vos résidents, sans ressaisie

C'est l'étape que personne ne met dans un cahier des charges, et celle sur laquelle le plus d'opérations prennent trois semaines de retard. La base de logements conditionne tout ce qui suit : le ciblage des campagnes, l'envoi des invitations, le suivi par bâtiment, les exports de fin d'opération. Mal renseignée au départ, elle se paie tous les jours ensuite.

Déposez le fichier tel qu'il est

Vos données existent déjà, quelque part : un export de progiciel, un tableur maintenu par le chargé de secteur, une liste transmise par le maître d'ouvrage. Elles ne sont jamais au format attendu, et demander leur remise en forme préalable revient à demander une semaine de travail à quelqu'un qui n'en a pas.

L'import est donc assisté : vous déposez le fichier sans le retoucher, la correspondance entre vos colonnes et les champs de MON-RDV.com est proposée automatiquement, et vous la corrigez à l'écran si elle se trompe. Aucune colonne à renommer, aucun modèle à respecter.

Les champs qui décident de la suite

Le téléphone. C'est le champ structurant : un logement sans numéro ne recevra rien, quel que soit le reste du dispositif. Les numéros doivent pouvoir être normalisés au format international ; un numéro mal formé est rejeté à l'envoi, pas à l'import — le récapitulatif avant lancement vous liste donc les logements muets pendant qu'il est encore temps de les corriger.

Bâtiment, hall, étage, appartement. Ce sont vos critères de ciblage. Un fichier importé sans bâtiment vous interdit définitivement la campagne « bâtiment A seulement », et c'est le genre de découverte qu'on fait la veille d'un envoi.

L'email, utile en complément, jamais suffisant seul.

L'étiquette. Un champ libre pour vos propres regroupements : « locataire fragile », « déjà rénové », « refus travaux », « présence obligatoire d'un traducteur ». C'est votre marge de manœuvre : tout ce que votre organisation a de spécifique passe par là, et se retrouve ensuite dans le ciblage des campagnes.

Une base par résidence, pas par opération

Les logements se saisissent une fois pour la résidence. Le projet de réhabilitation, la campagne de diagnostics et l'entretien courant de l'an prochain piochent dans la même base.

Conséquence pratique : la qualité de l'import se rentabilise sur plusieurs opérations, et une correction faite au fil de l'eau — un numéro erroné signalé par une campagne, un changement de locataire — bénéficie à toutes les suivantes.

Entreprises et intervenants

La même logique s'applique de l'autre côté : les entreprises et leurs intervenants se déclarent une fois, avec leurs coordonnées et leur périmètre. Ils accèdent ensuite à leur planning et à leurs rapports sans que vous ayez à leur transmettre quoi que ce soit — c'est ce qui permet au planning des entreprises d'être consulté plutôt que diffusé.

Fichier ou API

Sur une opération ponctuelle, le fichier reste plus rapide à mettre en place et n'engage personne.

Sur un parc suivi dans la durée, la connexion par API évite le décalage entre votre référentiel et le nôtre — les entrées et sorties de locataires étant précisément ce qui rend un fichier obsolète en quelques semaines.

Les trois pièges

Réimporter un fichier complet pour ajouter dix logements. L'ajout à l'unité existe pour ça, et il évite d'écraser des corrections faites entre-temps.

Laisser bâtiment et hall vides « parce qu'on verra plus tard ». On ne voit jamais plus tard, et c'est le ciblage de toutes les campagnes futures qui se ferme.

Traiter la liste des numéros manquants après le premier envoi. Le récapitulatif les signale avant : les traiter à ce moment-là coûte une heure, les traiter après coûte une relance et un point de taux d'ouverture de porte.