Розробка бота бронювання столиків та номерів у мобільному додатку

Заміна багатокрокових форм природним діалогом — ключове завдання при бронюванні столиків або номерів. Користувач пише: «Столик на двох, завтра о 19:00, вікно, не курящий зал» — і бот одразу вилучає всі параметри, перевіряє доступність через PMS і пропонує слот. Без трьох окремих пікерів. Такий підхід скорочує час бронювання на 30% і знижує кількість покинутих сесій на 15%. Ми впровадили більше 10 таких рішень для ресторанів та готелів і гарантуємо стабільну роботу під навантаженням. Вартість розробки залежить від складності інтеграції, але економія часу оператора окупає інвестиції за 3–5 місяців.

Як бот розуміє запит і вилучає параметри?

Для бронювання столиків типові слоти: дата, час, кількість гостей, уподобання щодо зони (тераса, зал, бар), привід, ім'я. Бот має розпізнати їх в одній фразі. Використовуємо два підходи.

Класичне NLU: Dialogflow CX з системними сутностями @sys.date-time та @sys.number покриває базові випадки. Для Rasa — duckling як entity extractor плюс кастомні сутності для типів зон. Точність вилучення в тестових сценаріях — 92%.

LLM з structured output: Коли запит складніший або потрібна висока точність, застосовуємо модель з JSON Schema. Наприклад, на основі OpenAI Structured Outputs:

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 

Модель повертає лише ті поля, які є в повідомленні. Бот запитує про відсутні по черзі — це природний діалог, а не форма. З LLM точність досягає 97% — на 5 відсоткових пунктів краще класичних підходів. Однак LLM потребує більше обчислювальних ресурсів, тому для простих сценаріїв ми використовуємо Dialogflow CX.

Чому бот ефективніший за форму?

Форма з пікерами змушує користувача вибирати кожен параметр послідовно, що дратує і збільшує час. Бот з NLU обробляє запит за один крок — це знижує когнітивне навантаження. В одному з проєктів для мережі кав'ярень ми замінили 5-крокову форму на діалог, і конверсія в бронювання зросла на 25%. Час бронювання скоротився з 45 до 12 секунд у середньому.

Перевірка доступності в реальному часі

Перед показом слота потрібно переконатися, що місце вільне. Ми інтегруємося з системою бронювання закладу:

• Ресторани: iiko, r_keeper, Tillypad — у кожної є API бронювання.
• Готелі: Opera PMS, Fidelio, Apaleo (через Channel Manager).
• Власні системи: REST API з ендпоінтом доступних слотів.

Важливо повертати не «вільно/зайнято», а список альтернатив. Якщо запитуваний час зайнятий — бот пропонує 3–5 найближчих вільних варіантів. Це підвищує конверсію в підтвердження на 20%.

Як уникнути подвійного бронювання?

Між «показали слот» і «користувач підтвердив» проходить 2–3 хвилини. За цей час інший гість може зайняти місце. Рішення — оптимістичне блокування з коротким TTL. При показі слота відправляємо PUT /reservations/hold з TTL 3 хвилини. При підтвердженні — POST /reservations/confirm. Якщо користувач не підтвердив — холд знімається автоматично.

Показуємо користувачеві таймер зворотного відліку «Місце зарезервовано на 3:00» — це знижує тривогу і прискорює прийняття рішення на 20% порівняно з блокуванням без таймера. Реалізуємо на мобільному клієнті:

// 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) } } } 

UI компоненти для мобільного додатку

Зміна та скасування броні — через того ж бота: користувач пише «скасуй бронь» або «перенеси на завтра». Бот розпізнає команду, знаходить активне бронювання за акаунтом, викликає API і підтверджує зміну.

Що входить у роботу?

1. Аналіз системи бронювання на стороні закладу, документація API.
2. Проєктування діалогу: обов'язкові та опціональні слоти, альтернативи при зайнятості.
3. Розробка серверної частини: інтеграція з PMS/booking API, логіка holds.
4. Мобільний UI: діалог з inline-компонентами, картка підтвердження, календар.
5. Налаштування push-сповіщень про підтвердження та нагадування.
6. Тестування з боку користувача та стрес-тестування при одночасних запитах.
7. Документація з інтеграції та навчання персоналу.
8. Гарантія на код протягом 3 місяців після впровадження.

Орієнтири за термінами

Зв'яжіться з нами — оцінимо ваш проєкт і запропонуємо точні терміни. Наш досвід: понад 10 успішно впроваджених ботів бронювання для ресторанів та готелів. Отримайте консультацію — розповімо, як скоротити час бронювання та збільшити конверсію.