Projectontwikkelaar Nextensa behandelt opleverpunten en nazorg via Letsbuild en Ziggu, zodat het bouwteam en de koper met dezelfde lijst openstaande punten werken, ook na de sleuteloverdracht.
De oplevering loopt vast op het moment dat de lijst van het werfteam en de lijst van de koper twee verschillende lijsten worden. Het werfteam noteert punten per discipline, per status en per aannemer. De koper wil één ding weten: is mijn punt nu opgelost.
Tussen die twee lijsten zit de klantadviseur, die updates overtypt in mails. Punten raken opgelost zonder dat de koper het hoort. Punten blijven liggen tot de koper belt. Aannemers komen drie keer terug naar hetzelfde appartement, omdat twee van die bezoeken nooit bij het juiste punt zijn genoteerd.
Dat is geen bouwprobleem. Dat is een administratieprobleem met een opleverdatum eraan vast.
Opleverpunten en nazorg zijn twee fases van één lijst, gescheiden door het moment van de sleuteloverdracht.
De opleverronde komt eerst: het werfteam of een keurder loopt de unit na, legt elk gebrek en elk onafgewerkt punt vast en wijst het toe. Nazorg is alles na de sleutels, inclusief de verborgen gebreken die pas opduiken als er iemand woont, en de waarborgperiode die eraan hangt.
Het werk blijft hetzelfde. Wat verandert, is wie het gebrek vindt, en na de oplevering is dat de koper.
Nextensa draait beide fases op twee gekoppelde systemen: Letsbuild voor het bouwteam, Ziggu voor de koper, verbonden via de Letsbuild-koppeling zodat niemand een status hoeft over te typen.
Vóór de sleuteloverdracht wordt de rondgang vastgelegd in Letsbuild. Elk gebrek krijgt een categorie, een status en een verantwoordelijke. Het bouwteam werkt zijn eigen lijst af zoals het dat altijd deed, per discipline en per aannemer, in de tool die de mensen op de werf al gebruiken.
Die lijst krijgt de koper nooit te zien. Wat hij in Ziggu ziet, is de stand van zijn eigen unit: een punt staat open, een punt wordt aangepakt, een punt is klaar. De punten synchroniseren dagelijks, en iemand van het team bepaalt per verslag of de koper het te zien krijgt. Die beslissing is bewust. Ze houdt de werknotities van het werfteam uit het portaal van de koper, en zodra een verslag gepubliceerd is, bereiken latere updates op dat verslag de koper zonder dat er nog iets moet gebeuren.
Zodra een aannemer een punt in Letsbuild op opgelost zet, komt die wijziging bij de klantadviseur in Ziggu terecht zonder dat iemand erachteraan moet. De adviseur vraagt de koper daarna met één klik om de oplossing te bevestigen.
Na de oplevering draait de richting om. De koper vindt een verborgen gebrek en meldt het zelf in Ziggu, op zijn eigen unit, met foto en locatie. De klantadviseur leest de melding, bepaalt of ze bij een aannemer hoort en duwt ze door naar Letsbuild. Dezelfde lijst loopt door over de opleverdatum heen, in plaats van opnieuw te beginnen als mailthread. Voor een ontwikkelaar die enkele honderden units tegelijk oplevert, is die continuïteit het hele punt.
Elke stap in deze workflow bestaat twee keer: één keer in de tool van het bouwteam, één keer in het portaal van de koper. De twee kolommen naast elkaar zetten toont het snelst waar de koppeling het werk doet.
| Stap | Bouwteam, in Letsbuild | Koper, in Ziggu |
|---|---|---|
| Rondgang vóór de oplevering | Gebreken per unit vastgelegd, ingedeeld en toegewezen | Zijn unit toont open punten |
| Werk loopt | De aannemer past de status van het punt aan | Het punt staat op in uitvoering |
| Punt opgelost | Status op opgelost gezet | De adviseur vraagt om bevestiging |
| Koper reageert | Punt sluit, of komt terug met de opmerking van de koper | Aanvaarden, of vragen om er nog eens naar te kijken |
| Na de oplevering | De adviseur zet de melding door naar een aannemer | De koper meldt een nieuw gebrek met foto en locatie |
Voor geen enkele regel in die tabel is een vergadering nodig. De twee kolommen bewegen omdat de systemen aan elkaar hangen, niet omdat iemand een status heeft overgeschreven.
De goedkeuringsvraag is wat deze workflow onderscheidt van een gedeelde Excel: een punt wordt gesloten door de koper, niet door wie het heeft opgelost.
Zonder die stap is een opgelost punt alleen opgelost aan de kant van de ontwikkelaar. Twee weken later stapt de koper het appartement binnen, ziet dezelfde plint nog altijd loskomen en meldt het opnieuw als een nieuwe klacht. De aannemer heeft ondertussen gefactureerd en staat op een andere werf. Iedereen begint opnieuw, en het is het vertrouwen van de koper dat de klap krijgt, niet de planning.
Mét die stap heeft de lus een einde. De koper aanvaardt, en het punt sluit met zijn akkoord erbij. Of de koper aanvaardt niet, zegt wat er nog scheelt, en het punt blijft open met de reden eraan vast. Allebei bruikbaar. Het tweede is het bruikbaarst, want het komt binnen terwijl de aannemer nog op de werf staat.
Daar volgen twee dingen uit. De klantadviseur is geen doorgeefluik van statussen meer en behandelt de uitzonderingen, en dat is net het deel van het werk waar een mens voor nodig is. En de nazorgperiode start van een lijst waar allebei de partijen achter staan, in plaats van van twee lijsten die op de dag van de oplevering stilletjes uit elkaar zijn gelopen. Zo ziet het eruit voor een projectontwikkelaar met verschillende projecten tegelijk: één lijst, twee publieken, en per gebrek één moment van akkoord.
