Le promoteur Nextensa gère les réserves, la réception et le service après-vente via Letsbuild et Ziggu, pour que l'équipe de chantier et l'acquéreur travaillent sur la même liste.
La réception coince au moment précis où la liste de l'équipe de chantier et celle de l'acquéreur deviennent deux listes différentes. L'équipe de chantier classe les réserves par corps de métier, par statut et par entrepreneur. L'acquéreur veut savoir une seule chose : mon point est-il traité.
Entre ces deux listes se trouve le conseiller client, qui retape des mises à jour dans des e-mails. Des points sont résolus sans que l'acquéreur l'apprenne. D'autres restent en attente jusqu'à ce qu'il appelle. Les entrepreneurs reviennent trois fois dans le même appartement, parce que deux de ces passages n'ont jamais été notés sur le bon point.
Rien de tout cela n'est un problème de construction. C'est un problème d'administration, avec une date de livraison au bout.
Les réserves et le service après-vente sont deux phases d'une seule liste, séparées par le moment de la remise des clés.
La visite de réception vient d'abord : l'équipe de chantier ou un inspecteur parcourt l'unité, consigne chaque défaut et chaque finition manquante, puis les attribue. Le service après-vente couvre tout ce qui suit les clés, y compris les défauts cachés qui n'apparaissent qu'une fois le logement habité et la période de garantie qui y est liée.
Le travail reste le même. Ce qui change, c'est qui trouve le défaut, et après la réception c'est l'acquéreur.
Nextensa fait tourner les deux phases sur deux systèmes reliés : Letsbuild pour l'équipe de construction, Ziggu pour l'acquéreur, connectés par l'intégration Letsbuild pour que personne n'ait à retaper un statut.
Avant la remise des clés, la visite est consignée dans Letsbuild. Chaque défaut reçoit une catégorie, un statut et un responsable. L'équipe de construction traite sa propre liste comme elle l'a toujours fait, par corps de métier et par entrepreneur, dans l'outil que ses équipes de terrain utilisent déjà.
Cette liste, l'acquéreur ne la voit jamais. Ce qu'il voit dans Ziggu, c'est l'état de sa propre unité : un point est ouvert, un point est en cours, un point est terminé. Les réserves se synchronisent quotidiennement, et un membre de l'équipe décide rapport par rapport si l'acquéreur y a accès. Cette décision est voulue. Elle garde les notes de travail du chantier hors du portail de l'acquéreur, et une fois un rapport publié, les mises à jour ultérieures sur ce rapport parviennent à l'acquéreur sans nouvelle intervention.
Dès qu'un entrepreneur passe un point en résolu dans Letsbuild, la modification arrive chez le conseiller client dans Ziggu sans que personne ait à la chercher. Le conseiller demande ensuite à l'acquéreur de confirmer la réparation, en un clic.
Après la réception, le sens s'inverse. L'acquéreur découvre un défaut caché et le signale lui-même dans Ziggu, sur sa propre unité, avec une photo et une localisation. Le conseiller client lit le signalement, décide s'il revient à un entrepreneur et le pousse vers Letsbuild. La même liste se poursuit par-dessus la date de réception au lieu de repartir sous forme de fil d'e-mails. Pour un promoteur qui livre plusieurs centaines d'unités à la fois, cette continuité est tout l'enjeu.
Chaque étape de ce flux existe deux fois : une fois dans l'outil de l'équipe de construction, une fois dans le portail de l'acquéreur. Mettre les deux colonnes côte à côte montre le plus vite où l'intégration fait le travail.
| Étape | Équipe de construction, dans Letsbuild | Acquéreur, dans Ziggu |
|---|---|---|
| Visite avant réception | Défauts consignés par unité, classés et attribués | Son unité affiche des points ouverts |
| Travaux en cours | L'entrepreneur met à jour le statut du point | Le point s'affiche en cours de traitement |
| Point résolu | Statut passé en résolu | Le conseiller demande une confirmation |
| Réponse de l'acquéreur | Le point se ferme, ou revient avec son commentaire | Accepter, ou demander un nouveau passage |
| Après la réception | Le conseiller transmet le signalement à un entrepreneur | L'acquéreur signale un nouveau défaut avec photo et localisation |
Aucune ligne de ce tableau ne demande une réunion. Les deux colonnes bougent parce que les systèmes sont reliés, pas parce que quelqu'un a recopié un statut.
La demande de validation est ce qui distingue ce flux d'un tableur partagé : un point est fermé par l'acquéreur, pas par celui qui l'a réparé.
Sans cette étape, un point résolu ne l'est que du côté du promoteur. Deux semaines plus tard, l'acquéreur entre dans l'appartement, retrouve la même plinthe qui se décolle et le signale une nouvelle fois comme une nouvelle plainte. L'entrepreneur a facturé et se trouve sur un autre chantier. Tout le monde recommence, et c'est la confiance de l'acquéreur qui encaisse, pas le planning.
Avec cette étape, la boucle a une fin. L'acquéreur accepte, et le point se ferme avec son accord au dossier. Ou il n'accepte pas, dit ce qui ne va toujours pas, et le point reste ouvert avec la raison attachée. Les deux issues servent. La seconde sert davantage, parce qu'elle arrive pendant que l'entrepreneur est encore sur le chantier.
Deux conséquences en découlent. Le conseiller client cesse d'être un relais de statuts et traite les exceptions, c'est-à-dire la part du travail qui demande une personne. Et la période de service après-vente démarre sur une liste que les deux parties reconnaissent, plutôt que sur deux listes qui ont divergé le jour de la réception. Voilà à quoi cela ressemble pour un promoteur immobilier qui mène plusieurs projets de front : une seule liste, deux publics, un accord par défaut constaté.
