Handle inquiries and reservation requests

Start by identifying what the customer submitted. A contact inquiry, a table reservation and a booking for a bookable Product are different records. Do not use a table-reservation summary as a complete list of all bookings.

1. Choose the right view

Select the business in the dashboard and use its inbox to inspect customer submissions. Product bookings, including seats on a bookable offering, are handled in the dashboard inbox.

A connected assistant can read contact inquiries and table-reservation inquiries. Table reservations are site-wide by default, with an optional location filter and a recent-submission window of up to 90 days. That window refers to when requests were made, not necessarily the date the guest plans to visit.

2. Read before taking action

For contact inquiries, check the message, submission time and the customer's preferred contact details. For a table reservation, check the location, visit date and time, party size, requests and stored status. Read the individual record when making a decision; a total or status count is only a summary.

Do not infer a payment, a reply or a new confirmation from the presence of a record. Report the status the system actually returns.

Try with your connected assistant

Replace the example business, page and details with your own.

Review recent table reservations

For Harbor Studio, summarize table-reservation inquiries submitted in the last two days, grouped by location and stored status. Include visit dates and party sizes. Omit guest phone numbers and email addresses from the summary. Do not change records or contact anyone.

3. Respond through a supported channel

The KrabiClaw assistant connection reads these inquiries; it does not provide inquiry-reply or reservation-status mutation tools. You can ask it to draft a response for review, then use your normal customer-contact channel to send it. Do not treat a draft as a sent message or an assistant summary as a status change.

If an action is available in your dashboard, inspect the specific record and follow that action's confirmation and result. Keep a record of what you actually sent or changed instead of assuming the inbox and an external conversation update each other.

4. Check reservation availability and alerts

Table-reservation policies are location-specific. A location with no policy does not accept reservations; there is no fallback site-wide policy. To set up or amend a policy, first read the selected location's policy, choose the actual terms and check the resulting guest-facing summary. Do not fill unspecified terms with invented defaults.

Check your notification preferences separately. Seeing a request in the inbox does not prove every team member received an alert. If delivery seems wrong, inspect the request and personal notification settings before asking the guest to submit again.

Next: Update locations and hours.