Des leads bien générés, mal exploités

Open House génère des leads qualifiés pour ses agences immobilières partenaires via des campagnes Meta (Instagram, Facebook). Aujourd'hui, ces leads arrivent dans le Meta Lead Center — mais leur distribution aux agents est manuelle : export, envoi par WhatsApp ou email, suivi sur tableur. Les leads sont contactés trop tard, parfois oubliés, et le retour sur la qualité reste informel. Open House Leads résout ce problème en créant une couche opérationnelle entre Meta et les équipes terrain — récupération automatique, attribution claire, qualification structurée, actions immédiates.

Design HTML en cours — page Leads avancée, 5 pages à designer

Open House Leads est en ligne avec Magrey & Sons comme première agence intégrée. L'application est un fichier HTML unique (~4 069 lignes) déployé sur GitHub Pages. La page Leads avance : les cartes KPI ont été recentrées suite à un retour client — les étapes peu utilisées ont été remplacées par « Leads aujourd'hui » et « Non assignés », plus utiles au quotidien. Le header du drawer est finalisé (badge vérifié, score, campagne, type, actions contact). Le mobile affiche les leads en cards sous 600px avec badges d'activité et bande d'accent pour les leads non traités.

Trois cycles récents ont affiné cette page : le toggle Acquéreurs/Vendeurs a été redessiné (v0.10.3 — split-card, « une carte, deux moitiés »), les cards mobile affichent maintenant l'heure exacte d'arrivée du lead (v0.10.4), et le projet a été restructuré pour aligner docs et déploiement (v0.10.5 — app à /leads, rapport à /report).

Mais le gros du travail est devant : le contenu des 4 onglets du drawer (le workflow principal de l'agent), le popover de filtres, les actions groupées, le formulaire d'ajout. Et ensuite — Tableau de bord, Agents, Campagnes, Database, Paramètres. Chaque page doit être designée de zéro.

Prochaine étape immédiate : deux décisions produit à cadrer avant d'attaquer les onglets du drawer — le partage de vue entre agent et manager, et un redesign de la table desktop. Une fois ces deux points résolus, place aux onglets — Infos (formulaire éditable), Qualification (pipeline + agent), Activité (timeline), Notes.

HTML → PostgreSQL → Hetzner — simple et efficace

Le dashboard est conçu pour gérer plusieurs agences simultanément. Chaque agence dispose de son propre espace — leads isolés, agents dédiés, données séparées. Open House supervise l'ensemble depuis une vue super admin. L'intégration Meta fait le lien entre les campagnes et le dashboard. En interne d'abord, intégré aux offres Open House. Puis, à terme, un produit SaaS autonome.

Lancement doux — étape par étape

L'outil ne sera pas lancé en masse. La stratégie est progressive — construire la confiance avant de scaler.

Le flux de données — de Meta au terrain

Les leads générés par les campagnes Meta arrivent automatiquement dans le dashboard. Les agents qualifient les leads — et cette qualification remonte vers Meta pour améliorer le ciblage des futures campagnes.

Chaque qualification envoyée par un agent améliore le ciblage des futures campagnes. L'algorithme Meta apprend quels profils convertissent réellement.

Un toggle Acquéreurs/Vendeurs filtre la vue. Mêmes actions, même interface — seuls les champs et les étapes de pipeline changent. Construire deux modules séparés doublerait le code sans bénéfice pour l'utilisateur.

Le scoring (🔥🟡❄️) est un indicateur de priorité calculé automatiquement — « qui appeler en premier ce matin. » La qualification, c'est le pipeline : l'agent parle au lead et le fait avancer. C'est le pipeline qui remonte vers Meta via CAPI pour améliorer le ciblage, pas le score.

Chaque agence travaille différemment. Les étapes de pipeline sont stockées en JSON par agence — toute l'interface lit depuis ce tableau. Coûte presque rien à construire dès le départ, douloureux à ajouter après. C'est un des avantages clés face au Centre de Prospects Meta.

Certaines agences envoient un email type comme premier contact. Templates avec {nom}, {budget}, {secteur} — gain de temps, premier point de contact standardisé. Besoin réel confirmé par le workflow terrain.

Un système complet de gestion par email représente un chantier important pour des agences qui ne veulent pas de l'outil. Un toggle « notification email » par agence couvre le besoin. Si des clients payants demandent explicitement un mode email-only, il sera ajouté.

L'API WhatsApp Business nécessite une vérification Meta, coûte par message, et est complexe à intégrer. Les liens wa.me donnent un accès WhatsApp en un tap, zéro configuration. L'API Business sera ajoutée quand l'automatisation WhatsApp deviendra un vrai besoin.

Pour 2-3 agences, se connecter à chaque vue suffit. Le multi-tenancy est propre dès le départ (agency_id partout), donc ajouter une couche admin plus tard = nouvelle vue sur les données existantes, pas une restructuration.