Бот бронювання столиків/номерів у мобільному додатку
Бронювання через діалог — це конкуренція з нативною формою вибору. Форма швидша для користувача, який знає, що хоче. Діалог перемагає у сценаріях з уточненнями: «столик на двох, біля вікна, зал для не курців» — три параметри в одній фразі, без трьох окремих пікерів.
Розбір запиту на бронювання
Для бронювання столиків типові слоти: дата, час, кількість гостей, уподобання за зоною (тераса, зал, бар), повід, імя.
Dialogflow CX з системними сутностями @sys.date-time та @sys.number охоплює базові випадки. Для Rasa — duckling як entity extractor плюс кастомні сутності для типів зон.
Якщо використовуєте LLM — структурований вихід через 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": "Витяг параметри бронювання з тексту користувача."},
{"role": "user", "content": user_message}
],
response_format=BookingSlots
)
slots = response.choices[0].message.parsed
Модель повертає тільки поля, які є в повідомленні. Бот запитує про відсутні по черзі.
Перевірка наявності в реальному часі
Перед пропозицією слоту — запит до системи управління бронюванням:
- Ресторани: iiko, r_keeper, Tillypad мають API бронювання
- Готелі: Opera PMS, Fidelio, Apaleo (через Channel Manager)
- Власні системи: REST API з endpoint доступних слотів
Важливо повертати не тільки «вільно/займайте», але список доступних варіантів з альтернативами. Якщо запрошений час займайте — бот пропонує найближчі вільні.
Проблема подвійного бронювання
Між «показали слот» та «користувач підтвердив» може пройти 2–3 хвилини. За цей час інший користувач може займайте місце.
Рішення: оптимістична блокування з коротким TTL. При показі слоту — PUT /reservations/hold з TTL 3 хвилини. При підтвердженні — POST /reservations/confirm. Якщо користувач не підтвердив — hold знімається автоматично.
// Android: таймер зворотного відліку поки тримаємо слот
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)
}
}
}
Користувач бачить зворотний відлік «Місце зарезервовано на 3:00» — це зменшує тривогу та прискорює прийняття рішення.
UI для бронювання
Шахматка столиків — опціональний компонент для ресторана: показуємо план залу, займайте та вільні столики. Реалізується через кастомний Canvas на Android або UIBezierPath на iOS, або через SVG-схему залу в WebView.
Карточка підтвердження — крупно: дата, час, кількість гостей, імя. Кнопка «Додати в календар» — EventKit на iOS, CalendarContract на Android.
Зміна та скасування — через того ж бота: «скасувати бронь», «перенести на завтра». Бот розпізнає команду, знаходить активне бронювання за аккаунтом, викликає API.
Процес розробки
Аналіз системи бронювання на стороні закладу, документація API.
Проектування діалогу: обов'язкові та опціональні слоти, альтернативи при зайнятості.
Серверна частина: інтеграція з PMS/booking API, логіка holds.
Мобільний UI: діалог з inline-компонентами, карточка підтвердження.
Орієнтири за часом
Бот з готовим booking API, базовим діалогом та мобільним клієнтом — 1–2 тижні. З кастомною схемою залу, складною PMS-інтеграцією та сповіщеннями — 3–5 тижнів.