Ramen Joe починався як один ресторан у Лісабоні. Сьогодні це п'ять закладів, застосунок iOS в App Store, застосунок Android у Google Play, програма лояльності з Apple Wallet і Google Wallet, а також бек-офіс, який керує операціями групи. Усе на одній платформі.
Ця стаття розповідає, що саме така платформа вирішила, скільки коштувало її побудувати замість купівлі готового SaaS і де більшість ресторанних груп помиляється, коли пробує зробити те саме.
Виконавче резюме
Ресторанна група з понад двома локаціями зазвичай має три технічні проблеми, які на старті ніхто не оцінює правильно. Фрагментовані бронювання по закладах. Програма лояльності, яка не слідує за клієнтом між закладами. Операційні дані, що живуть у локальних файлах і чатах WhatsApp.
Ramen Joe консолідував операцію в одну систему. Спільні бронювання, єдиний профіль клієнта, лояльність, цифрове меню, керування персоналом і централізована аналітика. Практичний результат — клієнт, який ставить штамп у Лісабоні, бачить той самий баланс у Порту, а команда керує п'ятьма закладами і може додавати нові локації з того самого бек-офісу.
Ціна такого вибору не тривіальна. Але ціна відмови від нього виринає пізніше, замаскована під відтік, повторну роботу персоналу і рішення про експансію, ухвалені наосліп.
Проблема бізнесу
Коли один ресторан стає групою, ПЗ, яке добре працювало для одного закладу, починає ламатися. Не тому, що воно погане. Тому, що його спроєктували для контексту, який уже не твій.
Класичний симптом: кожна локація опиняється зі своїм модулем бронювань, часто прив'язаним до Google або до конкретного SaaS-інструменту. Клієнти програми лояльності живуть у базі даних кожного закладу окремо або, гірше, у паперовому зошиті. Коли хочеш дізнатися, скільки постійних клієнтів у групі, відповіді немає. Тільки оцінки.
Критична точка ось у чому. В одному закладі CRM — це менеджер. Він знає постійних, знає, хто любить стіл у глибині, знає, хто приводить сім'ю в неділю. У п'яти закладах така розподілена пам'ять перестає працювати. І клієнт це помічає.
Чому це важливо
Лояльність у ресторанному бізнесі — це не операційна деталь. Це хребет моделі. Вартість залучення нового клієнта в кілька разів вища за вартість повернення наявного. Це справедливо майже в усіх секторах, і ресторанний бізнес не виняток.
Якщо твоя програма лояльності не слідує за клієнтом між закладами, ти трактуєш кожен візит як перший. Він не перший. Клієнт пам'ятає. Не пам'ятає лише система.
Другий кут — операційний. Група з п'яти закладів генерує достатньо даних, щоб ухвалювати обґрунтовані бізнес-рішення. Які години заповнюються першими. У які дні тижня потрібні кампанії. Яка локація має найбільше no-show. Без єдиної платформи ці дані існують, але ніхто не може їх прочитати.
Що робить платформа
Архітектура 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, який шле нагадування за годину до бронювання — це знизило no-show без спаму.
SMS короткий за задумом. Ім'я, час, заклад. Посилання для скасування. Нічого більше. Комерційний пакет розрахували з початкової оцінки в 1 500 SMS на рік, виведеної з очікуваного обсягу бронювань. Це не технічний ліміт: обсяг можна коригувати в міру зростання операції.
Застосунки: iOS і Android випущені одночасно
Версії для iOS і Android випустили одночасно. Android-застосунок став доступним пізніше, бо процес перевірки в Google Play тривав довше — а не через рішення фазувати продукт чи віддати перевагу одній платформі.
Обидва застосунки розробляли паралельно з однією пропозицією цінності: бронювання, лояльність і послідовний досвід на обох платформах. Різниця в моменті появи в магазинах — лише наслідок термінів схвалення в кожному маркетплейсі.
Ціна очевидна: два нативні кодбейси замість одного крос-платформного фреймворку на кшталт React Native чи Flutter. Це був свідомий trade-off. Виграш — застосунок поводиться так, як просить платформа, а не так, як дозволяє спільний знаменник.
Що йде не так у таких проєктах
Більшість ресторанних груп, які пробують побудувати таку платформу, роблять одні й ті самі три помилки. Варто їх назвати.
- Починають із застосунку. Без зрілого бекенду і без чітких бізнес-правил застосунок перетворюється на гарну обгортку, яка тиражує операційний хаос на мобільних екранах.
- Покладаються на WordPress-плагіни для бронювань і лояльності. Для одного закладу працює. Для п'яти — ламається.
- Наймають агенції, які будують за проєктом і зникають. ПЗ не закінчується на лончі. Воно там починається.
Протиотрута до всіх трьох та сама. Ставтеся до ПЗ як до інфраструктури, а не до кампанії. Спершу вкладайте у фундамент — бекенд, база даних, автентифікація, дозволи, безперервний деплой — і лише потім у видиму поверхню.
Практики, які виправдали себе
Деякі рішення здаються дрібними, але мали непропорційно великий вплив на роботу системи в продакшені.
Перше: git як єдине джерело правди. Кожна зміна проходить через commit, кожен деплой автоматичний через GitHub Actions. Це усуває категорію багів "працює на моєму комп'ютері" і дозволяє відкотитися за хвилини, якщо щось ламається в продакшені. Офіційна документація GitHub про continuous deployment добре покриває принципи.
Друге: інтернаціоналізація серйозно. Сайт працює португальською і англійською, зі строками, централізованими у файлах перекладу. Здається перебором для ресторану в Лісабоні, поки не помічаєш, що 30% клієнтів у туристичних зонах не говорять португальською. І що розширення в нове місто простіше, коли система вже підтримує кілька мов.
Третє: розділити sandbox і продакшн із чіткими правилами. Ramen Joe має версію sandbox, яка віддзеркалює продакшн, але з тестовими даними. Будь-яка зміна проходить спочатку там. Це знижує ймовірність зламати справжнє бронювання при тестуванні нової фічі.
Де застосовна ця модель
Архітектура Ramen Joe не специфічна для ramen. Вона працює для будь-якого рітейл- або hospitality-бізнесу з кількома локаціями і базою постійних клієнтів. Ресторанні групи, мережі кав'ярень, барбершопів, клініки з кількома філіями, спортзали з кількома точками.
Спільний знаменник ось який: клієнт один, а операція розподілена. Якщо твоє ПЗ цього не відображає, ти платиш операційним тертям те, що мав би заробляти лояльністю.
Ключові висновки
- Ресторанній групі з кількома закладами потрібна уніфікована платформа — фрагментовані бронювання коштують дорожче за ПЗ, яке їх консолідує.
- Справді мультилокаційна платформа дозволяє додавати нові локації, меню й операційні правила без технічних змін у сайті чи застосунках.
- Лояльність між закладами не опціональна, якщо хочеш реальної утримуваності. Клієнту байдуже, у якому закладі він витратив.
- Нативні застосунки виправдані, коли Wallet, push-сповіщення і швидка камера — центральна частина досвіду.
- Персонал — користувач системи не менше за клієнта. Якщо потік довший за старий процес, систему саботує перевантаження.
- Git як єдине джерело, sandbox окремо від продакшену і i18n з першого дня. Це фундаментальні рішення, які уникають дорогих рефакторингів пізніше.
- Найдорожча помилка — почати із застосунку до того, як бекенд став зрілим.
Природний наступний крок для групи на цій стадії — не додавати ще фічі. А міряти. Які штампи конвертуються в другий візит. Які заклади краще утримують. Які кампанії справді зрушують стрілку. Уніфікована платформа робить цей аналіз можливим. Далі — питання того, щоб дивитися.