Meerwerk: hoe je elke wijziging vastlegt voordat er discussie over komt
Meerwerk verandert de prijs, de planning of allebei. Wie elke goedkeuring vastlegt met een naam en een datum, sluit de discussie af voordat ze begint.
Meerwerk verandert de prijs, de planning of allebei. Wie elke goedkeuring vastlegt met een naam en een datum, sluit de discussie af voordat ze begint.

Meerwerk is werk dat niet in de oorspronkelijke opdracht zat en er tijdens de uitvoering bij komt. Een andere kraan, een extra stopcontact, een wand die dertig centimeter opschuift, een optie die de klant er halverwege bij wil. Het verandert de prijs, de planning of allebei, en het geldt pas als de opdrachtgever ermee akkoord gaat. Het spiegelbeeld heet minderwerk: iets dat wegvalt en in mindering komt.
Die laatste voorwaarde is waar het misgaat. Een klant die op de werf een vraag stelt, is geen contract aan het wijzigen. Hij vraagt iets, krijgt antwoord, en gaat ervan uit dat het geregeld is. De uitvoerder denkt hetzelfde. Niemand legt iets vast, want op dat moment lijkt er niets vast te leggen. Het was een gesprek.
Zes maanden later staat de keuken er met de verkeerde grepen, en herinneren beide partijen zich dat gesprek anders.
Meerwerk is geen bouwterm. Het is wat er gebeurt zodra een klant tijdens de uitvoering nog keuzes maakt, en dat gebeurt in vrijwel elk project waar iemand voor een ander werkt.
Een projectontwikkelaar heeft honderd kopers die elk hun eigen afwerkingsniveau kiezen, elk met een eigen deadline en een eigen prijskaartje. Een aannemer krijgt de vraag op de werf, tussen twee andere taken door. Een machinebouwer levert een installatie waar de klant halverwege een extra module bij wil, met gevolgen voor de doorlooptijd. Een bureau ziet de scope schuiven zodra de klant het eerste ontwerp gezien heeft.
Dezelfde gebeurtenis, andere sector, hetzelfde probleem: iemand zegt ja, en dat ja moet later terug te vinden zijn.
Bij een aanbesteding heeft die gebeurtenis een vorm. Er is een bestek, een bouwdirectie en een genummerd document dat rondgaat voor handtekening. Bij een particuliere opdracht komt precies hetzelfde binnen als een appje op dinsdagavond.
Het verschil zit niet in inzet. Het zit erin dat niemand heeft afgesproken waar deze dingen thuishoren. In een klein team is het proces vaak degene die eraan dacht een bevestigingsmail te sturen, en die persoon staat niet altijd in de kamer. Beslissingen worden genomen via WhatsApp, bevestigd met een knik, en opgeslagen in iemands hoofd. Vertrekt die iemand, dan vertrekt de geschiedenis van het project mee.
Een niet-vastgelegd akkoord kost geld op het moment dat er iets over gevraagd wordt. Tussen het materiaal, de uren en het tweede bezoek loopt een verkeerd bestelde keuken in de duizenden euro's, en dan is er nog niets gezegd over de goodwill die je erin steekt.
De schade zit zelden in één groot conflict. Ze zit in de trage versie: hier een wijziging, daar een misverstand, elk apart opgevangen in plaats van uitgevochten, en elk apart weggehaald uit de marge op dat project.
Een goedkeuring die via WhatsApp gegeven is, houdt het niet omdat het bericht het antwoord draagt maar niet waar dat antwoord over ging. De chat bewaart een ja. Hij bewaart niet de omschrijving, de prijs, de deadline of de versie van de tekening die iedereen voor ogen had.
Daarom is de oplossing geen betere chat. Het is een plek waar de keuze zelf haar prijs, haar deadline en de naam van wie ze goedkeurde meedraagt, zodat de goedkeuring en het goedgekeurde niet uit elkaar lopen.
Het loopt telkens hetzelfde. Een klant vraagt op dinsdagavond naar een optie. Iemand antwoordt met een bedrag. Niemand legt vast bij welke van de drie offertes dat bedrag hoorde. Komt de factuur, dan discussieert iedereen over een bericht in plaats van een dossier te lezen.
Een appje is prima voor de vraag. Het antwoord hoort ergens waar je het opnieuw kan tonen.
Een vastgelegde goedkeuring draagt vier dingen: wat er wijzigt, wat het kost, wat het met de planning doet, en wie het wanneer heeft goedgekeurd. Minder dan dat is een notitie. Met die vier is het meerwerk geen verhaal meer dat twee mensen verschillend vertellen, maar een document dat voor zichzelf spreekt.
De mechaniek is gewoon. Elke keuze wordt een eigen item. De klant opent het, ziet de omschrijving, de tekening, de prijsimpact en de deadline, en keurt goed. Zijn naam en de datum blijven eraan hangen. Het uitvoerende team werkt vanaf de goedgekeurde versie, en alleen die.
De waarde komt twee keer boven, en de tweede keer is degene waar niemand op rekent. De eerste is op het moment van de wijziging, wanneer de prijs vastligt voordat de bestelling naar de leverancier gaat in plaats van erna. De tweede is bij de oplevering, wanneer een klant achttien maanden later een factuurregel betwist en het antwoord een document is in plaats van een discussie over wat er in maart gezegd zou zijn.
| Akkoord in een gesprek | Vastgelegde goedkeuring | |
|---|---|---|
| Waar het staat | Een telefoontje, een werfbezoek, een mailwisseling | Het projectdossier, bij de beslissing waar het bij hoort |
| Wie het terugvindt | Wie erbij was | Iedereen op het project, jaren later |
| Wat het bewijst | Wat elke partij zich herinnert | De exacte omschrijving die is goedgekeurd |
| Wat de klant zag | Een mondelinge toelichting | De omschrijving, de tekening, de prijs en de deadline |
| Kosten bij discussie | Herstelwerk, een tweede bezoek, een conflict | Een goedkeuring met een naam en een datum |
Een klant hoort geen training nodig te hebben om een keuze goed te keuren die hij al gemaakt heeft. Dat bezwaar komt in elk gesprek terug, en het is terecht: iemand die een keuken uitzoekt gaat daar geen software voor leren.
De goedkeuring moet dus één handeling zijn. Er komt een melding binnen, die opent op het ene ding dat beslist moet worden, en daarna is het klaar. Geen inlogdoolhof, geen handleiding, geen tweede systeem om te onthouden. Het structureren van de beslissing ligt bij jou. Het goedkeuren blijft zo klein als het kan.
Het moet ook de werf overleven. Meerwerk ontstaat in halve ruimtes en op locatie, niet achter een bureau. Vraagt een klant of dat eiland drie meter kan opschuiven, dan is de bruikbare versie: vastleggen, prijzen en ter goedkeuring sturen voordat iedereen weer weg is.
Ziggu legt elke beslissing vast in het project waar ze bij hoort, met de prijs, de deadline en de goedkeuring die haar afsluit. Jouw team voert uit. De klant ziet en tekent de delen die hem aangaan, en allebei kijken jullie naar hetzelfde dossier.
In vier landen gebruiken meer dan 2.500 bedrijven Ziggu voor ongeveer 30.000 lopende projecten, met ruim 42.000 klanten die inloggen om hun eigen project te volgen. Het onderdeel dat dit werk draagt is beslissingen en goedkeuringen, en hetzelfde probleem vanaf de kant van het berichtenverkeer staat in wat er in de plaats van WhatsApp komt.
Het eerste meerwerk dat zonder discussie wordt afgesloten, maakt het argument zelf.