Замена многошаговых форм естественным диалогом — ключевая задача при бронировании столиков или номеров. Пользователь пишет: «Столик на двоих, завтра в 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 компоненты для мобильного приложения
| Компонент | Android | iOS |
|---|---|---|
| План зала (шахматка) | Canvas в Jetpack Compose |
UIBezierPath в SwiftUI или UIKit |
| Карточка подтверждения | MaterialCardView | SwiftUI Card |
| Календарь и временные слоты | Material Calendar | UIKit DatePicker или SwiftUI DatePicker |
| Добавление в календарь | CalendarContract API | EventKit API |
Изменение и отмена брони — через того же бота: пользователь пишет «отмени бронь» или «перенеси на завтра». Бот распознаёт команду, находит активное бронирование по аккаунту, вызывает API и подтверждает изменение.
Что входит в работу?
- Анализ системы бронирования на стороне заведения, документация API.
- Проектирование диалога: обязательные и опциональные слоты, альтернативы при занятости.
- Разработка серверной части: интеграция с PMS/booking API, логика holds.
- Мобильный UI: диалог с inline-компонентами, карточка подтверждения, календарь.
- Настройка push-уведомлений о подтверждении и напоминании.
- Тестирование со стороны пользователя и стресс-тестирование при одновременных запросах.
- Документация по интеграции и обучение персонала.
- Гарантия на код в течение 3 месяцев после внедрения.
Ориентиры по срокам
| Сложность | Срок |
|---|---|
| Базовый бот с готовым booking API, простой диалог | 1–2 недели |
| + Кастомная схема зала, сложная PMS-интеграция, уведомления | 3–5 недель |
Свяжитесь с нами — оценим ваш проект и предложим точные сроки. Наш опыт: более 10 успешно внедрённых ботов бронирования для ресторанов и отелей. Получите консультацию — расскажем, как сократить время бронирования и увеличить конверсию.