A booking begins as a particular request
A guest asks for a table for four at 7 pm on Friday. Reception still needs to work out which table really fits. Area, table size, expected visit length and other groups all matter. Bonzumo connects reservations with the floor plan and guest context. The team can consider a request against actual occupancy. The online contact and booking paths available to your website and venue should be agreed for the specific setup rather than assumed.
Set time and capacity rules before launch
A reservation uses space for an expected period, not just one point in time. Set realistic time slots, buffers and area rules for your business. A small café has a different pace from a restaurant serving several courses. Bonzumo provides settings for areas, tables, capacity, times and rules. Base them on observations from real service. Tight buffers may look attractive in a booking form but cause delays on a busy evening.
Let reception and service read the same plan
A booking changed by phone should not remain on an old note while servers prepare a different table. Decide who records changes and how the updated occupancy becomes visible. Bonzumo brings the reservation overview and floor plan together. During training, one colleague can accept the request and another welcome the guests. Both should be able to explain the same plan without an extra personal spreadsheet or a message that only one person saw.
Use guest details sparingly and purposefully
Name, time and party size are usually central to a booking. Additional details should be recorded only if they serve a practical purpose and can be handled appropriately. A request for a quiet seat may be useful; a long collection of private facts is rarely needed. Decide which roles may read a note and when it should no longer be retained. Bonzumo offers guest context, but data protection choices depend on your venue and its actual use.
Treat changes as ordinary service work
Guests arrive late, a party becomes smaller or a table stays occupied longer. A useful booking process leaves room to respond. Before moving a group, check the other bookings in the area and explain any new promise clearly. The floor plan should once again match what the team has agreed with the guests. This case is more revealing in a demo than a list of perfectly punctual bookings. It shows whether reception and service still share one view after a change.
Play through the entire journey in a demo
Begin with an anonymous online request for four, add a second party and a walk-in, then change an arrival time. Ask the team to explain the selected table and the alternative if the guests are late. Continue through welcome and handover to service. This tests more than a booking form. It shows the benefit to your guests: a reliable promise and a calmer start to their visit.
Change a party size without creating conflicting promises
A party booked for six calls two hours before arrival: eight people will now attend. The original table assignment may no longer fit. First check which tables are truly available for the requested period, whether a larger place remains free and which later bookings might be affected. Then offer a new clear promise or an honest alternative. Update the shared reservation with the new party size so reception and service do not work from two versions of the same booking.
When the guests arrive, another colleague should understand the change without a separate account of the phone call. They can see the current party size, agreed area and any note needed for the visit. If only seven people actually turn up, review the real occupancy again. A reservation view is not a rigid prediction for every minute; it is a working basis for decisions. Bonzumo connects the booking and floor plan at the point where those decisions pass between the entrance and service.
In a demo, combine this change with another booking at a nearby table. Ask two colleagues independently why the revised place fits and what limit remains for the next group. This reveals whether configured capacity matches the real room and whether changes travel through the team without creating duplicate assignments. An online request has delivered its value only when the actual reception team finds the same current plan.
Include the current table status in that explanation. A booking that looks available on a timetable may still depend on guests finishing, a table being reset and a server being ready to welcome the next group. Showing each step helps the manager choose realistic booking buffers.