Voice agents for restaurants: inquiries and booking requests

Restaurant service: hours, menu and approved information

Prepare current sources identifying the location, hours, address, channels and menu information approved by staff. Table or item availability needs current information from the responsible process. For dietary restrictions, follow restaurant-approved guidance and refer unsupported questions; general descriptions do not justify guarantees about ingredients or preparation.

Dietary questions need specifically approved information. General menu descriptions cannot guarantee ingredients or preparation.

Query availability through a defined operation

With an available API, configure date, time and party-size inputs. Explain tool timing and unavailable-slot responses.

Lookups return options; booking is a separate action. Found slots do not establish completed reservations.

Confirm details before recording

Confirm booking details and use configured operations where available. Inspect responses before announcing confirmation or identifiers.

Without booking integration, record team requests and explain continuation. This example assumes no native restaurant-platform connector.

Test changes and out-of-scope requests

Validate larger parties, corrected dates, unavailable systems and repeated requests. Define team routing and verify receipt.

Changes and cancellations depend on destination operations and rules. Verify each response before confirming that a reservation was changed or cancelled.

Confirm reservations, party size and occasion

For a fictional table of six on Saturday night, confirm complete date, time and branch. Present tool-returned options and wait for confirmed creation before announcing a reservation.

Without integration, record a pending request. Special arrangements remain preferences when staff review is required.

Test party-size changes, lateness, cancellation and no availability. Empty results require alternatives, not invented tables. External systems should prevent duplicate reservations.

Choose a scope matching dining operations

List contact reasons the restaurant can handle using approved information. Addresses, hours, reservation policies and access may provide a useful starting point. Requests depending on the kitchen, current capacity or managerial decisions require another source or staff participation. The scope should match real service capabilities rather than every question callers might ask.

For multiple branches, identify differences between locations. Correct guidance downtown may be wrong in another neighborhood. Agents should ask which branch when that changes advice instead of silently choosing the best-known location. Include location-specific service hours and booking rules in the approved source.

Separate information from transactions. Describing reservations does not create tables, and explaining menus does not register orders. Integrations must exist and confirm outcomes before conversations announce completed actions. If the available process only collects preferences, keep that pending status visible in the caller-facing explanation.

Define subjects excluded from the first pilot too. Staff may begin with common questions and preference collection before supporting reservation changes. Explicit scope helps receiving staff understand completed work and unresolved needs. Review questions that frequently fall outside the scope, then decide whether they warrant expansion or a clearer alternative rather than gradually allowing unsupported commitments through conversational improvisation.

Keep menus and conditions tied to the right source

Menus should identify branch, period and relevant conditions. Dishes promoted for events may not be served daily. General restaurant information does not establish inventory, current composition or availability that evening. Keep time-sensitive operational facts separate from descriptive information that changes less frequently.

Use material approved by operations and assign responsibility for changes. Questions about specific ingredients should follow the restaurant's verification procedure. Agents must not infer dietary suitability from dish names or incomplete descriptions. Source gaps should lead to appropriate verification, not a confident assumption based on what similar dishes usually contain.

In a fictional example, someone asks whether a preparation can be adapted. Sources may explain how to request kitchen review. That differs from guaranteeing adaptation or suitability for a particular need. Record preferences according to approved procedures while preserving the distinction between a request and an accepted arrangement.

Test answers requiring conditions as well as dish names. Check that agents preserve qualifications and recognize missing information. Fluent descriptions lose usefulness when they erase the difference between normally offered options and confirmed availability. Include outdated event descriptions and branch differences in review so material from one service does not silently become general guidance for every caller.

Confirm what each booking stage means

Reservations require complete dates, times, branches and party sizes according to existing processes. Saying “Saturday” can leave ambiguity about the intended week. Agents should clarify before querying or recording anything dependent on that date. Confirm only fields needed for the next decision, keeping conversation manageable.

In a fictional case, someone requests a table for six and then increases the party to eight. Earlier availability may no longer apply. Subsequent queries must use current party size, and responses should not preserve the first option as if nothing changed. Inspect submitted parameters as well as spoken acknowledgment of the correction.

Distinguish found options, selected preferences and recorded reservations. Announce confirmation only after the corresponding result. If responses are lost following attempts, integrations should support state verification before repeating creation and risking duplicates. A conversational apology does not establish whether a reservation exists in the external system.

Specific tables, decorations and events require their own conditions. Record them as preferences when approval is needed. Wording should indicate exactly what the restaurant accepted, preventing friendly comments from becoming operational guarantees. Review final records against caller expectations so a confirmed ordinary table is not interpreted as confirmation of every special arrangement mentioned during the call.

Prepare for changes, lateness and no availability

Real conversations involve more than new reservations. Callers may ask about lateness, cancel, change times or correct party size. Each action depends on policy and configured operations, not merely instructions accepting requests. Assess whether current integrations support each action before including it in the agent's scope.

If integrations cannot modify reservations, explain authorized alternatives and preserve requests as pending where records exist. Do not claim original bookings were canceled or changed without confirmed results. Apply required identification so changes cannot affect another person's booking. Familiarity with a name or date alone may not satisfy the restaurant's approved process.

When no availability exists, present only alternatives actually offered. Nearby times may sound reasonable while being absent from calendars. If callers prefer staff review, define how those requests enter the team's process. Avoid promising accommodation merely because a request has been recorded politely.

Test exceptions using controlled data and different operating periods. Include closure, special events and preference changes during conversations. Expected outcomes should describe both reservation state and correct caller-facing guidance. Test failed operations too: refusals and unavailable systems should not be translated into successful changes, and repeated attempts should not create multiple bookings or contradictory records.

Make requests usable by staff during service

Staff need to find requests without depending on whoever built the pilot. Define where records appear, who monitors them and which details enable action. During busy periods, isolated notifications may be insufficient for continuity. Validate the receiving process with people actually working service rather than assuming delivery equals operational use.

Use reduced records containing branch, service, date, time, party size and unresolved conditions where needed. Include contact through authorized procedures. Do not copy irrelevant personal details simply because they appeared in conversation. Current corrected values should replace earlier preferences in the actionable description without obscuring which arrangements remain unapproved.

In a fictional case, group requests require managerial review. Staff must distinguish received preferences from approved events. Agents should use the same distinction when speaking to callers so people do not plan occasions as confirmed. Define who communicates decisions and through which available channel before offering a follow-up expectation.

Where transfer exists, verify telephony and expectations. Direct transfer in Tigy does not automatically carry context. Restaurant summaries require separate verified mechanisms. Test whether staff can find those records and whether they match current requests. Record transfer and information delivery separately because either can succeed while the other fails, leaving the caller or restaurant without the expected continuity.

Evaluate outcomes by request type and service period

Separate answered questions, confirmed reservations and pending requests. Asking for tables does not establish creation, and ended conversations do not establish resolved needs. Verify records and caller-facing guidance. Outcome definitions should let different reviewers classify the same interaction consistently.

Compare peak hours with quieter periods. Dining capacity and staff availability influence results. If many requests remain pending because no tables exist, review should recognize that cause rather than attributing everything to the agent. Compare similar request types before interpreting differences as improved conversational performance.

Include corrections, duplicates, missing requests and repeat contacts. These reveal rework absent from counts of received calls. Review concrete cases to determine whether problems involve questions, sources, tools or staff reception. A correctly collected request can still fail when nobody owns its follow-up, while a clear process can still be undermined by incorrect dates.

Expand after validating scope and exceptions. Adding events or changes introduces decisions and maintenance. Agents should grow according to the operation's ability to sustain reliable answers and actions, with owners updating relevant rules. Keep established booking cases in later evaluation so new capabilities do not degrade the simple requests that originally justified the pilot. Telephone availability alone should never be presented as a guarantee that a table or special arrangement can always be provided.