Gastenlijst bij een grote bruiloft bijhouden

Bij twintig gasten hou je het in je hoofd. Wie er is, wie er niet is, wie nog moet antwoorden: dat overzicht past op een half A4'tje en meestal ook zonder. Bij een grote bruiloft, met honderd, honderdvijftig of meer namen uit twee families en twee vriendengroepen, houdt niemand dat meer bij zonder iets dat het voor je onthoudt. Niet omdat het ingewikkelder is, maar omdat er domweg te veel namen zijn om elke wijziging in je hoofd te corrigeren.

De gastenlijst in het dossier begint daarom niet met los typen. Je uploadt een of meer Excel-bestanden met namen, en het systeem zet die om naar een lijst waarin elke gast een eigen regel heeft. Dat is meteen ook waarom Excel het beginpunt is en geen los invoerveld: bij een grote bruiloft komen die namen zelden uit één bron. De ouders van de bruid hebben een lijst met de familie van hun kant, de ouders van de bruidegom hebben er een van hun kant, en jullie zelf hebben de lijst met vrienden en collega's. Drie bestanden, drie keer geüpload, en het dossier zet ze samen tot één gastenlijst. Niemand hoeft dus alle namen opnieuw te typen omdat iemand anders zijn lijst in een ander format had staan.

Wat een grote gastenlijst verder onderscheidt van een kleine, is niet het aantal namen op zich, maar het aantal statussen dat tegelijk in beweging is. Bij twintig gasten weet je na twee weken meestal wie er komt. Bij honderdvijftig gasten loopt het antwoorden weken uit elkaar: de eerste bevestigingen komen binnen voordat de laatste uitnodiging de deur uit is, en tussen die twee momenten verschuift er voortdurend iets. Daarom heeft elke gast in het dossier een eigen stand: uitgenodigd, komt, komt misschien, of komt niet. Dat is geen decoratie naast een naam, het is de informatie waar de rest van de planning op wacht.

Een voorbeeld maakt dat concreet. Stel de moeder van de bruidegom heeft veertig namen aangeleverd voor haar kant van de familie. Twee weken na het versturen van de uitnodigingen staan er van die veertig er dertig op uitgenodigd, zes op komt, twee op komt misschien en twee op komt niet. Zonder die vier standen zou je bij elke vraag over aantallen opnieuw moeten navragen wie inmiddels heeft gereageerd. Met de standen zie je het meteen, en zie je ook waar de onzekerheid nog zit: bij die twee die komt misschien hebben aangegeven.

Waar dat bij een grote bruiloft harder telt dan bij een kleine, is de tafelschikking. Die is in het dossier gebaseerd op de gastenlijst, en bij honderdvijftig gasten schuift er bij elke statuswijziging iets. Een stel dat van komt misschien naar komt niet gaat, laat twee stoelen leeg aan een tafel die daardoor scheef zit tegenover de tafel ernaast. Bij twintig gasten merk je dat meteen; bij honderdvijftig gasten merk je het pas als je het weer opzoekt. Omdat de tafelschikking op dezelfde gastenlijst draait, hoef je dat niet apart te synchroniseren: de stand van elke gast is meteen de stand waarmee de tafelschikking rekent.

De trouwwebsite is de tweede plek waar dat samenkomt, en ook daar is de winst het grootst zodra de aantallen oplopen. Gasten geven daar zelf door of ze komen, ook met de optie misschien, in plaats van dat jullie achter iedereen aan bellen. Bij twintig gasten bel je die vier mensen die niet reageren gewoon even op. Bij honderdvijftig gasten is dat geen telefoontje meer maar een project, en dan is het waardevol dat de reacties automatisch in dezelfde lijst komen als de namen die je vanuit Excel hebt aangeleverd. Je houdt dus niet twee lijsten bij die je met elkaar moet vergelijken, je houdt er één bij die van twee kanten wordt gevuld.

Daar hoort ook bij wat er niet gebeurt. Het systeem stuurt geen herinneringen naar gasten die nog niet gereageerd hebben, en het rekent de statussen niet automatisch door naar het aantal couverts bij de catering of het aantal auto's voor het vervoer. Wat er op komt misschien staat, blijft op komt misschien staan totdat iemand die stand zelf wijzigt. Bij een kleine bruiloft is dat een kleine moeite; bij een grote bruiloft betekent het dat je bewust een moment moet inplannen, ergens een week of twee voor de uiterste antwoorddatum, waarop je de lijst doorloopt en de gasten die nog niets hebben laten weten zelf benadert. Wie dat overslaat, ontdekt op de dag zelf dat er stoelen te weinig of te veel zijn, en dat is precies het probleem dat de standen juist zichtbaar hadden gemaakt als er op tijd naar gekeken was.

Een tweede grens: het systeem koppelt de gastenlijst niet aan de catering of aan het budget. Het aantal gasten dat komt is iets wat je zelf naast de post voor catering in het budget legt, en zelf bijwerkt als dat aantal verandert. Bij een gastenlijst van twintig mensen is dat een kwestie van even kijken; bij honderdvijftig mensen met een cateraar die per persoon rekent, is het de moeite waard om dat op een vast moment te doen, bijvoorbeeld direct na de uiterste antwoorddatum, in plaats van steeds een paar dagen achter de werkelijke aantallen aan te lopen.

Wat een grote gastenlijst dus vooral vraagt, is niet meer functionaliteit dan een kleine gastenlijst, maar een vaste gewoonte om ernaar te kijken. Bij twintig namen valt een gemiste wijziging vanzelf op omdat je de lijst uit je hoofd kent. Bij honderdvijftig namen valt die pas op als je hem opent, en dat is precies waarom de lijst met standen bestaat: niet om het aantal gasten te verkleinen, maar om zichtbaar te maken wat er op elk moment feitelijk vaststaat en wat nog open is. Wie ouders, getuigen of anderen toegang geeft tot precies dat deel van het dossier, kan die gewoonte ook delen: de moeder die haar veertig namen heeft aangeleverd, kan zelf zien wie van haar kant al heeft gereageerd, zonder dat daarvoor het hele dossier open moet.