> ## Documentation Index
> Fetch the complete documentation index at: https://docs.telzino.com/llms.txt
> Use this file to discover all available pages before exploring further.

# OpenTable Reservations

> Answer a restaurant’s calls, check real table availability on OpenTable, and text the caller a pre-filled booking link.

The **OpenTable Reservation Agent** is an agent template for restaurants that use OpenTable as their reservation system. It answers the phone, works out what the caller wants, checks whether a table is genuinely free, and texts the caller a pre-filled OpenTable link they tap to confirm.

It also answers questions about the restaurant, notes allergies and occasions for the team, and hands callers to a person when it should.

<Info>
  **The agent does not book the table.** Telzino is not an OpenTable partner, so no third party can write a reservation into OpenTable's book. The agent verifies availability and sends a deep link with the date, time and party size already filled in — the caller taps **Confirm** on OpenTable's own page. Nothing is held until they do, and the agent is instructed never to imply otherwise.
</Info>

## What the agent can do

<AccordionGroup>
  <Accordion title="Take a new reservation">
    Collects the date, time, party size and the caller's first name from ordinary speech — "tomorrow", "around 7", "four of us", "two adults and a baby". Everything is resolved in the restaurant's own timezone. It reads the details back once before checking availability, and a correction changes only the detail that was wrong rather than restarting.
  </Accordion>

  <Accordion title="Check real availability">
    Queries OpenTable through StayAPI for the exact time requested. If that time is free, it moves straight to sending the link. If the check errors or times out, the agent says the booking system is not responding and offers a handoff — it never guesses and never sends a link for a table nobody checked.
  </Accordion>

  <Accordion title="Offer alternatives">
    When the requested time is taken, the agent offers at most three nearby times in one sentence — "I don't have 7 o'clock, but I could do 6:45, 7:15, or 7:30." Times are ordered by how close they are to what was asked for, filtered to the restaurant's serving hours, and spoken in clock order. After two rounds it offers a different day or a callback instead of reading out the whole book.

    The agent can only send a link for a time that actually came back from OpenTable. If the model produces anything else, the send is refused.
  </Accordion>

  <Accordion title="Text the booking link">
    After asking permission ("OK to text the booking link to your phone? Standard message rates may apply."), the agent texts a pre-filled OpenTable link. It can send to the number the caller is ringing from, or another number they read out.

    Before sending, it checks the destination can actually receive a text. A landline gets "That looks like a landline — is there a mobile I should send it to instead?" rather than a message that silently never arrives.
  </Accordion>

  <Accordion title="Offer the waitlist on a full night">
    When a date is completely booked, the agent can text the restaurant's OpenTable page so the caller can join the waitlist or watch for a cancellation.

    OpenTable publishes no addressable waitlist URL, so this is the restaurant's own page rather than a waitlist entry. The agent is explicitly instructed to say so — it is not adding anyone to a list and cannot report a position on one.
  </Accordion>

  <Accordion title="Point callers at an existing booking">
    The agent cannot change or cancel a reservation. Asked to, it offers to text OpenTable's manage-reservation page, and tells the caller they will need to sign in with the phone number or email they booked with — the agent cannot pre-fill that.
  </Accordion>

  <Accordion title="Answer questions">
    Menu questions are answered from the restaurant's published OpenTable menu. General questions — parking, dress code, whether it is kid-friendly — are answered from the agent's [knowledge base](/functions/knowledge-base) when one is attached.
  </Accordion>

  <Accordion title="Note allergies and occasions">
    A mentioned allergy, dietary requirement, birthday or anniversary is recorded against the call for the restaurant to see.
  </Accordion>

  <Accordion title="Hand over to a person">
    Parties above the maximum, private-dining enquiries, complaints and anything the agent cannot handle are routed to a person, using the destination configured for that reason.
  </Accordion>
</AccordionGroup>

## What it deliberately does not do

<Warning>
  These are limits of what OpenTable exposes publicly, not gaps in configuration. The agent is built to be honest about each one rather than to guess.
</Warning>

| Limitation | What the agent does instead |
| - | - |
| Cannot write a booking into OpenTable | Sends a pre-filled link the caller confirms themselves |
| Cannot change or cancel an existing booking | Texts OpenTable's manage-reservation page |
| Cannot add anyone to a waitlist | Texts the restaurant's page, where a waitlist button may appear |
| Cannot attach an allergy or occasion to the OpenTable booking | Records it on the call for the restaurant, and tells the caller to mention it to their server on arrival |
| Cannot confirm a dish is vegan, vegetarian or gluten-free unless the menu says so in words | Says it is not sure and offers to connect the caller to the team |

<Info>
  **Why the dietary answer is cautious.** OpenTable publishes no dietary tags at all — a menu item carries a name, an optional description and a price. Across a sample of real menus fewer than half the items had any description. So the agent will only confirm a dietary property a menu states explicitly, and never infers one from ingredients. Someone asking whether a dish is vegan may have an allergy, and a confident guess is the one answer that could hurt them.
</Info>

## Before you start

<Steps>
  <Step title="The template must be enabled for your account">
    **OpenTable Reservation Agent** is governed by [Feature Administration](/admin-guide/dashboard/feature-administration), which can be set per Partner and per Reseller. It is **available by default** and has to be explicitly locked to hide it. Where it has been locked for your tenant, the template does not appear in the agent catalog at all — it is absent rather than greyed out.
  </Step>

  <Step title="The restaurant must be on OpenTable">
    You need the restaurant's OpenTable page address, e.g. `https://www.opentable.com/r/your-restaurant`. Open the restaurant's page on opentable.com and copy it from the browser.
  </Step>

  <Step title="Text messaging must be connected">
    The booking link is delivered by SMS, so the agent needs a text-message carrier connected on its **Integrations** page. For Twilio that is the organization's [Twilio connection](/integrations/twilio) (shared by all of its agents) plus this agent's own **From Number** in its Twilio SMS dialog. Without a carrier the agent still answers calls, checks availability and answers questions — but it will not offer to text anything, because it cannot.

    Which carrier it uses is not chosen per restaurant. Telzino supports **Twilio** and **NetSapiens**, and the one in force is shown read-only as **Text Message Carrier** in the restaurant settings.

    <Note>
      There is no screen for assigning a carrier yet. Until an assignment is made, **Text Message Carrier** reads *Not assigned* and the agent simply sends over whichever carrier is connected to it on the Integrations page — which is the right answer whenever only one is connected. An assignment can be written through the API as `sms_provider`.
    </Note>
  </Step>
</Steps>

## Creating the agent

<Steps>
  <Step title="Start a new agent">
    In the Connect app, create a new agent and choose **OpenTable Reservation Agent** from the template list.
  </Step>

  <Step title="Name the restaurant">
    This is how the agent refers to the restaurant on the phone and in the text message.
  </Step>

  <Step title="Paste the OpenTable page address">
    Telzino resolves it to the restaurant's OpenTable ID. If the address cannot be resolved you will see an inline error and can correct it.

    You can skip this and add it later, but **the agent cannot check availability until it is set** — it will answer calls and offer to take a message instead.
  </Step>

  <Step title="Set the greeting">
    How the agent answers the phone.
  </Step>
</Steps>

<Note>
  This template deliberately has no system-prompt field. The agent's conversation logic is generated from the restaurant's settings, so changing the hours or the party-size limits changes how the agent behaves on the very next call. A prompt typed by hand would be frozen at whatever the settings were the day it was written.
</Note>

## Settings

Open the agent and find the restaurant settings section.

<Note>
  These settings live in **both** apps, but not identically. **Look up**, **Text Message Wording** and **Text Message Carrier** exist only in the Connect editor. In the dashboard's Agent Settings you can edit the same values, but there is no resolver — editing the OpenTable page address there clears the restaurant ID and there is no way to resolve a new one, so do the initial link-up (and any address change) in Connect.
</Note>

### Restaurant identity

| Setting | What it does |
| - | - |
| **OpenTable Page** | Paste your restaurant's page address, then press **Look up**. Resolved to the OpenTable restaurant ID used for every availability check |
| **Restaurant Time Zone** | Every date and time the caller says is resolved in this timezone |

The restaurant's **name and location are not typed in** — they come back from the
lookup and are shown beneath the address once it resolves, along with the
neighbourhood, metro area and country. Those confirm you linked the right branch
when a chain has several with the same name.

<Warning>
  Editing the OpenTable page address clears the resolved restaurant ID, and it must be resolved again. Without this, an edited address would leave the agent checking the **previous** restaurant's availability and texting a link that books a table there.
</Warning>

### Hours

Set the serving windows for each day. A day with no window is treated as closed.

Windows that run past midnight are supported — a bar restaurant serving `17:00`–`01:00` is correctly treated as open at half past midnight.

Hours drive three behaviours:

* **After-hours greeting.** A caller reaching a closed restaurant is told so and offered a booking for another time, then the normal flow continues unchanged.
* **Last seating.** The agent will not offer a table after the kitchen closes.
* **Alternative times.** Slots outside the serving window are filtered out before anything is offered.

<Note>
  If you set no hours at all, the agent never tells a caller the restaurant is closed. An empty form is not evidence, and "we're closed right now" is a bad thing to say to someone standing outside an open door.
</Note>

### Reservation limits

| Setting | Default | What it does |
| - | - | - |
| **Party Size → Smallest** | 1 | Smaller parties are politely declined |
| **Party Size → Largest** | 8 | Larger parties skip the availability check and go to the events team |
| **How Far Ahead** | 60 | How far in advance the agent will book. Labelled **Days Ahead** in the dashboard |
| **Closed Dates** | none | One-off closures such as a holiday or a private event. One date per line, as `YYYY-MM-DD` |

These are enforced by the agent itself, not only by its instructions. A request that breaks one of them cannot produce a booking link, because a tappable link for a table the restaurant will not honour is worse than a refusal — the caller believes they have a booking and turns up.

### Text messages

| Setting | Default | What it does |
| - | - | - |
| **Check Mobile Numbers** | On | Runs a line-type lookup before sending, so a landline is caught while the caller is still on the line |

Turning the check off is a latency and UX preference. There is no cost to leaving it on — the lookup is funded by Telzino, not billed to your account.

### Handing over to a person

Transfers use your agent's ordinary **Transfer Rules**, the same field every agent
type uses — there is no separate setting for reservation agents. Write a rule per
situation and the agent follows it, so a complaint and a large party can reach
different people.

The situations worth writing a rule for:

| Situation | When it comes up |
| - | - |
| Anything else | The caller just asks for a person |
| Large party | A party above your maximum |
| Complaint | The caller asks for a manager, or complains |
| Private dining / events | A private-dining or event enquiry |
| Technical failure | The booking system is not responding |

<Warning>
  **With Transfer Rules empty, the agent will not offer a transfer at all.** It offers
  to take a message instead. Offering to put someone through with nowhere to send them
  strands them mid-sentence, so the agent is built not to.
</Warning>

You can also set an **events team number**, which the agent can *text* to a caller
rather than dial — R7.3's "I can connect you now, or text you their number."

### Put me through words

Say any of these and the agent offers a person immediately, without finishing what it
was doing. It defaults to *manager*, *complaint*, *sick*, *allergic reaction* and
*urgent*; set your own list to replace it.

Matching is on whole words, so "the dessert was sickeningly good" does not trigger a
transfer.

### Other settings

| Setting | Default | What it does |
| - | - | - |
| **Last seating** | 30 min | How long before closing the last table goes out |
| **Minimum notice** | 0 | How much warning you need, in hours |
| **"Dinner time" means** | 7:00 PM | What a vague time resolves to |
| **Children count** | Yes | Whether children count toward the party size |
| **When you can't take a booking** | — | What the agent says when a request breaks a rule |
| **After-hours greeting** | — | How it answers while you are closed |
| **Text Message Wording** | Standard | Which pre-approved message carries the link |
| **Text Message Carrier** | Not assigned | Read-only, and Connect only. Which carrier sends the text |

<Note>
  Message wording is chosen, not written. Carriers register sample content against your
  account, so the same copy has to be used across every restaurant — free-form editing
  would hold up delivery. You can see each template's exact text in the picker.
</Note>

## When a text cannot get through

If the caller has a landline and no mobile, withholds their number, declines the text, or the send keeps failing, the agent works down a ladder. It skips anything unavailable and never offers the same option twice.

<Steps>
  <Step title="Email the link">
    Offered only when **Offer to email the booking link instead** is switched on. The agent reads the address back before sending.
  </Step>

  <Step title="Ask the restaurant to call back">
    Offered only when **Offer to have the restaurant call them back** is switched on. The agent takes a number and roughly when suits, and saves the reservation details already collected alongside the request so whoever rings back is not starting from nothing. The landline they are calling from is fine for a callback, even though it could not take the text.
  </Step>

  <Step title="Transfer to the team">
    Offered only while the restaurant is open and Transfer Rules are configured.
  </Step>

  <Step title="Take a message">
    The last option, and the one that needs nothing configured.

    <Note>
      This rung is conversational only: the agent takes the details and they appear in the call transcript and summary. It does not yet create a voicemail, notify a **voicemail destination**, or record itself as its own outcome in the reservation report — so a call that ends here is counted as an abandoned call rather than a message taken.
    </Note>
  </Step>
</Steps>

## Seeing how it is doing

**Reports → Reservation Agent** in the dashboard shows what actually happened on the
calls: how many callers left with a way to book, where the rest dropped off, whether
the texts arrived, and how busy the OpenTable lookups were.

Two numbers there are worth understanding:

* **Booking rate** counts callers who left with a booking link — texted or emailed —
  or who took an alternative time. A call handed to a person is not counted, even
  though they may well have booked: the agent did not do it.
* **Text delivery** is measured over messages the carrier has resolved. Messages
  still in flight are shown separately rather than counted as failures.

A delivery failure rate above 5% raises a warning on that page. It usually means a
carrier is filtering the traffic rather than that anything is broken in the agent.

<Note>
  The failure rate counts both messages the carrier rejected on the way in and ones it
  accepted and then failed to deliver. NetSapiens does not report delivery receipts
  back to Telzino, so messages sent over NetSapiens stay in the "still in flight"
  column and no delivery rate is shown for them.
</Note>

The same figures are available over the API — see
[Reservation Analytics](/api-reference/reports/reservation-analytics).

## Frequently asked questions

<AccordionGroup>
  <Accordion title="Why did the caller not get a text?">
    Check the agent has a text-message carrier connected (**Text Message Carrier** in the restaurant settings shows which one), and check the delivery status recorded against the call. The most common causes are a number that cannot receive SMS and carrier filtering of unregistered A2P traffic.
  </Accordion>

  <Accordion title="The agent says it cannot check availability">
    The OpenTable page address has not been resolved to a restaurant ID. Re-open the agent's settings and resolve it.
  </Accordion>

  <Accordion title="Why does the agent not know our menu?">
    Around four in ten restaurants publish no structured menu on OpenTable — they link out to their own site instead. When there is no menu to read, the agent says it does not have it in front of it and offers to connect the caller to the team. It will not read a web address out or invent dishes. Put the details in the agent's [knowledge base](/functions/knowledge-base) to have them answered.
  </Accordion>

  <Accordion title="Can the agent take a deposit?">
    No. Payments are a separate capability — see [Taking payments over the phone](/functions/taking-payments-over-the-phone).
  </Accordion>

  <Accordion title="Does it work in languages other than English?">
    The template is English-only today.
  </Accordion>
</AccordionGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.