Bruidswarenhuis
De tafelschikking is geen los schema dat je een week van tevoren tekent. Het is een uitwerking van de gastenlijst die je al maanden bijhoudt. Wie daar geen verband tussen maakt, tekent op basis van een lijst die niet meer klopt, en ontdekt dat op het moment dat het lastig is om nog iets te veranderen.
De gastenlijst in het dossier komt uit de Excel-bestanden die jullie geüpload hebben, en elke naam daarin heeft een stand: uitgenodigd, komt, komt misschien, komt niet. Die standen veranderen de hele aanloop door. Een collega van je vader zegt in januari nog niets, meldt zich in maart af via de trouwwebsite, en een neef die eerst twijfelde blijkt toch te komen. Als de tafelschikking op die lijst is gebaseerd, verschuift zij vanzelf mee. Is zij dat niet, dan zit je in juni een tafelindeling te maken op naam van iemand die al drie maanden op komt niet staat.
Stel dat je de tafelschikking apart in een eigen Excelbestand bijhoudt, naast de gastenlijst in het dossier. Dat werkt prima tot iemand zich afmeldt. Je past het aan in het ene bestand, maar vergeet het in het andere, of andersom. Twee weken later stuurt je moeder een appje dat ze zich afvraagt waar tante Corrie nu zit, en jullie weten het geen van beiden meer zeker, omdat er twee versies van de waarheid rondgaan. Dat is niet een kwestie van slordigheid; dat gebeurt gewoon als twee lijsten met dezelfde namen niet aan elkaar vastzitten.
Het omgekeerde probleem is net zo gewoon. Iemand meldt zich pas laat aan als komt, nadat eerst komt misschien op de gastenlijst stond. Als de tafelschikking daar niet automatisch op reageert, ontbreekt die naam gewoon op de dag zelf, terwijl hij overal in de administratie wel als bevestigd staat. Dat is vervelender dan een naam die dubbel gepland staat, want een lege plek aan een tafel valt op tijdens het diner zelf, en dan is er niemand meer die het nog kan corrigeren.
Omdat de tafelschikking in het dossier op de gastenlijst is gebaseerd, hoef je die twee dingen niet handmatig gelijk te houden. Wie zich afmeldt via de trouwwebsite, staat als komt niet in de lijst, en de indeling weerspiegelt dat zonder dat je apart nog een schema moet bijwerken. Dat scheelt niet zozeer tijd, als wel een foutbron die je anders zelf in de gaten moet houden naast alles wat er verder nog gebeurt in de laatste maanden voor de bruiloft.
Er is ook een praktischer voordeel, dat vooral merkbaar wordt zodra de gastenlijst groter is dan een paar tientallen namen. Bij een lijst van vijftig man onthoud je nog wel ongeveer wie er zit en wie niet. Bij honderdtwintig man, verdeeld over twee families die elkaar niet allemaal kennen, is dat niet meer te overzien zonder iets dat de namen voor je bijhoudt. De tafelschikking wordt dan het middel waarmee je zicht houdt op wie waar zit, in plaats van iets dat je uit het hoofd moet reconstrueren telkens als er weer een wijziging binnenkomt.
De koppeling met de gastenlijst lost het probleem van twee losse lijsten op, maar niet het probleem van wie er naast wie moet zitten. Dat is een ander vraagstuk, en dat blijft mensenwerk. Een systeem kan bijhouden dat oom Wim en tante Sjaan als koppel op de lijst staan, maar niet dat zij liever niet naast je schoonfamilie zitten. Die kennis hebben alleen jullie, en die vul je zelf in.
Wat het systeem wel voor je scheelt, is het bijhouden van de basisgegevens waarop die keuzes steunen: wie er komt, wie er niet komt, en wie er nog moet reageren via de trouwwebsite. Als die drie categorieën kloppen, kun je de lastigere vraag over plaatsing rustig behandelen zonder dat je halverwege ontdekt dat de tafel waarvoor je net een mooie oplossing had gevonden, in werkelijkheid drie mensen te veel telt omdat er iemand is afgevallen die je nog had meegerekend.
De tafelschikking is niet iets waar je vroeg in de planning al aan hoeft te beginnen. Zolang de gastenlijst nog volop in beweging is, met veel namen op komt misschien, heeft een indeling weinig houvast; je zou hem binnen een maand alweer moeten herzien. Het heeft dan meer zin om eerst de lijst te laten uitkristalliseren, en de tafelschikking pas op te pakken als het merendeel van de reacties binnen is. Voor de meeste bruiloften is dat ergens in de laatste maanden voor de datum, wanneer de trouwwebsite het grootste deel van de aanmeldingen al heeft opgehaald en de stand komt niet of komt bij de meeste gasten vaststaat.
Wat ook kan wachten, is het uitwerken van een indeling tot in het kleinste detail, inclusief plaatskaartjes en tafelnummers, als de catering en de zaalopstelling nog niet vastliggen. De tafelschikking heeft een vorm nodig om in te passen: hoeveel tafels er zijn, en voor hoeveel mensen. Zonder die gegevens uit de andere blokken in het dossier ontwerp je een indeling die je daarna toch weer moet aanpassen aan de werkelijke opstelling. Het is dan zinniger om eerst die kaders vast te leggen, en de tafelschikking daarna in te vullen op basis van een gastenlijst die op dat moment ook grotendeels stabiel is.
De volgorde is dus: eerst de gastenlijst laten vollopen en bijhouden wie komt, dan de vorm van de zaal en het aantal tafels vastleggen, en pas daarna de tafelschikking invullen. Wie die volgorde omdraait, loopt het risico dat hij een indeling maakt op basis van gegevens die nog gaan veranderen, en dat werk dus dubbel doet.