Создание портала для ресторана с интеграцией iiko и R_Keeper

Портал ресторана: что ломается при росте нагрузки

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

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

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

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

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

Что даёт внедрение: эффект, который видно по показателям

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

Заказы сходятся без оператора

Онлайн-заказы и доставка идут из личного кабинета гостя напрямую в iiko и R_Keeper: заказ создаётся в системе с тем же составом, модификаторами и адресом, что выбрал гость. Доля автоматически сведённых заказов — 97–99%, остальное уходит в отдельный список исключений на ручной разбор.

Меню обновляется за минуты

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

Сбой не останавливает приём

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

Баллы и столы в одном контуре

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

Форматы портала ресторана: готовое решение или сборка под заказ

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

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

Как мы ведём внедрение: этапы инженерной работы

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

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

2. Схема обмена данными. Согласуем, что и в какую сторону передаётся: меню и цены, остатки, статусы заказа, закрытие чека, отмены. Фиксируем главный источник данных при конфликте и правила повторных отправок.

3. Настройка интеграции. Поднимаем обмен между порталом и iiko или R_Keeper на тестовом контуре: сопоставляем номенклатуру, настраиваем роли и доступы, ограничиваем частоту обращений к кассе, чтобы обмен не мешал работе ресторана.

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

5. Запуск. Переводим точки по одной, начиная с одной смены, и держим контроль очереди обмена и времени ответа — сбой локализуется на конкретной точке, а не на всей сети.

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

Что заказчик получает на руки: комплект документации

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

Собираем комплект так, чтобы им можно было пользоваться, не зная внутренностей портала: каждый документ отвечает на вопрос «что делать, если это отвалилось».

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

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

Кейс: сняли расхождения между сайтом и системой учёта

Что было до

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

Что изменили и что получили

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

Ручных сверок осталось 2-3 за смену вместо 30-40 — их вызывают только нестандартные случаи вроде частичного отказа от позиции. Публикация изменения меню сократилась с 3-4 часов до 5-10 минут: правку вносят один раз в системе учёта, и она сразу видна на сайте. На пике — пятничный вечер, праздничные дни — портал держит двукратный рост заказов без расхождений по остаткам, тогда как раньше именно в эти часы начинались спешные сверки.

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

Что делать, если уже работает другой сайт и учётная система

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

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

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

Частые вопросы: сроки, нагрузка и обмен данными

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

Что будет при недоступности кассы?

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

Как устроен обмен с кассой?

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

Сможем ли менять меню сами?

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

Что входит в поддержку после запуска?

Мониторинг обмена и доступности, обновления, разбор инцидентов по регламенту и доработки. Журнал сбоев показывает, какие узлы деградируют первыми.

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

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

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

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