join_waitlist
Ask to be told if a table opens at a time the guest actually wants.
This is not a reservation and never becomes one by itself. The venue contacts the
guest if something frees up, so say that plainly rather than implying a table is
held.
Offer it whenever the guest cannot get a time that suits them, which is far more
often than a venue being completely full: someone who wants 7:30 and is offered
5:00 or 9:45 may well prefer to wait for 7:30. An empty get_availability is only
the most obvious case. Try other times, party sizes and dates first, then ask
whether they would rather wait than take a time that does not work. Record what
they wanted in `time_range`, not the time you found.
`date` is the venue's own local calendar date, `YYYY-MM-DD`. `time_range` is
required and is the window in the guest's words, like "7:00 PM - 9:00 PM" or
"7:00 PM"; ask the guest for it rather than guessing, because the venue works the
list by when people wanted to come. The email address is where the confirmation
goes, so it must be the guest's own.
Not every venue accepts these. One that does not refuses with a message saying so,
which is an answer, not an error to retry.
There is no reference number to give the guest, so the response is the only record
either of you gets. Confirm it back to them by the restaurant, date and time.
Mention the confirmation email only when `confirmation_sent` is true. When it is
false the request is still on the venue's list, the note simply did not go out, so
say they are on the list and that no email is coming rather than promising one.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| Yes | |||
| notes | No | ||
| phone | No | ||
| venue_id | Yes | ||
| last_name | Yes | ||
| first_name | Yes | ||
| party_size | Yes | ||
| time_range | Yes |