Разработка бота бронирования столиков и номеров в мобильном приложении

Замена многошаговых форм естественным диалогом — ключевая задача при бронировании столиков или номеров. Пользователь пишет: «Столик на двоих, завтра в 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 успешно внедрённых ботов бронирования для ресторанов и отелей. Получите консультацию — расскажем, как сократить время бронирования и увеличить конверсию.