Een offertewijziging van de klant correct bevestigen

De meeste misverstanden ontstaan niet door slechte bedoelingen, maar door onduidelijkheid over welk document geldt. Een nieuwe PDF heeft dezelfde bestandsnaam als de vorige, het onderwerp van de mail blijft hetzelfde en het verschil zit verstopt op pagina twee. De klant antwoordt 'oké' op een mail waarin hij drie versies ziet.

Diagnose in drie vragen:

• Kan de klant aan de offerte zelf zien welke versie hij leest?
• Kan hij zien wat precies is gewijzigd ten opzichte van de vorige versie?
• Staat er in de offerte wanneer ze verloopt en wat er met eerdere versies gebeurt?

Antwoord je op één van die vragen 'nee', dan bestaat het risico dat een oude PDF later als geldige afspraak wordt aangehaald. De procedure hieronder dicht die gaten.

Geef elke offerte een uniek kenmerk en een versienummer, en zet beide op de eerste pagina en in de bestandsnaam. Een duidelijk patroon is bijvoorbeeld kenmerk, versienummer en datum. Gebruik dat patroon consequent, ook voor kleine wijzigingen.

Voeg bovenaan een korte rubriek toe met drie velden: versie, datum van deze versie en vervangt versie. Daarmee weet een lezer meteen of hij de laatste in handen heeft. Zet in de nieuwe versie ook een zin dat eerdere versies niet meer gelden zodra de klant deze versie bevestigt.

Verwijder oude versies niet uit je eigen archief, maar markeer ze als vervangen. Je hebt ze nodig om later te kunnen aantonen wat er wanneer is afgesproken.

Een klant die alleen een nieuwe PDF ontvangt, moet zelf het verschil zoeken. Dat is precies waar fouten ontstaan. Neem daarom in de mail of op de eerste pagina een overzicht op van wat is gewijzigd, per onderdeel, met oude en nieuwe waarde naast elkaar.

Gebruik een vaste structuur: onderdeel, vroegere formulering, nieuwe formulering en gevolg voor prijs of planning. Noteer ook wat niet verandert, zodat de klant weet dat de rest ongewijzigd blijft. Vermijd formuleringen als 'kleine aanpassingen doorgevoerd'; die zeggen niets controleerbaars.

Is een wijziging pas haalbaar onder een voorwaarde, zet die voorwaarde dan bij het betrokken onderdeel zelf, niet in een algemene slotzin. Zo kan de klant bij het akkoord zien waar zijn bevestiging precies over gaat.

Loop deze lijst af voor je een gewijzigde offerte verstuurt. Elk punt is ja of nee; bij een nee verzend je niet.

• Het kenmerk is gelijk aan de vorige versie en het versienummer is verhoogd.
• De bestandsnaam bevat kenmerk, versie en datum.
• Bovenaan staat welke versie vervangen wordt.
• Een overzicht toont alle gewijzigde onderdelen met oude en nieuwe waarde.
• Prijs, planning en voorwaarden zijn herberekend en kloppen met elkaar.
• De geldigheidsdatum van deze versie staat er duidelijk op.
• Eerdere versies worden uitdrukkelijk als vervangen benoemd na akkoord.
• Het akkoord vraagt om een actieve bevestiging, niet enkel om stilte.
• In de mail staat één eenduidige vraag: ga je akkoord met versie X, ja of nee.

Een offerte met een hoger versienummer maar zonder lijst van wijzigingen voldoet niet aan deze controle, ook al is het document zelf correct.

Een mondelinge of vage bevestiging volstaat zelden als bewijs. Laat de klant daarom expliciet bevestigen met verwijzing naar kenmerk en versie, bijvoorbeeld door per mail te antwoorden met die gegevens. Laat je het akkoord via een webformulier lopen, dan zijn formuliergegevens het bewijs dat je later nodig hebt, dus bouw het zorgvuldig. Een formulierinzending op zich bewijst niet altijd wie akkoord gaf; bewaar daarom ook de bevestigingsmail en controleer de identiteit van de afzender.

De webrichtlijnen geven daarvoor bruikbare uitgangspunten. Het W3C benadrukt dat labels elk formulierveld identificeren en dat gebruikers instructies, bevestiging van ingegeven gegevens en duidelijke foutmeldingen nodig hebben (W3C-tutorial over formulieren). Voor validatie in de browser geldt dat client-side validatie de gebruiker snel feedback geeft, maar niet volstaat als beveiligingsmaatregel; controle aan serverzijde blijft nodig (MDN over formuliervalidatie).

Praktisch: toon in het formulier kenmerk en versie als vooraf ingevulde, leesbare tekst, laat de klant een aparte bevestiging aanvinken en stuur een kopie naar zijn adres. Of een gekozen formuliertool dit ondersteunt en hoe je de gegevens bewaart, controleer je bij je tool of beheerder.

Een fictief voorbeeld, enkel ter illustratie van invoer en controles. Een klant vraagt in versie 1 van een offerte om één onderdeel te schrappen en een ander uit te breiden. Je maakt versie 2 met dezelfde kenmerknaam, een nieuw versienummer en een nieuwe datum. Bovenaan staat 'vervangt versie 1'. Het overzicht toont twee wijzigingen: onderdeel A vervalt, onderdeel B krijgt een extra leveringsstap, met de herberekende prijs en planning ernaast. Onderaan staat een geldigheidsdatum.

Verwachte controles na verzending, zonder uitspraak over hoe snel een klant reageert:

1. De klant antwoordt met kenmerk en versienummer in zijn bevestiging.
2. In je archief staat versie 1 als vervangen en versie 2 als bevestigd, met datum van akkoord.
3. Er is nog maar één versie zonder status 'vervangen'.

Reageert de klant met een vage 'goed zo', vraag dan nog één keer om een expliciete bevestiging van versie 2 voor je start. Wil je zien welke zichtbare signalen je website uitstraalt rond contact en aanvraag, bekijk ze dan via Marketing Scan. Een publieke scan beoordeelt je interne offerteprocedure niet.