Реализация бота для бронирования столиков/номеров в мобильном приложении
Бронирование через диалог — это конкуренция с нативной формой выбора. Форма быстрее для пользователя, который знает, что хочет. Диалог выигрывает в сценариях с уточнениями: «столик на двоих, окно, не курящий зал» — три параметра за одну фразу, без трёх отдельных пикеров.
Разбор запроса на бронирование
Для бронирования столиков типичные слоты: дата, время, количество гостей, предпочтения по зоне (терраса, зал, бар), повод, имя.
Dialogflow CX с системными сущностями @sys.date-time и @sys.number покрывает базовые случаи. Для Rasa — duckling как entity extractor плюс кастомные сущности для типов зон.
Если используете LLM — structured output через 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 с эндпоинтом доступных слотов
Важно возвращать не «свободно/занято», а список доступных вариантов с альтернативами. Если запрошенное время занято — бот предлагает ближайшие свободные.
Проблема двойного бронирования
Между «показали слот» и «пользователь подтвердил» может пройти 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 недель.