Ramen Joe начинался как один ресторан в Лиссабоне. Сегодня это пять заведений, приложение для iOS в App Store, приложение для Android в Google Play, программа лояльности с Apple Wallet и Google Wallet, а также бэк-офис, который управляет операциями всей группы. Всё построено на единой платформе.
Этот материал рассказывает, какие задачи платформа решила, во что обошлось её создание вместо покупки готового SaaS и где ошибаются большинство ресторанных групп, пытаясь пройти тот же путь.
Краткое резюме
У ресторанной группы с более чем двумя локациями обычно возникают три технические проблемы, масштаб которых никто не оценивает вовремя. Брони раздроблены по заведениям. Программа лояльности не следует за клиентом между точками. Операционные данные живут в локальных файлах и переписках WhatsApp.
Ramen Joe консолидировал операции в одну систему. Общие брони, единый клиент, лояльность, цифровое меню, управление персоналом и централизованная аналитика. На практике это значит, что клиент, который получает штамп в Лиссабоне, видит тот же баланс в Порту. А команда управляет пятью заведениями — и может добавлять новые локации — из одного и того же бэк-офиса.
Цена такого решения немаленькая. Но цена бездействия проявляется позже, замаскированная под отток клиентов, дублирование работы персонала и решения о расширении, принятые вслепую.
Бизнес-задача
Когда один ресторан превращается в группу, софт, который отлично служил одному заведению, начинает трещать. Не потому что он плох. Потому что был спроектирован под контекст, которого у тебя больше нет.
Классический симптом: у каждой локации свой модуль броней, часто привязанный к Google или к отдельному SaaS-инструменту. Клиенты программы лояльности сидят в базе данных каждого заведения отдельно или, что хуже, в бумажном блокноте. Когда хочешь узнать, сколько постоянных клиентов у группы в целом, ответа нет. Есть только оценки.
Ключевой момент такой. В одном заведении CRM — это управляющий. Он знает завсегдатаев, помнит, кто предпочитает дальний столик, знает, кто приводит семью по воскресеньям. В пяти заведениях эта распределённая память перестаёт работать. И клиент это замечает.
Почему это важно
Лояльность в ресторанном бизнесе — это не операционная деталь. Это позвоночник всей модели. Стоимость привлечения нового клиента в разы выше стоимости возврата существующего. Это правило действует почти во всех секторах, и ресторанный бизнес — не исключение.
Если твоя программа лояльности не следует за клиентом между заведениями, ты обращаешься с каждым визитом как с первым. Но это не так. Клиент помнит. Забывает система.
Второй ракурс — операционный. Группа с пятью заведениями генерирует достаточно данных, чтобы принимать обоснованные бизнес-решения. Какие часы заполняются первыми. В какие дни недели нужны кампании. В какой локации больше неявок. Без единой платформы эти данные существуют, но никто не может их прочитать.
Что делает платформа
Архитектура Ramen Joe стоит на трёх блоках, которые общаются между собой. Бэкенд на Express с реляционной базой данных, публичный фронтенд на Next.js для конечных клиентов и набор нативных приложений (iOS SwiftUI и Android), которые воспроизводят опыт сайта в мобильном контексте.
Выбор нативных приложений вместо PWA заслуживает объяснения. Это не техническое тщеславие. Это продуктовое решение, продиктованное тремя конкретными причинами.
- Apple Wallet и Google Wallet интегрируются в нативные приложения чисто — карта лояльности отправляется прямо в кошелёк телефона и получает автоматические обновления, когда меняется баланс.
- Push-уведомления в iOS имеют ограничения, которые веб не может обойти без ущерба для опыта.
- Tap-to-scan персонала в ресторанах требует камеры с быстрым автофокусом и почти нулевой задержкой. Веб здесь пока проигрывает.
Со стороны броней система рассинхронизирована с календарём каждого заведения. Когда клиент бронирует в Лиссабоне, столик блокируется только в Лиссабоне. Но карточка клиента, история, предпочтения по столикам — всё это глобальное.
Цифровое меню и расширение без технической зависимости
Платформа также централизует цифровое меню всех пяти локаций. Команда управляет товарами, информацией и настройками каждого заведения из одного бэк-офиса, сохраняя согласованный опыт на сайте и в приложениях без дублирования работы по каналам.
Мультилокационное управление было спроектировано так, чтобы расширение группы не зависело от новой технической разработки. Команда сама может завести локацию, задать часы работы, контакты, меню, столики, правила броней и остальные операционные настройки.
После настройки новое заведение становится доступным на сайте и в мобильных приложениях из того же источника данных. Не нужно разрабатывать новую версию сайта или приложений только ради добавления одной точки. Это снижает стоимость и сокращает время между решением о расширении и появлением новой локации в цифровых каналах.
Лояльность между заведениями: решение, которое меняет всё
Самая частая точка трения в ресторанных группах именно здесь. Каждое заведение хочет свою программу. Каждый управляющий хочет видеть своих лояльных клиентов. Каждая маркетинговая кампания склонна застревать в одной локации.
Ramen Joe выбрал противоположное. Одна программа, один баланс баллов, один клиент. Это создаёт нетривиальные последствия для бухгалтерии — кто «платит» за штамп, поставленный в Лиссабоне и погашенный в Порту? — но решается внутренними правилами распределения, а не фрагментацией системы.
Клиенту не должно приходиться об этом думать. И, по правде, он и не думает. Ставит приложение один раз, добавляет карту в Wallet — и опыт одинаков в любом заведении группы. Это и есть product-market fit лояльности.
Роль персонала
Цифровая система лояльности работает только тогда, когда персонал в ней участвует. Если поставить штамп занимает больше времени, чем прежний штамп на бумажной карточке, персонал начнёт саботаж — не из злого умысла, а от перегрузки в часы пик.
Сканер Ramen Joe спроектирован с учётом этого ограничения. Официант, авторизованный в системе, открывает приложение, наводит камеру на QR клиента — и штамп ставится меньше чем за две секунды. Никаких меню, никаких промежуточных подтверждений, никакого ввода вручную.
Разрешение ставить штампы отделено от разрешения на доступ к бэк-офису. Официант ставит штамп. Управляющий смотрит отчёты. Администратор группы меняет правила. Такое разделение банально в корпоративном SaaS, но его часто игнорируют в ресторанном софте — а потом удивляются, откуда взялся внутренний фрод с баллами.
Брони: меньше автоматики, больше контроля
В любой современной системе броней есть соблазн: автоматизировать всё. Автоматическое подтверждение, автоматическое напоминание, автоматический ответ на изменения. И в большинстве случаев это работает хорошо.
В качественной ресторации это работает хуже. Бронь на двенадцать человек в субботу вечером не должна подтверждаться автоматически без того, чтобы кто-то посмотрел на зал. Запрос конкретного столика должен проходить через того, кто знает заведение. А форс-мажоры в последнюю минуту требуют человека.
Платформа Ramen Joe допускает обе модели, отдельно для каждого заведения. Стандартные брони обрабатываются автоматически. Крупные брони или брони со специальными пожеланиями попадают в очередь на одобрение. Есть и SMS-канал через Telnyx, который отправляет напоминание за час до брони, что снизило количество неявок без превращения в спам.
SMS короткие по замыслу. Имя, время, заведение. Ссылка для отмены. Больше ничего. Коммерческий пакет рассчитан с начальной оценкой в 1500 SMS в год, посчитанной на основе ожидаемого объёма броней. Это не технический лимит: ёмкость можно скорректировать по мере роста операций.
Приложения: iOS и Android выпущены одновременно
Версии для iOS и Android запускались одновременно. Приложение для Android стало доступным позже, потому что проверка в Google Play заняла больше времени, а не потому что мы решили выпускать поэтапно или отдавать приоритет одной платформе.
Оба приложения разрабатывались параллельно с одинаковым предложением: брони, лояльность и согласованный опыт на двух платформах. Разница в моменте появления в магазинах определялась только сроками одобрения каждого маркетплейса.
Цена очевидна: две нативные кодовые базы вместо одного кросс-платформенного фреймворка вроде React Native или Flutter. Это был осознанный компромисс. Выигрыш — приложение, которое ведёт себя так, как требует платформа, а не так, как позволяет общий знаменатель.
Что идёт не так в таких проектах
Большинство ресторанных групп, которые пытаются построить подобную платформу, совершают одни и те же три ошибки. Их стоит назвать.
- Начинают с приложения. Без зрелого бэкенда и без чётких бизнес-правил приложение превращается в красивую оболочку, воспроизводящую операционный хаос на мобильных экранах.
- Полагаются на плагины WordPress для броней и лояльности. Работает на одном заведении. Разваливается на пяти.
- Нанимают агентства, которые строят под проект и исчезают. Софт не заканчивается на запуске. Он с него начинается.
Противоядие от всех трёх ошибок одно и то же. Относись к софту как к инфраструктуре, а не как к кампании. Сначала вкладывайся в фундамент — бэкенд, база данных, аутентификация, разрешения, непрерывный деплой — и только потом в видимую поверхность.
Практики, которые оправдали себя
Некоторые решения кажутся мелкими, но их влияние на работу системы в продакшене оказалось непропорционально большим.
Первое: git как единственный источник истины. Каждое изменение проходит через коммит, каждый деплой автоматический через GitHub Actions. Это устраняет целую категорию багов «работает у меня на машине» и позволяет откатиться за минуты, если что-то сломается в продакшене. Официальная документация GitHub по continuous deployment хорошо покрывает эти принципы.
Второе: интернационализация всерьёз. Сайт работает на португальском и английском, со строками, вынесенными в централизованные файлы переводов. Это выглядит избыточно для ресторана в Лиссабоне, пока не осознаёшь, что 30% клиентов в туристических зонах не говорят по-португальски. И что расширение в новый город идёт быстрее, когда система уже поддерживает несколько языков.
Третье: разделение sandbox и продакшена с ясными правилами. У Ramen Joe есть версия sandbox, которая зеркалит продакшен, но с тестовыми данными. Любое изменение проходит сначала через неё. Это снижает вероятность сломать реальную бронь при тестировании новой фичи.
Где эта модель применима
Архитектура Ramen Joe не специфична для рамэна. Она применима к любому ритейл- или гостеприимному бизнесу с несколькими локациями и базой возвращающихся клиентов. Ресторанные группы, сети кофеен, сети барбершопов, клиники с несколькими филиалами, фитнес-центры с более чем одной точкой.
Общий знаменатель такой: клиент один, а операции распределены. Если твой софт этого не отражает, ты платишь операционным трением за то, что должен был зарабатывать на лояльности.
Ключевые выводы
- Ресторанной группе с несколькими заведениями нужна единая платформа — фрагментированные брони обходятся дороже, чем софт, который их консолидирует.
- По-настоящему мультилокационная платформа позволяет заводить новые локации, меню и операционные правила без технических правок сайта или приложений.
- Лояльность между заведениями не опциональна, если хочешь реального удержания. Клиенту не важно, в каком заведении он потратил деньги.
- Нативные приложения оправданы, когда Wallet, push-уведомления и быстрая камера — центральная часть опыта.
- Персонал — такой же пользователь системы, как и клиент. Если процесс дольше прежнего, система саботируется перегрузкой.
- Git как единый источник, sandbox отдельно от продакшена, i18n с первого дня. Это решения фундамента, которые избавляют от дорогих рефакторингов позже.
- Самая дорогая ошибка — начинать с приложения, не имея зрелого бэкенда.
Естественный следующий шаг для группы в этой фазе — не добавлять новые фичи. Это измерять. Какие штампы конвертируются во второй визит. Какие заведения удерживают лучше. Какие кампании реально двигают стрелку. Единая платформа делает такой анализ возможным. Дальше остаётся только смотреть.