Restaurant call centers: a central reservation desk checklist

Before a central team takes reservation calls for several restaurants, agree on three things: which venues it can book, which changes need local approval, and who follows up when the request stays open. Start with a small set of venues and shifts, then check the saved reservations and handoffs before expanding coverage.

This guide covers a staffed reservation desk for a restaurant group. For where calls should ring, use the multi-location phone routing checklist. For questions about existing orders, refunds or complaints, use the staff handoff checklist. Here the task is deciding what a central reservation team may do inside each venue's booking process.

What needs to be shared across the group?

A shared phone number does not settle booking access. Write down each venue's booking system, service hours, time zone, party-size rules and local contact. Give the desk a way to find the current record and an agreed route for questions it cannot settle.

SevenRooms provides one example of software built for this work. Its restaurant group tools describe central reservation teams using global search and live availability, with user permissions for cross-team access and approvals. Its account setup guide separates role permissions, internal and online availability, reservation charges and guest messages. Those descriptions do not establish which actions your staff can take on your account. Confirm the settings with the provider and each venue manager.

Keep guest-profile access in that review too. Someone who can book a table may not need every note or report across the group. Our restaurant CRM guide covers the choice of guest records; the worksheet below covers the desk's day-to-day authority.

Fill in a venue-by-role worksheet

Use one copy per venue. The entries below are proposed questions for your managers and provider, not default permissions in SevenRooms or another system. Replace each blank with a named role, a rule and the place where staff can check it.

Decision	Write down before launch	Check with a test account
View and book	Venues, service periods and bookable party sizes: ____	The desk sees the intended venue and can save only an allowed booking.
Change a reservation	Which date, time or party-size changes the desk may make: ____	A permitted change reaches the correct record and guest message.
Make an exception	Who approves a full shift, special seating request or party beyond the normal limit: ____	The desk sends a request without promising a table before approval.
Change a charge	Who decides deposits, cancellation fees, waivers and refunds: ____	Access and staff procedure match the written rule; no live charge is needed for the check.
Follow up	Local recipient, backup contact and agreed response time: ____	An unresolved request has an owner and a next action.
End access	Who removes a departing team member's account: ____	Removed access no longer opens the venue's records.

Where the software cannot enforce a rule, mark that limit and agree on a manual check. Do not treat a visible button as approval to use it. Ask the provider to show the actual account settings before the desk handles live guests.

Separate a booking from a request awaiting approval

Give the team a simple status list: confirmed in the booking system, awaiting local approval, guest follow-up needed, or closed with a recorded result. Choose names that fit your system. A note or a transferred call alone should not count as a confirmed reservation.

For each request, record the venue, requested date and time, party size, contact route, action already taken and next responsible person. Use the restaurant's approved system and data-access rules. Check for an existing reservation before making another one, and avoid copying guest details into a separate shared sheet unless that use is approved.

For example, a caller asks to move a party of six to a full Friday shift. The desk finds the existing booking, records the request and asks the authorized local role. It tells the guest that approval is pending. Only after approval and a saved change should it confirm the new arrangement. This is a proposed workflow, not a result from a restaurant trial.

Plan for busy shifts and an unavailable venue

Decide what the desk does when the local contact does not answer. Set a backup recipient, a follow-up deadline and the words staff should use with the guest. If availability cannot be checked, take a request rather than offer an unverified table. Confirm who reviews open requests at the end of the shift.

Keep phone-queue settings separate from booking permissions. A queue can distribute calls to staff, but your booking rules still need to define the decisions those staff may make. Test the path from the original venue number through the desk and back to the local team, using the routing checklist above.

Run these checks before adding more venues

Use test accounts and agreed test records with the provider where available. Do not charge a guest or occupy live tables merely to test a workflow.

1. Correct venue: ask for two similarly named locations. Check the address, time zone and saved venue each time.
2. Ordinary booking: save an allowed reservation, then have the local host find it and check the guest confirmation.
3. Existing booking: request a change and confirm the team updates the intended record without creating a duplicate.
4. Exception: request a party size or time outside the desk's authority. Check the approval recipient and keep the guest's status pending.
5. Unavailable contact: make the primary local contact unavailable in the test. Check the backup path and follow-up owner.
6. Access limit: try a venue or action outside the test role's scope. Record whether the system blocks it or the process needs another control.

Measure the desk's work without counting transfers as results

For a stated set of shifts, count requests received, confirmed reservations checked against saved records, changes checked against the original booking, requests still open and duplicates or wrong-venue records found. Keep ordinary bookings and exceptions separate. Record unknown results as unknown.

Also record staff time spent on calls and follow-up using the same method before and during the trial. An answered call, short call or call without transfer does not by itself show a completed reservation or time saved. Our call-volume worksheet helps keep call attempts separate from people and outcomes.

Choose the next step from those checks: expand the venues that have clear permissions and reliable handoffs, correct a failed case, or keep the current scope while open requests remain unresolved. Set your acceptance rules before the trial; this guide does not supply a universal performance target.

Published by Maple. This AI-assisted guide uses SevenRooms' public group-management and account-setup documentation with an original permission worksheet and proposed tests. It reports no restaurant trial, customer result or Maple integration with a central reservation desk. Confirm account features and local authority with your provider and managers.