Twee projectontwikkelaars koppelen Letsbuild aan Ziggu zodat opleverpunten en nazorgpunten bij de koper raken, met een dagelijkse synchronisatie en een beslissing per verslag over wat de koper ziet.
Letsbuild en Ziggu staan aan weerszijden van één puntenlijst. Het bouwteam werkt die lijst af in Letsbuild. De koper volgt zijn eigen punten in Ziggu. Die twee aan elkaar knopen, dat is wat de Letsbuild-koppeling doet.
Letsbuild, jarenlang bekend als Aproplan, is werfsoftware die breed gebruikt wordt in de Belgische bouw. Eén van de functies draait rond werfverslagen en het pv van voorlopige oplevering, en daar worden de meeste punten voor het eerst opgeschreven.
Op dat moment beginnen de twee lijsten ook uit elkaar te lopen. Het bouwteam ordent per aannemer, de koper wil maar één ding weten: is mijn punt al opgelost.
Vesta Development nam de koppeling om het opvolgwerk weg te halen dat achter elk opgelost punt zat. Mathias Nolf, projectleider bij Vesta, zegt het zonder omwegen.
“Tijdsbesparing was de sleutel. We gebruikten Letsbuild al bij het documenteren van openstaande punten bij voorlopige opleveringen, maar er was nog steeds veel opvolgwerk nodig nadien. Via Letsbuild kan de aannemer aanduiden dat zij een punt hebben opgelost. Maar, is onze klant wel tevreden met het resultaat? De klantenbegeleider moest telkens opnieuw de klant contacteren.”
Daar zit het gat. Een aannemer die een punt afsluit in Letsbuild zegt dat het werk gedaan is. Hij zegt niet dat de koper akkoord gaat, en dat uitzoeken kostte een telefoontje per punt.
“Dankzij de integratie zijn klant, ontwikkelaar en aannemer altijd in sync. Elk punt dat in Letsbuild wordt toegevoegd, verschijnt automatisch in het Ziggu-klantenportaal. Hierdoor is het voor iedereen duidelijk welke punten nog moeten worden behandeld, welke zijn opgelost door de aannemer en wachten op goedkeuring van de klant en welke volledig van de baan zijn.”
“Ook na oplevering kan de klant nog een punt melden, mocht dat nodig zijn. Zij zien dan meteen de status daarvan in hun portaal. Dat brengt gemoedsrust.”
Voor de uitrol verwijst Nolf naar Stratokit, de integratiepartner van Letsbuild: “De implementatie verliep vlot. We leerden van elkaar en konden langs weerszijden bepaalde workflows verbeteren.” Over digitalisering bij Vesta in het algemeen: “Wij willen snel kunnen inspelen op nieuwe ontwikkelingen die duidelijke voordelen bieden op vlak van efficiëntie. Ook voor Ziggu hebben we die rekenoefening gemaakt: het platform helpt ons als team fouten vermijden. De kostprijs per unit is dus snel terugverdiend.”
ION Develop Different ging met één doel van start: dezelfde status niet twee keer moeten invoeren. Cederic Veryser, head of digital bij ION, beschrijft wat dat vroeger kostte.
“Het doel was om zo min mogelijk dubbel werk te doen. Vroeger moest een klantenbegeleider telkens ieder punt in Ziggu manueel gaan updaten op basis van de status in Letsbuild. Dankzij de integratie loopt deze infostroom volledig gestroomlijnd zonder dat ze hierin moeten tussenkomen.”
Veryser noemt twee winsten. De koper krijgt een overzicht van zijn punten, met beschrijving, foto's en status. De klantenbegeleider verliest een taak.
“Vroeger, wanneer een klant een update vroeg over deze puntjes, moest je als klantenbegeleider daar wel wat tijd in steken. Eerst zocht je in Ziggu op wat de klant gemeld had. In Letsbuild ging je daarna de status opzoeken om vervolgens opnieuw in Ziggu dit voor de klant te gaan samenvatten.”
Zijn derde punt overleeft elke verandering van tools.
“Vanuit een software architectuur standpunt vind ik het belangrijk dat er nu een duidelijke centrale bron van waarheid is. Voor nazorg is dit Letsbuild en dat blijft mogelijk dankzij de datastroom met Ziggu.”
“Voor ION is dit de toekomst. Tijdswinst voor onze mensen en een hogere klantentevredenheid. De ROI van dit project valt niet te betwijfelen.”
Het verschil lees je het snelst in twee kolommen: dezelfde vijf momenten, één keer zonder koppeling en één keer met.
| Moment | Zonder koppeling | Met Letsbuild gekoppeld aan Ziggu |
|---|---|---|
| Een punt wordt genoteerd bij voorlopige oplevering | De klantenbegeleider zet het over in het klantportaal | Het punt komt mee met de dagelijkse synchronisatie |
| Een aannemer lost een punt op | De klantenbegeleider kijkt in Letsbuild en past daarna het portaal aan | De nieuwe status komt mee met de dagelijkse synchronisatie |
| De koper vraagt hoe het met zijn punt staat | De klantenbegeleider zoekt in beide systemen en schrijft een samenvatting | De koper leest het zelf in het portaal |
| De koper meldt een gebrek na oplevering | De klantenbegeleider typt het over in het werfsysteem | De klantenbegeleider stuurt de melding door naar Letsbuild |
| Waar de waarheid zit | Twee lijsten die uit elkaar groeien | Letsbuild voor de nazorg, gespiegeld naar de koper |
Niets in die tabel haalt een mens uit het proces. Het haalt het overtypen eruit.
De koppeling is geen open kraan. Iemand van het team beslist per verslag of de koper het überhaupt te zien krijgt.
Punten synchroniseren één keer per dag vanuit Letsbuild. Ze komen in Ziggu bij de juiste unit terecht, en de koper ziet ze pas als iemand het verslag publiceert. In die ene beslissing zit het oordeel. Interne categorieën, werknotities en halfafgewerkte aannemerslijsten blijven bij het bouwteam.
Is een verslag eenmaal gepubliceerd, dan blijft de koper het krijgen. Updates die in datzelfde verslag binnenlopen bereiken hem zonder dat er in Ziggu nog iets moet gebeuren. Eén beslissing vooraf, en daarna houdt het verslag zichzelf bij.
Dat is het verschil met een gedeelde map. Een gedeelde map geeft de koper alles of niets. Publiceren per verslag laat je de lijn één keer trekken, op de juiste plaats.
Na de oplevering draait de richting om. Een koper die een verborgen gebrek vindt, meldt het in Ziggu bij zijn eigen unit, met een foto. De klantenbegeleider leest het, beslist of het bij een aannemer hoort en stuurt het door naar Letsbuild. De lijst loopt door over de opleverdatum heen in plaats van opnieuw te beginnen als een mailconversatie.
Twee ontwikkelaars, dezelfde conclusie. Vesta telt het in telefoontjes die niet meer moeten, ION in typwerk dat wegviel. Voor een ontwikkelaar die oplevering en nazorg als één workflow draait, houdt deze koppeling beide helften van de lijst op hetzelfde gericht.
