Table/Room Booking Bot in Mobile App
Booking via dialog competes with native selection forms. Forms are faster for users who know what they want. Dialog wins in scenarios with clarifications: "table for two, by window, non-smoking" — three parameters in one phrase, no three separate pickers.
Parsing Booking Requests
For table reservations, typical slots are: date, time, party size, zone preference (terrace, hall, bar), occasion, name.
Dialogflow CX with system entities @sys.date-time and @sys.number covers basics. For Rasa — duckling as entity extractor plus custom entities for zone types.
With LLM — structured output via JSON Schema:
from openai import OpenAI
from pydantic import BaseModel
class BookingSlots(BaseModel):
date: str | None = None # ISO 8601
time: str | None = None # HH:MM
party_size: int | None = None
zone_preference: str | None = None
guest_name: str | None = None
occasion: str | None = None
response = await client.beta.chat.completions.parse(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "Extract booking parameters from user text."},
{"role": "user", "content": user_message}
],
response_format=BookingSlots
)
slots = response.choices[0].message.parsed
The model returns only fields present in the message. The bot asks for missing ones sequentially.
Real-Time Availability Check
Before offering a slot — query the booking management system:
- Restaurants: iiko, r_keeper, Tillypad have booking APIs
- Hotels: Opera PMS, Fidelio, Apaleo (via Channel Manager)
- Custom systems: REST API with available slots endpoint
Important: return not just "free/occupied" but a list of available options with alternatives. If requested time is occupied — bot suggests nearest available.
Double-Booking Problem
Between "showed slot" and "user confirms" can be 2–3 minutes. Another user might book in the meantime.
Solution: optimistic locking with short TTL. On slot display — PUT /reservations/hold with 3-minute TTL. On confirm — POST /reservations/confirm. If user doesn't confirm — hold expires automatically.
// Android: countdown timer while holding slot
class BookingViewModel : ViewModel() {
private var holdExpiresAt: Long = 0
fun startHoldCountdown(ttlSeconds: Int) {
holdExpiresAt = System.currentTimeMillis() + ttlSeconds * 1000L
viewModelScope.launch {
while (System.currentTimeMillis() < holdExpiresAt) {
val remaining = (holdExpiresAt - System.currentTimeMillis()) / 1000
_holdCountdown.emit(remaining)
delay(1000)
}
_holdExpired.emit(Unit)
}
}
}
User sees a countdown "Slot reserved for 3:00" — reduces anxiety and speeds up decision-making.
Booking UI
Table grid — optional for restaurants: show floor plan, occupied and free tables. Implemented via custom Canvas on Android or UIBezierPath on iOS, or SVG floor plan in WebView.
Confirmation card — large: date, time, party size, name. "Add to calendar" button — EventKit on iOS, CalendarContract on Android.
Changes and cancellations — via the same bot: "cancel reservation", "move to tomorrow". Bot recognizes command, finds active booking by account, calls API.
Development Process
Analyzing the venue's booking system, API documentation.
Designing dialog: mandatory and optional slots, alternatives if occupied.
Server side: integrating with PMS/booking API, holds logic.
Mobile UI: dialog with inline components, confirmation card.
Timeline Estimates
Bot with ready booking API, basic dialog, mobile client — 1–2 weeks. With custom floor plan, complex PMS integration, notifications — 3–5 weeks.