Start from the banquet hall model (free sign-up; running a simulation needs Pro). At a Japanese wedding, the reception desk opens about 30 minutes before the start: the guests hand over their gift of money and sign the guest book. When too few people run the desk at the busiest time, a queue forms in the foyer and the start is delayed. In this article, your AI writes the check-in before a mock wedding for 200 and compares the people at the desks, the difference between the two sides’ guests, and how the check-in is done. It ran the same tools an AI calls over MCP. Every figure and number below comes from that run.
1. The hall and the reception desks
The mock venue is a banquet hall for 200 with the foyer to its south. In the foyer the groom’s desk stands to the west and the bride’s to the east, each with a guest book table, a gift table, two chairs for the people at the desk and room to queue in front. Your AI reads the two desks (the guest book tables and their queues) and the hall door nearer each with get_space, and writes this scenario (put_process_scenario):
- The desks open 30 minutes before the start. The guests are about 200 in 140 parties, who come in through the entrance at random: 35 % in the first ten minutes, 45 % in the next ten and 20 % in the last ten (146.4 parties on average over the 20 runs).
- The groom’s guests queue at the groom’s desk, the bride’s at the bride’s.
- Two people run each desk, taking each party’s gift and signature in the guest book: 45 s a party on average (27 to 63 s).
- Checked in, a party goes into the hall by the nearer door.
- Twenty runs, with different random numbers.
The people at each desk, the groom’s share of the guests, the time a party takes, guest cards (sent with the invitation and filled in beforehand: half the time at the desk) and one desk for both sides (any free desk) are the scenario’s parameters. With sweep_process_parameters, your AI runs the same twenty random runs at each combination.
2. How long the guests wait today
With the guests split evenly and two at each desk, a party waits 2.1 min on average (95 % interval 1.7 to 2.5 min); the longest wait is 4.7 min at the groom’s desk and 5.0 at the bride’s, and the queue is up to about 14 parties. The last party is checked in 2.4 minutes after the start.
In the busiest ten minutes, about 31.5 parties come to each desk (3.15 a minute), but two people check in 2.67 parties a minute. The queue grows in those ten minutes and does not catch up before the start.
3. People at the desks, and one side with more guests
| People at a desk | Half each side: wait | Half each side: the last party | 65 % the groom’s: groom’s desk | 65 % the groom’s: bride’s desk | 65 % the groom’s: the last party |
|---|---|---|---|---|---|
| 1 | 14.9 min | 30.0 min after the start | 23.3 min | 6.8 min | 43.9 min after the start |
| 2 | 2.1 min | 2.4 min after the start | 5.2 min | 0.5 min | 8.0 min after the start |
| 3 | 0.3 min | 0.7 min after the start | 0.8 min | 0.1 min | 0.8 min after the start |
The wait is a party’s on average; the last party is when the last party is checked in (mean of 20 runs).
- One person at a desk is not enough: even with the guests split evenly, a party waits 14.9 min on average and check-in ends 30 minutes after the start.
- With 65 % of the guests the groom’s, even two at a desk leave the groom’s desk at 5.2 min on average, the longest wait 10.3 min and the queue up to about 27 parties, while the bride’s desk, at 0.5 min, stands idle at times.
- With three at each desk, even at 65 % the groom’s a party waits 0.8 min, and check-in ends 0.8 minutes after the start.
4. What helps when one side has more guests
Your AI copied the scenario with 65 % of the guests the groom’s and two at each desk (update_process_parameters with copyAs; the original stays as it is), and compared how check-in is done.
| 65 % the groom’s, two at a desk | Wait | Groom’s desk: longest wait | Groom’s desk: queue (longest) | The last party |
|---|---|---|---|---|
| As today | 3.7 min | 10.3 min | 27.4 | 8.0 min after the start |
| One desk for both sides | 1.6 min | 4.0 min | 11.1 | 1.4 min after the start |
| Guest cards | 0.1 min | 0.9 min | 5.2 | 0.3 min after the start |
| Both | 0.0 min | 0.3 min | 2.1 | 0.3 min after the start |
- With one desk for both sides (either desk will do), the wait is 2.0 min shorter (95 % interval 1.5 to 2.6 min), and the bride’s desk, idle before, is used too.
- Guest cards halve the time at the desk and make the wait 3.5 min shorter (95 % interval 2.8 to 4.3 min): shorter than with three at each desk (0.6 min), without more people.
5. The number of guests
| Guests | Wait | Longest wait | The last party |
|---|---|---|---|
| About 140 (100 parties) | 0.5 min | 1.9 min | 0.8 min after the start |
| About 200 (140 parties) | 2.1 min | 5.0 min | 2.4 min after the start |
| About 260 (180 parties) | 5.1 min | 9.8 min | 9.4 min after the start |
With the guests split evenly and two at each desk (105.9, 146.4 and 187.9 parties came on average over the 20 runs). The longest wait is the longer of the two desks’.
6. How to use these numbers
- The people needed at the desks depend on the guests, the difference between the two sides and how close together they come. Count each side’s parties from the guest list and give them to your AI. With the desks opening 30 minutes before the start, the parties in the busiest ten minutes are the guide.
- The time a party takes depends on handing over the gift and signing. Guest cards, or splitting the work at the desk (one takes the gifts, one guides the signing), make it shorter.
- Not calculated: showing guests to the cloakroom or waiting rooms, late guests, handing out travel money and thank-you gifts, the people at the desk taking turns.