Dans une conversation, une promesse semble fiable. « Je l’envoie ce soir. » « Je reviens après le rendez-vous. » « Je vérifie avec le propriétaire. » Puis quarante messages arrivent, et la promesse rejoint un petit cimetière textuel où la retrouver exige presque un effort de conscience.
Mon CRM immobilier est né du souhait de voir ce travail dans son ensemble. Contact, source, historique, prochaine étape et message préparé doivent être réunis. Sinon, l’agent ne vend pas : il reconstitue sa propre mémoire de travail.
Cet écran rassemble les informations d’un propriétaire fictif, ses biens et l’historique du travail. On voit un contact devenir un dossier de travail, au lieu de rester une ligne avec un numéro de téléphone.
Dossier du propriétaire
Interface archivée · données de démonstration
Trois bases pour trois types d’informations
L’architecture actuelle utilise Cloudflare Workers et des bases D1 distinctes pour le CRM, les prospects du marché secondaire et l’index des courtiers. Cette séparation évite de considérer chaque numéro trouvé comme un client à part entière doté des mêmes droits et du même historique.
Un écran distinct présente les critères d’un acheteur fictif. Il permet d’examiner l’autre versant du métier : ce que la personne cherche et les informations nécessaires à la sélection suivante.
Critères de l’acheteur
Interface archivée · données de démonstration
La couche opérationnelle forme des vagues de travail et des actions. Le retraitement est protégé contre les doublons : une même étape préparée ne doit pas réapparaître à cause d’une relance. C’est l’idempotence. Un mot long pour un objectif simple : l’ordinateur ne doit pas doubler le travail parce qu’il ne s’est pas entendu lui-même.
L’envoi des messages reste une action manuelle distincte. Le système peut préparer le contact et le texte, mais l’intention d’écrire ne vaut pas communication effectuée. Un refus de nouvelles sollicitations bloque la suite du travail sur ce canal.
L’AI aide à l’entrée, la base est nécessaire à la sortie
L’interface conversationnelle aide à formuler une tâche en mots ordinaires. Mais le résultat doit devenir une fiche concrète : destinataire clair, état et prochaine action. Si tout reste dans la réponse de l’assistant, le CRM n’a rien appris.
Un tableau externe ne doit pas non plus rester discrètement une seconde base active. Sinon, l’opérateur corrige le contact ici, l’agent lit un ancien export là-bas, et tous deux pensent travailler soigneusement.
Tous les modules envisagés ne sont pas devenus des processus opérationnels. Comps Engine et les scénarios PDF associés sont suspendus. Certaines modifications techniques récentes nécessitent encore une vérification dans l’environnement de travail. Je ne réunis pas plans, code source et opérations confirmées dans une promesse publicitaire « tout est automatisé ».
Dans le CRM, je relie contact, informations du bien et prochaine étape. L’envoi est séparé de la préparation : cela rend visibles promesses et actions sans présenter tout le travail comme automatique. Comps Engine et les scénarios PDF associés sont décrits séparément comme une piste suspendue.
Histoires liées : Premier outil WhatsApp · WhatsApp pour l’équipe · Exploration de Comps Engine.
@nevsky_alexander
Sur Instagram, Dubaï au-delà de la carte postale : la famille, la ville, les trouvailles et la vie entre deux projets. Sur Threads, des réflexions à voix haute sur le design et l’IA. Sur YouTube, des vidéos qui ont besoin de plus de place qu’une story. Retrouvez-moi là où vous vous sentez bien, et gardons le contact