Group & Function Enquiries

The problem this solves

Every restaurant and venue sets a limit on how big a party can book online. It's a sensible limit. A table for two to six people is a straightforward slot in your floor plan; a table for twenty, or a function room, is a different conversation entirely, one with logistics a booking form can't resolve on its own: which tables actually go together, what else is happening on the floor that night, whether the room is even free.

The usual fix is to turn the form off past a certain size and point the guest at a phone number or a separate enquiry email. That works, but it also means the guest leaves your booking page with nothing confirmed, and their enquiry lands somewhere your regular bookings don't, a different inbox, a different list, easy to lose track of next to everything else running that night.

Group & Function Enquiries keeps the guest on the same booking form and keeps their enquiry in the same place as every other booking. Above your limit, the form doesn't disappear, it changes what submitting it does.

Step 1: Receive

When a party above your limit fills in the public booking form, it doesn't try to confirm a table on the spot the way a normal booking does. Instead, it becomes an enquiry: their preferred dates and party size arrive as a message in the same inbox where your ordinary bookings already show up.

That matters day to day because you're not checking a second inbox, a separate enquiry form, or a phone message pad to find out a function request came in. It's sitting next to tonight's bookings, in the order it arrived, with the guest's own details attached to it from the start.

Step 2: Hold

Once you've read the enquiry, you reply to the guest in that same thread, the same back-and-forth you'd use to sort out any other detail with a customer. As part of that conversation, you hold the tables you're considering for their party.

Held tables come off public availability immediately. A guest browsing your booking page can't book a table you're holding for a function, the same protection a confirmed reservation gets. That's the point of this step: you can spend a few days going back and forth on dates, headcount and layout with the enquiring guest without worrying that the tables you're planning to offer them get booked out from under you by someone else browsing your site.

• The hold applies to the specific tables you pick, not a blanket block on the room
• It comes off availability the same way a confirmed booking does, so there's no separate 'hold' logic for guests to be confused by
• It stays in place while you and the guest work out final numbers, timing and any other detail in the thread

Step 3: Confirm

Once the details are settled, you pick the final tables and confirm the booking from inside the same thread. Nothing about the guest gets re-entered: the name, contact details, date and party size they gave you when the enquiry first arrived carry straight into the reservation.

That's the practical payoff of keeping the whole flow, receive, hold, confirm, in one conversation rather than splitting it across a form, an email chain, and a manual entry into your booking system later. What the guest told you once is what ends up on the booking. One conversation ends in one booking, on the same floor plan and in the same list as everything else you've got on that night.