Ресторан, интернет-магазин и доставка: одна система или три продукта?

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

КОРОТКО

Одна система, три сценария

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

Мы пришли к этому на проекте LavShash: у бизнеса были ресторан, гастромаркет примерно от 2 000 до 3 000 товаров и собственная доставка. Большинство предложений, которые он получал, строились по одной схеме: сайт ресторана, интернет-магазин и продукт для доставки, каждый сам по себе. Мы предложили одну цифровую экосистему вокруг трёх сценариев клиента, спроектировали её и сделали сайт, маркет и нативные приложения доставки для iOS и Android. Система построена и готова, запуск отложен.

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

Три продукта под одним логотипом для клиента остаются тремя продуктами.

ТРИ СМЕТЫ

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

Разделение обычно задаёт рынок, а не сам бизнес. Студия, которая делает сайты ресторанов, считает сайт ресторана. Команда e-commerce считает магазин. Студия приложений считает приложение. Каждое предложение решает задачу, которая перед ним стоит. Пространство между тремя продуктами при этом не принадлежит никому.

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

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

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

ОБЩЕЕ ЯДРО

Что существует один раз, а что отдельно

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

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

Тот же принцип для розницы, опта и партнёров мы описали в статье Когда e-commerce становится бизнес-системой. Там речь о ценах по аккаунтам и распределении остатков между торговыми каналами. В ресторанном бизнесе болевые точки другие: время кухни, зоны доставки и клиент, который за одну неделю успевает поесть в зале, заказать на дом и купить продукты.

В LavShash каждая часть сохранила свою логику и свои сценарии, а снаружи всё оставалось одним брендом на общей архитектуре. Гастромаркет внутри был полноценным интернет-магазином: категории, поиск, фильтры, карточки товаров, корзина и оформление заказа, то есть именно то, чем занимается наша разработка интернет-магазинов. Сначала магазин сделал на Magento предыдущий подрядчик, а мы пересобрали его на Laravel вокруг бизнес-правил; почему и что это изменило, рассказано в статье Уходить ли с Magento в 2026 году.

ОДИН КЛИЕНТ

Один аккаунт, одна история

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

Разница видна там, где это важно владельцу:

• Сервис. Приложение доставки уже знает адрес из последнего заказа в маркете, а жалобу на доставку видно рядом с визитами клиента в ресторан.
• Рассылки. Одна запись о согласиях решает, кому можно отправлять новости и предложения, вместо трёх списков с тремя наборами правил отписки.
• Лояльность. Баллы, подарочные карты или предложение ко дню рождения работают во всех каналах, потому что их есть к чему привязать.
• Цифры. Бизнес видит, сколько клиентов пользуются больше чем одним каналом и сколько они тратят в сумме. Три отдельные базы без ручного сопоставления на этот вопрос не ответят.

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

Защита данных тоже упрощается: персональные данные лежат в одном месте, с одним набором прав доступа и одним порядком обработки запроса на удаление, вместо трёх подрядчиков и трёх баз, в которых нужно искать.

ДОСТАВКА

Доставка как отдельный продукт

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

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

Логику доставки в бизнесе с несколькими каналами определяют пять вопросов:

1. Можно ли в одном заказе смешать блюда кухни и товары маркета? Звучит удобно, но у готовой еды короткое окно, а заказ из маркета можно собрать за несколько часов. Одни разрешают это с одним временем доставки, другие делят на два заказа с одной оплатой.
2. Кто решает, какой слот доступен: кухня или курьер? Если кухня занята на 19:00, доставка должна перестать предлагать 19:30, а не принимать заказ и потом извиняться.
3. Какие зоны и по какой цене? Зоны и минимальная сумма заказа относятся к бизнес-правилам и меняются. Им место в админке, где их правит менеджер, а не в коде.
4. Что клиент видит после оплаты? Принят, готовится, в пути, доставлен: каждый статус либо отправляет бизнес, либо потом объясняет по телефону.
5. Как устроены возвраты? Недостающий товар в заказе из маркета и остывшее блюдо требуют разной обработки, но оба случая должны идти через одну историю заказов.

Владельцы часто спрашивают, нужна ли собственная доставка, если есть агрегаторы. Агрегаторы дают охват, и многие рестораны работают с обоими вариантами. Цена агрегатора складывается из комиссии с каждого заказа и отношений с клиентом: в США тарифы DoorDash Marketplace на октябрь 2026 года берут с ресторана 15%, 25% или 30% с заказа на доставку, а клиент остаётся клиентом платформы. Собственный канал доставки оставляет клиента, данные и правила у бизнеса. При этом он должен окупаться, поэтому ему место на том же ядре, что и всё остальное, а не в роли четвёртого продукта.

Доставка перестаёт быть страницей меню, как только заказы начинают повторяться.

ТОЧКИ ВХОДА

Главная страница не главный вход

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

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

Для бизнеса, который планирует свою систему, из этого следуют конкретные решения:

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

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

ПРИЛОЖЕНИЯ ИЛИ ВЕБ

Нативные приложения или мобильный веб?

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

Поэтому в LavShash доставка получила нативные приложения для iOS и Android, а ресторан и гастромаркет жили в вебе. Доставка никогда не должна была ощущаться мобильной версией сайта ресторана. Тому, кто заказывает часто, нужна скорость: его адрес, его последний заказ, способ оплаты и статус, за которым можно следить.

Мобильный веб за последние годы заметно вырос. Начиная с iOS и iPadOS 16.4 веб-приложение, добавленное на экран «Домой», может запрашивать разрешение на push-уведомления, об этом команда WebKit в Apple объявила вместе с этим релизом. Маркету или ресторану быстрый мобильный сайт, который можно установить как веб-приложение, закрывает большинство задач за долю стоимости приложения в сторе. Apple со своей стороны тоже ставит планку: правила проверки App Store требуют, чтобы приложение было чем-то большим, чем переупакованный сайт, так что завернуть сайт в оболочку приложения не получится.

Как выбирать на практике:

Мы делаем нативные приложения на Swift и Kotlin или одно приложение на React Native, в зависимости от того, что нужно продукту, вместе с серверной частью и админкой, как описано на странице разработки приложений; полноценное приложение обычно занимает от 10 до 20 недель. Для бизнеса с несколькими каналами главное в том, что приложение становится ещё одним интерфейсом к тому же ядру, без собственного каталога. Более широкое решение, включая прогрессивные веб-приложения, разобрано в статье Когда бизнесу реально нужно мобильное приложение?

РАСХОДЫ

Во что обходятся три продукта

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

Приложения добавляют слой расходов, который никуда не уходит. На октябрь 2026 года программа разработчиков Apple стоит $99 в год, а Google Play берёт разовый регистрационный взнос $25. Оба стора повышают технические требования по графику: с 28 апреля 2026 года приложения, загружаемые в App Store Connect, должны собираться в Xcode 26 с iOS 26 SDK, а с 31 августа 2026 года новые приложения и обновления в Google Play должны быть нацелены на Android 16 (API level 36). Приложение приходится обновлять каждый год, даже если в бизнесе ничего не изменилось. В схеме из трёх продуктов именно приложение доставки чаще всего остаётся без хозяина.

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

Для ориентира наши стартовые цены на октябрь 2026 года: интернет-магазин от $25 000, мобильное приложение от $30 000, диджитализация бизнеса от $15 000. Система такого типа объединяет части всех трёх, поэтому настоящая смета появляется после того, как бизнес разобран. Остальные цены собраны на странице цен.

Самая дешёвая смета на старте редко даёт самую дешёвую систему в работе.

ПОРЯДОК

Что строить первым

Одна система не означает, что всё строится сразу. Она означает, что целое проектируется заранее, а строится в порядке, который рано даёт пользу. Мы рекомендуем такую последовательность:

1. Разобрать бизнес. Каналы, товары, остатки, клиенты, кухня, курьеры, а также уже работающие системы учёта и кассы. Стратегическая сессия даёт первый ответ за два или три часа, а discovery-фаза превращает его в документы, прототип и смету.
2. Спроектировать общее ядро. Каталог, правила доступности, аккаунт клиента, модель заказа и админка. Именно эта часть делает следующие каналы дешёвыми.
3. Запустить сценарий, на который уже есть спрос. Для одного бизнеса это маркет, для другого доставка. Первый канал помогает оплатить следующие.
4. Добавить второй и третий сценарии на том же ядре. Каждый получает свой интерфейс, но ни один не получает свою базу.
5. Добавить приложения, когда видно повторное поведение. Приложение доставки имеет смысл, когда к ней возвращаются, и к этому моменту ядро уже отдаёт ему данные.

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

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

КОГДА ОТДЕЛЬНО

Когда отдельные продукты правильнее

Одна система подходит не всегда. Отдельные продукты оправданы в четырёх ситуациях:

• Каналы на деле являются разными бизнесами. Разные бренды, разная аудитория, порой разные владельцы. Если маркет через год можно будет продать отдельно, его система должна уметь уйти вместе с ним.
• Канал работает как эксперимент. Если доставка запускается как тест на три месяца, агрегатор или простой инструмент заказа обойдутся дешевле, чем встраивание в ядро. Перенести канал в систему можно, когда он себя докажет.
• Ресторану нужно только приглашать. Сайта с меню, фотографиями и виджетом брони от сервиса бронирования может хватить, и делить с магазином почти нечего.
• Операции не пересекаются. Нет общих товаров, общих клиентов и общих остатков. Тогда интеграция стоит больше, чем экономит.

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

Любому подрядчику стоит задать простой вопрос: если через два года мы добавим четвёртый канал, что изменится в вашей системе? Если ответ звучит как «ещё один проект такого же размера», бизнес покупает продукты. Если ответ «новый интерфейс на существующем ядре», он покупает систему.

FAQ

Источники

• DoorDash for Merchants: тарифы Marketplace и комиссии
• Apple Developer Program: стоимость участия
• Справка Google Play Console: регистрационный взнос
• Apple: требования к публикации в App Store
• Android Developers: требования к target API level в Google Play
• Apple: правила проверки App Store, раздел 4.2 Minimum Functionality
• WebKit: Web Push for Web Apps on iOS and iPadOS