Bruidswarenhuis
Jullie kiezen ergens in de eerste maanden een fotograaf, een cateraar of een trouwauto. Op dat moment ontstaat er vanzelf een post in het budget, met de naam van de leverancier, de categorie waar die onder valt en de ruimte om een bedrag, een betaaldatum, een aanbetaling en een restbetaling in te vullen. Dat is het uitgangspunt van deze pagina: niet wat er gebeurt als je voor het eerst kiest, maar wat er gebeurt als je later van gedachten verandert.
Stel dat de cateraar na het eerste gesprek toch niet past, en jullie kiezen een andere partij met een ander tarief. Jullie passen het blok op de startpagina aan, en de post die daaraan gekoppeld is verandert mee: nieuwe naam, nieuwe categorie als dat nodig is, en een leeg bedrag waar eerst een bedrag stond. Er verandert niets automatisch aan wat je al had ingevuld aan aanbetaling of restbetaling, want dat waren bedragen die bij de oude leverancier hoorden. Die vul je opnieuw in, met de nieuwe datum en het nieuwe bedrag. Wat je dus bespaart is niet het intikken zelf, maar het zoeken naar waar dat bedrag ook alweer stond. De post staat er al, op dezelfde plek, onder dezelfde categorie.
Hetzelfde geldt als het bedrag verandert zonder dat de leverancier verandert. De fotograaf die jullie in januari boekten voor een dagdeel, wordt in april toch een hele dag omdat er ook 's avonds gefotografeerd moet worden. De offerte wijzigt, en dus wijzigt het bedrag in de post. Je vult het nieuwe bedrag in op dezelfde plek waar het oude stond, en het systeem rekent vanaf dat moment met het nieuwe bedrag wat er nog openstaat. Er is geen scheiding tussen een oud en een nieuw bedrag die je ergens moet samenvoegen: er is één post, met één actueel bedrag, en de rest reken je zelf niet meer uit.
Waarom dit belangrijker is dan het lijkt, zit in wat er anders was gegaan. Zonder een systeem dat de post aan de keuze koppelt, zou een wijziging in de fotograaf betekenen dat je een regel in een lijst moet opzoeken, aanpassen, en dan nagaan of het totaal van die categorie nog klopt, en daarna of het totaal van het hele budget nog klopt. Bij twee mensen die dit naast elkaar bijhouden, is dat het moment waarop er twee versies ontstaan: degene die het net heeft aangepast weet het, de ander leest nog het oude bedrag. Hier hoeft dat niet, omdat er maar één post is die bij die keuze hoort, en die post is voor jullie beiden hetzelfde scherm.
Het aparte veld voor aanbetaling en restbetaling maakt een wijziging preciezer dan wanneer er alleen een totaalbedrag zou staan. Als de trouwlocatie halverwege het traject een extra kostenpost toevoegt, bijvoorbeeld voor een langere huur van de zaal, dan raakt dat meestal alleen de restbetaling en niet de aanbetaling die al is voldaan. Je past dus alleen het restbedrag aan, en de aanbetaling blijft staan zoals die was. Dat voorkomt dat je bij elke wijziging het hele bedrag opnieuw moet uitzoeken: wat was al betaald, wat nog niet. Het systeem onthoudt dat onderscheid, jij hoeft alleen het deel aan te passen dat werkelijk verandert.
Er zijn ook wijzigingen die geen aanpassing van een bestaand bedrag zijn, maar het verdwijnen van een hele post. Als jullie besluiten dat er geen trouwauto komt en er in plaats daarvan met eigen vervoer wordt gereden, dan verdwijnt dat blok van de startpagina, en daarmee ook de post in het budget. Er blijft geen leeg bedrag staan dat je moet negeren of moet uitleggen aan wie er meekijkt. De schoonouders die toegang hebben tot het budget zien simpelweg dat die categorie er niet meer is, in plaats van een post met een bedrag van nul die vragen oproept.
Dat meekijken is precies waar een wijziging in het budget verder gaat dan een aanpassing in een spreadsheet die alleen jullie zien. Wie toegang heeft tot het budget, of tot een deel daarvan, ziet dezelfde post als jullie, met dezelfde stand van zaken. Als een van jullie ouders de rekening van de trouwlocatie betaalt en daarvoor inzage heeft in die specifieke post, dan zien zij het nieuwe bedrag zodra het is aangepast, zonder dat er een appje of een telefoontje aan vooraf moet gaan om te zeggen dat het bedrag is gewijzigd. Wat zij zien is niet een melding van een wijziging, maar het resultaat: het bedrag dat er nu staat, de datum die er nu staat, wat er nog open is.
Dat scheelt vooral in de situaties waarin een wijziging laat komt. Twee weken voor de bruiloft blijkt dat het aantal gasten toch hoger uitvalt dan waarop de catering was berekend, en de cateraar stuurt een aangepaste offerte met een hoger bedrag en een eerdere betaaldatum, omdat de rest snel voldaan moet zijn. Die aanpassing doe je op dezelfde post: het bedrag omhoog, de betaaldatum naar voren. Wat er nog openstaat wordt opnieuw berekend zodra je dat invult, en dat is meteen zichtbaar voor iedereen die op dat onderdeel meekijkt, zonder dat er nog een gesprek nodig is over wat er precies is veranderd.
Wat dit niet doet, is de wijziging voor je signaleren. Het systeem past niets aan totdat jullie het zelf invullen op de post die bij die keuze hoort. Een gewijzigde offerte van de bruidskleding, een verschoven betaaldatum van de trouwlocatie, een nieuw bedrag voor de bruidstaart omdat er toch een extra verdieping bij komt: dat moet je zelf invoeren op de plek waar de eerdere versie stond. Wat het systeem wel doet, is ervoor zorgen dat die plek altijd hetzelfde blijft, en dat je nooit twee posten voor dezelfde keuze naast elkaar hebt staan, een oude die je was vergeten te verwijderen en een nieuwe die je per ongeluk hebt aangemaakt.
De koppeling tussen keuze en post werkt dus vooral als een vaste plek, niet als een systeem dat wijzigingen actief opspoort. Wie een leverancier vervangt, een bedrag aanpast of een categorie laat vervallen, doet dat op de post die daar al voor bestond, en iedereen die daar toegang tot heeft ziet vanaf dat moment de nieuwe stand. Dat is het verschil met een lijst die je er losstaand naast bijhoudt: daar moet je de wijziging apart doorgeven, hier staat de wijziging vanzelf op de plek waar iedereen al kijkt.