Integrating AI Voice Agents with Restaurant Booking Systems

We built AI phone answering for restaurants that integrates with ResDiary, OpenTable, and POS systems. Here's a technical deep-dive on the integration challenges and how we solved them.

Why Restaurants?

Restaurants miss 20–30% of calls during peak hours. The phone rings hardest during service — exactly when nobody can answer. Classic scheduling conflict with a clear technical solution.

System Architecture

Caller → Telephony → ASR → NLU → Dialog Manager → TTS → Caller
                                        ↕
                              Booking System Adapter
                              ├── ResDiary API
                              ├── OpenTable API
                              ├── Custom POS
                              └── Calendar fallback

The Adapter Pattern

Every restaurant uses different tech. We abstracted booking operations behind a unified interface:

interface BookingProvider {
  checkAvailability(date: Date, partySize: number): Promise<Slot[]>;
  createReservation(slot: Slot, guest: GuestInfo): Promise<Reservation>;
  cancelReservation(id: string): Promise<void>;
  getMenuInfo(): Promise<MenuItem[]>;
  getAllergenInfo(itemId: string): Promise<Allergen[]>;
}

ResDiary has a solid REST API — straightforward integration. Real-time availability checks, reservation creation, and confirmation in one flow.

OpenTable requires OAuth and has rate limits that matter during peak hours (Friday 6-8pm = lots of simultaneous calls = lots of availability checks).

Custom/legacy systems — many restaurants use paper diaries or spreadsheets. For these we fall back to Google Calendar integration with a shared calendar.

Handling Concurrent Reservations

Peak hours mean multiple callers requesting the same time slots simultaneously. We use optimistic locking with the booking provider:

Check availability → show caller available slots
Caller picks a slot → attempt reservation
If slot taken between check and book → offer next best alternative
Retry up to 2 alternatives before escalating

For ResDiary, their API handles this natively. For calendar-based fallbacks, we maintain a short-lived lock (90s TTL in Redis).

Takeaway Order Flow

Takeaway is more complex than reservations — it's essentially building an order through voice:

Intent: order_takeaway
→ Menu navigation (categories → items → modifiers)
→ Cart management (add, remove, modify)
→ Order confirmation + total
→ Collection time estimation
→ Payment (redirect to payment link via SMS)

The upsell logic ("Would you like to add a dessert?") uses simple rules based on order composition and restaurant-configured suggestions. Not ML — just business rules that work.

Allergen Handling

Irish food allergen regulations require accurate information. We store allergen data per menu item and cross-reference during the conversation:

Caller: "Do you have anything gluten-free?"
→ Query: menu items WHERE allergens NOT CONTAINS 'gluten'
→ Response: "Yes, we have [items]. Would you like to order one of these?"

Zero tolerance for guessing. If allergen data is missing for an item, the AI says so and offers to connect to staff.

Multilingual Support

Tourist areas (Dublin, Galway, Cork) need multilingual handling. We detect language from the caller's first utterance and switch the entire dialog flow: