Mille biens sur la carte. Le client a besoin d’une décision

Une carte immobilière donne vite une impression d’échelle. On zoome sur un quartier, des points apparaissent. Encore un zoom, et il y a plus de points que de temps disponible pour l’acheteur.

J’ai étudié Developers Map et préparé une proposition d’évolution. Le service original n’est pas mon développement. Mon travail est l’audit du parcours, le concept produit et un prototype interactif distinct. Ses données sont démonstratives ; ce n’est pas une nouvelle offre immobilière active.

Voici le prototype conservé de la carte Developers Map avec un jeu de biens fictifs. On peut examiner l’interface originale et les filtres disponibles.

Carte et filtres

Interface archivée · données de démonstration

Par où je propose de commencer

Par le besoin : pourquoi acheter, quel budget, combien de chambres, quelle échéance et quel paiement ? Ce brief mérite une existence propre. Sinon, chaque recherche repart des filtres dont le sens reste dans la tête du courtier.

Le parcours devient : formuler le besoin, trouver, vérifier, comparer, présenter au client, agir. La carte y a une place importante mais précisément définie.

Le deuxième écran montre la vue préparée de Decision Room. C’est un élément du prototype pour discuter les décisions, pas une confirmation de disponibilité du service principal.

Salle de décision

Interface archivée · données de démonstration

Je m’intéresse à l’après-recherche : qu’avons-nous trouvé ? Le prix est-il récent ? Le bien disponible ? La livraison a-t-elle une source ? Zéro, inconnu et donnée ancienne doivent être différents. Sinon, l’interface apprend à croire une absence de données joliment formatée.

La sélection doit survivre à l’envoi

Je propose de conserver une shortlist de biens précis plutôt que d’envoyer des cartes aléatoires à chaque fois. La version client et le PDF doivent décrire les mêmes biens que voit le courtier, surtout si quelque chose a changé avant le rendez-vous.

Vient ensuite Decision Room, un espace de comparaison. Les compromis deviennent visibles : une option respecte mieux le délai, une autre le budget, une troisième exige un autre paiement. Le client réagit à des options précises ; la discussion cesse de se disperser en captures « et celui-ci ? ».

Dans le concept, Launch Room traite les changements et prochaines actions : informations mises à jour, vérifications, points à reprendre. C’est un scénario proposé, pas une promesse que le service surveille déjà tous les événements.

Pourquoi commencer par un prototype

Le produit original a sa technologie et son API. Je ne propose pas de le réécrire dans ma stack favorite pour dessiner un autre filtre. Un prototype HTML, CSS et JavaScript séparé permet de parcourir et discuter le nouveau chemin avant de toucher au système actif.

Les scénarios d’autres marchés restent aussi une démonstration d’extensibilité. Mascate, Tbilissi ou Bali dans une maquette ne signifient pas que nous possédons un catalogue vérifié de ces villes.

C’est un travail qui m’intéresse beaucoup : prendre un produit déjà capable et trouver où la personne reste seule face à la décision. L’AI accélère la recherche et la construction d’options. La valeur apparaît quand ces options forment un parcours praticable et vérifiable.

Le résultat est une proposition de parcours et un prototype distinct pour en discuter. Brief, shortlist, Decision Room et Launch Room appartiennent au concept ; ce ne sont pas des fonctions déjà publiées de Developers Map.

Articles liés : Support Telegram · CRM pour courtiers.