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

Почему мобильное приложение для ресторана теряет брони столов

Сценарий гостя в приложении для бронирования столов короткий: выбрать дату, число гостей, время — и получить подтверждение брони. Ломается он ровно в одном месте. Гость доходит до выбора времени, видит сетку интервалов, тратит 30-40 секунд на раздумья — и закрывает приложение, потому что следующий шаг превращается в переписку с менеджером.

Дальше и начинается потеря брони. Форма отправляет заявку, но подтверждение брони приходит не сразу, а после того, как сотрудник посмотрит зал и напишет или позвонит. Пока гость ждёт ответа, он открывает карты (Google Maps) или агрегатор и бронирует там же за пару минут. Приложение получило отказ не из-за интерфейса, а потому что не довело сценарий гостя до конца.

Вторая причина — занятость столов. Если приложение обменивается с кассой не мгновенно, а по расписанию, сетка интервалов показывает данные давностью в несколько минут и врёт в обе стороны: свободный стол выглядит занятым, занятый — свободным. Первое даёт потерянные брони, второе — скандал у входа, когда двое гостей приходят на один стол в одно время.

Цена ошибки накапливается тихо. Гость, который не забронировал сегодня, помечает это как «приложение не работает» и возвращается к звонку — а звонок уводит брони из системы, где их видно и по ним можно планировать загрузку зала.

Разбираем, как это закрывается: подтверждением брони по правилам ресторана за секунды, честной занятостью столов и сценарием, который гость проходит без ожидания.

Что меняется после запуска: скорость брони и загрузка зала

Скорость брони измеряется не откликом приложения, а путём до подтверждённой брони. При звонке этот путь состоит из дозвона, уточнения свободных слотов, ожидания перезвона и ручной записи в журнал — часть таких обращений теряется на стыке «свободно — занято». В приложении гость выбирает зал, дату и число гостей, остаток посадки пересчитывается автоматически, и подтверждение приходит сразу, без участия хостес.

Загрузка зала растёт не за счёт рекламы, а за счёт перераспределения мест. Слоты привязаны к реальной посадке и стоп-листу, поэтому отменённая бронь мгновенно возвращается в доступ и её видит следующий гость. Зал перестаёт простаивать на стыках между посадками, а пиковые часы закрываются депозитом или предзаказом — стол занимают те, кто придёт.

С неявками гостей борется не штраф, а управление жизненным циклом брони. Напоминание накануне и подтверждение в день визита, депозит для крупных компаний, авто-освобождение стола, если гость не пришёл за отведённое время, — доля броней «в никуда» падает, а хостес видит, кто подтвердил, и не держит стол под молчащего гостя.

Повторные визиты держатся на истории. Приложение помнит любимый стол, средний чек и повод прошлого визита, поэтому возврат к дате уходит персональным предложением, а не общей рассылкой. Интеграция с iiko подтягивает посадку и историю из учётной системы ресторана: одна база вместо журнала, таблицы и переписки в мессенджере.

Все эти эффекты — следствие одной связки: бронь, посадка и гость живут в одних данных, а не в трёх учётных контурах.

Три пути: единое ядро, нативная сборка, коробочное решение

Выбор подхода определяется не вкусом, а долей платформенной логики в сценарии. Бронирование — это карта с точками, уведомление о подтверждении, предоплата за стол, календарь и напоминание за час до визита: чем больше таких узлов, тем сильнее расходятся варианты. Ниже — три альтернативы, между которыми выбирают на практике.

Разница проявляется не на старте, а на втором-третьем сезоне. У единого ядра 70–80% кода общее, и правка правил брони выходит один раз; у нативных сборок — дважды; у готового решения — в порядке очереди поставщика. Поэтому мы сначала считаем долю платформенных узлов и число внешних интеграций (касса, программа лояльности, карты), и только потом называем подход.

Как идёт работа: от разбора сценариев до передачи проекта

Начинаем не с макетов, а с того, как зал живёт в смену: где пик, сколько посадок в час, кто подтверждает бронь и что делать, когда гость не пришёл. От этой картины зависит схема брони — держим ли стол за конкретным официантом, работает ли автоподтверждение, как учитываются депозиты и большие компании.

1. Аудит процессов зала. Разбираем источники броней — звонки, сайт, агрегаторы, — правила отмены, депозиты и рассадку больших компаний. На выходе карта сценариев и перечень узких мест.
2. Прототип брони. Кликабельный прототип выбора зала, стола, времени и числа гостей проверяем на хосте и администраторе до написания кода: правки здесь занимают часы, после релиза — недели.
3. Схема данных и связки. Определяем, какие столы можно объединять, как бронь синхронизируется с учётной системой зала и что происходит при двух запросах на один стол одновременно.
4. Сборка. Итерации по одной-двум неделям, на каждой — рабочая сборка. Заказчик смотрит на живое приложение, а не на отчёт о готовности.
5. Тестирование сценариев под нагрузкой. Прогоняем пиковый вечер и праздничные дни: сотни одновременных запросов, обрывы сети, повторные нажатия. Проверяем, не уходит ли один стол двум гостям.
6. Ввод в эксплуатацию. Запускаем параллельно с привычным порядком: часть броней идёт через приложение, часть — как раньше. Смотрим заполняемость и время подтверждения брони.
7. Передача проекта. Отдаём доступы, документацию по схеме брони и инструкции для смены, настраиваем оповещения о сбоях. Дальше — поддержка и развитие.

Передача проекта: схемы интеграций, доступы, регламенты поддержки

Передача приложения — это не архив с исходным кодом, а комплект, по которому ваша команда или сторонний подрядчик поднимет сборку, выпустит обновление и разберёт инцидент без нашей помощи. Мы собираем его по ходу проекта: часть артефактов рождается вместе с интеграциями, часть — на этапе опытной эксплуатации, когда видно реальное поведение брони под нагрузкой.

• Документация на приложение: карта экранов и сценариев брони, описание модулей, точек расширения и того, какие данные считаются источником истины при расхождении клиента и сервера.
• Схемы интеграций: потоки с системой брони, кассовым контуром, эквайрингом и фискализацией — где именно подтверждается бронь, в какой момент проходит оплата, какие поля обязательны и что происходит при отказе каждого узла.
• Права доступа сотрудников: матрица ролей в панели администратора, репозитории, сервисах уведомлений, аккаунтах магазинов приложений и внешних сервисов — с указанием владельца каждого доступа, а не общей учётной записи.
• Регламент поддержки: приоритеты обращений, время первой реакции, порядок эскалации, ответственные на стороне ресторана и наши контакты для каждого класса инцидентов.
• Регламент выпуска обновлений: правила работы с ветками, обязательные проверки перед сборкой, порядок публикации и откат на предыдущую версию, если обновление ломает сценарий брони.
• Инструкции для персонала: как менять меню и часы работы, настраивать лимиты и интервалы посадки, снимать зависшие брони и что делать, если гость не получил подтверждение.
• Перечень внешних сервисов и их настроек: карта зависимостей с указанием, что критично для приёма броней, а что можно отключить без остановки зала.

Первые две-четыре недели после передачи остаёмся на связи по регламенту поддержки — отвечаем на вопросы вашей команды и разбираем инциденты вместе, пока вы не выйдете на самостоятельный цикл выпуска.

Кейс: сеть заведений — время брони сократилось втрое

Что было

Сеть залов держала брони в бумажном журнале и на телефоне: администратор принимал звонок, сверялся с занятостью столов и перезванивал для подтверждения. На вечерней пиковой нагрузке путь от обращения до подтверждённой брони растягивался до 4-5 минут, часть звонков терялась в очереди, а доля неявок держалась около 18% — стол простаивал под гостя, который не приехал.

Что изменили

Для Прованс собрали мобильное приложение с картой зала: гость видит реальную занятость на выбранное время, подбирает стол по посадке и получает подтверждение сразу, без звонка. Напоминание приходит за несколько часов до визита, отмена и перенос доступны в один тап, а освободившееся время тут же уходит в лист ожидания следующему гостю.

Со стороны зала появилась консоль администратора: лента броней, загрузка на смену, автоматическое распределение столов с буфером на уборку между посадками — ручной сверки по журналу больше нет.

Что стало

Путь до подтверждённой брони сократился втрое — до полутора минут в среднем, и в часы пик он больше не растёт из-за очереди на телефоне. Неявки снизились с 18% до 6% на тех посадках, где включены напоминания и подтверждение визита.

Число звонков на смену уменьшилось примерно втрое: администратор занимается залом, а не обзвоном. Лист ожидания возвращает в оборот брони, от которых отказались, поэтому вечерние отказы сократились без расширения посадки — кейс разработки окупается самой загрузкой зала, а не ростом числа столов.

Что делать, если приложение уже выпущено и тормозит

Выпущенное мобильное приложение для ресторана тормозит редко по одной причине: обычно складываются тяжёлый старт, лишние запросы при открытии экрана и обходные решения, накопленные за годы правок. Прежде чем что-то переписывать, мы проводим аудит текущего решения — снимаем профиль запуска и ключевых сценариев бронирования и смотрим, где время уходит на ожидание сети, а где на отрисовку списков и карт. По итогам аудита видно, закрывается ли задача поддержкой готового продукта или без пересборки ядра не обойтись.

Выбор между двумя путями — это выбор между скоростью результата и сроком жизни решения. Точечная доработка даёт быстрый эффект там, где мы уже поработали, но оставляет причину: следующая правка снова упрётся в те же слои. Пересборка ядра дольше и требует параллельной работы двух версий, зато снимает причину, а не симптом.

Дальше начинается поддержка готового продукта: сбор падений и медленных операций, контроль доли успешно завершённых бронирований, регресс на каждом выпуске. Доработка релиза идёт короткими итерациями с возможностью быстрого отката — качество не теряется по мере роста нагрузки.

Частые технические вопросы перед стартом

Сомнения на этапе оценки почти всегда одни и те же: что будет в час пик при перегрузке канала, как данные попадут в кассовую смену, чем обернётся обновление в разгар смены и кто отвечает за персональные данные гостей. Ниже — короткие ответы по существу, без общих слов.

Как приложение связано с кассой и складом?

Мы работаем через открытый программный интерфейс кассовой системы: заказ со стола попадает в текущую смену одним чеком, статусы оплаты и списания возвращаются обратно в приложение. Если касса недоступна, операция ставится в очередь с ключом уникальности — повтор не создаёт дубль чека. Какие именно кассы поддерживаются и что делать с нестандартной сборкой, фиксируем на этапе обследования.

Обновления ломают работу в смену?

Серверная часть выкатывается на подготовленное окружение с последующим переключением, поэтому время недоступности измеряется секундами. Мобильное приложение опирается на обратно совместимый контракт: гости со старыми версиями продолжают бронировать, минимальная поддерживаемая версия поднимается постепенно. Миграции схемы данных идут отдельным шагом и проверяются на копии рабочей базы.

Кто отвечает за безопасность данных гостей?

Мы минимизируем набор: храним только то, что нужно для брони и программы лояльности. Передача и хранение — в зашифрованном виде, доступ разграничен по ролям, действия администраторов попадают в журнал. Выгрузка и удаление данных по запросу гостя выполняются штатным сценарием. После передачи исходников и схемы данных ответственность фиксируем регламентом выпуска и поддержки.

Обсудим задачу и вернёмся с оценкой и планом

Чтобы оценка опиралась на факты, а не на «плюс-минус», нужны вводные по залу и процессу бронирования. Собираем их на разговоре с человеком, который отвечает за посадку: обычно 40–60 минут хватает, чтобы увидеть объём мобильного приложения для ресторана и риски, которые лучше закрыть до начала работ.

Что полезно подготовить к обсуждению задачи:

• Схема зала: сколько точек, посадок, есть ли банкеты, депозиты, веранда, как сейчас распределяют столы между сменами.
• Каналы бронирования: звонки, сайт, соцсети, внешние площадки — что остаётся, что переводим в приложение.
• Роли и доступы: гость, хостес, менеджер смены, управляющий — кто что видит и меняет.
• Учётные системы: касса, склад, программа лояльности, телефония — есть ли открытый доступ к данным и кто отвечает за интеграцию.
• Уведомления: подтверждение гостю, напоминание накануне, оповещение смены о новых бронях — по каким каналам.
• Ограничения: дата, к которой нужен запуск, требования к защите персональных данных, свои дизайн-макеты или работаем с нашими.

Если по части пунктов ответа нет — не страшно, часть уточним на месте и предложим решение. После разговора фиксируем состав первой версии и порядок этапов. Вернёмся с оценкой проекта по срокам и планом работ, где видно, что делаем на старте и когда функцию можно проверить на реальных бронированиях.