Онлайн-заказ для ресторана: сайт или приложение?

Для многих ресторанов и кафе онлайн-заказы начинались как вспомогательный канал и незаметно стали большой частью выручки. Самый быстрый путь был очевиден: подключиться к Glovo или Bolt Food, загрузить меню и на той же неделе получать заказы. Компромисс стал заметен позже. С каждого заказа платится комиссия, клиент принадлежит платформе, а не заведению, и лояльность формируется к приложению агрегатора, а не к вашему бренду.

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

Поделимся и реальным примером. Для одесского бренда доставки Buddha Pizza мы создали одностраничный сайт с онлайн-заказом и игривым генератором заказов, о котором говорил полгорода. Полный кейс Buddha Pizza есть в нашем портфолио, а подробнее о нем расскажем ниже.

Почему ресторанам нужны прямые онлайн-заказы

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

Комиссия агрегатора. Glovo, Bolt Food и другие платформы берут процент с каждого заказа. Точная ставка зависит от договора, города, формата сотрудничества и дополнительных услуг вроде продвижения в приложении, поэтому ориентируйтесь на условия именно вашего соглашения. Для сравнения, на американском рынке DoorDash публично называет комиссии на доставку 15 %, 25 % и 30 % от суммы заказа в зависимости от тарифа. Для заведения, где себестоимость блюд, аренда и зарплаты уже забирают большую часть выручки, такой процент заметно снижает маржинальность.

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

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

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

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

Варианты онлайн-заказа: сравнение

Есть четыре основных способа принимать заказы онлайн. Большинство заведений в итоге используют два из них одновременно.

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

Агрегаторы доставки

Glovo и Bolt Food в Украине объединяют три вещи: большую аудиторию, сеть курьеров и готовое приложение для клиентов. Это самый быстрый способ начать доставку и полезный канал, чтобы вас увидели люди, которые еще не знают заведение.

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

SaaS-платформы для онлайн-заказов

Второй вариант — это готовые SaaS-сервисы, которые за ежемесячную подписку дают заведению брендированную страницу заказов или виджет на сайт. Часть таких решений входит в экосистему POS-систем, поэтому интеграция с POS работает «из коробки».

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

Собственный сайт с онлайн-заказом

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

Сайт также помогает вас находить. Хорошо сделанный сайт может ранжироваться в поиске по названию заведения, блюдам и району, а SEO и карточка в Google Maps работают вместе: многие гости ищут «пицца рядом» именно на карте. Для одного заведения или небольшой сети сайт — часто лучший первый шаг к прямым заказам. Такие решения мы делаем в рамках разработки веб-порталов и сервисов, от простых сайтов заказа до платформ для сетей с админ-панелью.

Брендированное мобильное приложение

Брендированное приложение дает самую тесную прямую связь с гостями. Оно «живет» на главном экране телефона, помнит адреса и любимые заказы и позволяет отправлять push-уведомления о новых блюдах, акциях и статусе заказа. Через приложение удобнее всего выстраивать лояльность.

Приложение имеет смысл, когда гости заказывают часто. Но оно добавляет работы: публикация и обновление в App Store и Google Play, проверки магазинов приложений, поддержка новых версий iOS и Android. Обычно приложение строят на том же бэкенде, что и сайт, поэтому меню, цены и заказы остаются в одном месте. Если приложение в ваших планах, команда по разработке мобильных приложений поможет решить, запускать его сейчас или после сайта.

Сайт или приложение: как выбрать

Главный вопрос не «сайт или приложение?», а «как часто наши гости заказывают и сколько стоит каждый повторный заказ?». Ответить помогают четыре фактора:

• Частота заказов. Гости заказывают раз в месяц или несколько раз в неделю?

• Повторные клиенты. Какая доля заказов приходится на тех, кто уже заказывал раньше?

• Средний чек. Типичный заказ — это кофе или семейный ужин?

• Количество заведений. Одно заведение или растущая сеть?

Вот как эти факторы работают для трех типичных бизнесов.

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

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

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

Когда достаточно сайта

Сайта обычно достаточно, когда:

• у вас одно заведение или несколько точек;

• низкая частота повторных заказов и многие гости заказывают несколько раз в год;

• большинство новых клиентов находят вас через трафик из поиска и Google Maps;

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

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

Когда окупается приложение

Приложение обычно окупается, когда:

• у вас частые повторные заказы и гости заказывают каждую неделю или чаще;

• программа лояльности — ключевая часть бизнес-модели;

• push-уведомления могут приносить реальные заказы, например предложения на обед или напоминания в дни футбольных матчей;

• у вас несколько заведений и вы хотите одно приложение для всего бренда.

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

PWA как компромисс

Progressive web app (PWA) — это сайт, который ведет себя как приложение. Гость может выбрать «добавление на главный экран» и получить иконку на телефоне, сайт быстро грузится и работает даже со слабой связью, а офлайн-меню можно просматривать, когда сеть пропадает. Для Украины с ее перебоями связи во время отключений это имеет практическое значение.

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

Необходимые функции системы онлайн-заказов

Какой бы формат вы ни выбрали, системе онлайн-заказов нужен базовый набор функций. Вот они, с объяснением, зачем каждая.

Меню с модификаторами. Гостям нужно выбрать размер, тесто, дополнительные ингредиенты, «без лука», соус отдельно. Меню без нормальных модификаторов дает ошибочные заказы и звонки. Модификаторы также должны правильно считать цену и наличие.

Трекинг заказа. «Заказ принят», «готовится», «в пути», «доставлен». Трекинг снимает тревогу и звонки «где мой заказ?» и строит доверие к прямому каналу.

Заказ ко времени. Многие заказывают обед в офис или ужин на попозже. Заказы ко времени выравнивают нагрузку на кухню и возвращают заказы, которые иначе ушли бы в другое место.

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

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

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

Отзывы. Обратная связь в собственном канале помогает рано замечать проблемы и дает социальное доказательство новым посетителям.

Отзывы гостей после доставки. Короткий вопрос через час после доставки, например оценка от 1 до 5 и поле для комментария, дает кухне и менеджерам быструю обратную связь. Низкие оценки стоит видеть сразу, чтобы позвонить гостю и исправить ситуацию, пока он не написал об этом публично. Довольных гостей можно попросить оставить отзыв в Google.

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

Быстрое оформление. Сохраненные адреса, сохраненные способы оплаты, Apple Pay и Google Pay. Чем меньше шагов между «хочу есть» и «заказ оформлен», тем больше заказов.

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

Уведомления о статусе. SMS, push или сообщение в мессенджере, когда заказ принят, готов или в пути. Гость не звонит в заведение, а персонал не отвлекается от работы.

Админ-панель для заведения. Изменение меню и цен без разработчика, стоп-лист, управление зонами доставки и графиком, отчеты по заказам. Если обновление меню требует письма разработчику, система быстро устаревает.

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

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

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

Интеграции для онлайн-заказов

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

Вот что обычно нужно связать:

POS-система (Poster, Syrve). Заказы с сайта или из приложения сразу попадают в POS заведения с правильными позициями, модификаторами и ценами. Интеграция держит меню синхронизированным: когда блюдо закончилось, оно исчезает и из онлайн-меню.

Кухонный экран (KDS). Новые заказы появляются на экране кухни в правильной очереди, со временем приготовления и статусами. Кухня работает из одной очереди, независимо от того, откуда пришел заказ: из зала, с сайта или из агрегатора.

Онлайн-оплата. Оплата картой, Apple Pay и Google Pay через LiqPay, WayForPay или plata by mono. Данные карт обрабатывает платежный сервис, поэтому ваши системы не касаются самой чувствительной части.

ПРРО (Checkbox). Оплата картой на сайте через интернет-эквайринг, как правило, требует фискального чека. Программный РРО, например Checkbox, интегрируется с системой заказов и формирует чек автоматически после оплаты. Конкретные требования для вашей формы бизнеса стоит уточнить у бухгалтера.

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

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

CRM. Профили гостей, история заказов и предпочтения в одном месте. Именно это превращает заказы в отношения: персональные предложения, поздравления с днем рождения, кампании для тех, кто давно не заказывал.

GA4. Аналитика воронки заказа: просмотры меню, добавление в корзину, оформление, оплата. Без нее не видно, где гости отваливаются и какие кампании приводят заказы.

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

Зоны и время доставки. Доставка «по всему городу за час» редко правда. Разбейте город на зоны с разным временем, минимальной суммой и стоимостью доставки, показывайте гостю реальное ориентировочное время сразу после ввода адреса и честно меняйте его в пиковые часы. Система должна знать, когда кухня перегружена, и либо увеличивать время, либо временно закрывать удаленные зоны.

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

Стоимость и сроки собственного решения

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

Основные факторы стоимости:

• Формат. Сайт, сайт плюс PWA или сайт плюс нативные приложения для iOS и Android.

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

• Интеграции. Какую POS, платежный сервис, ПРРО, службу доставки, CRM и аналитику нужно подключить и есть ли у них удобные API.

• Лояльность и маркетинг. Баллы, реферальная программа, персональные предложения, push-уведомления.

• Количество заведений. Одна кухня или несколько, каждая со своим меню, зонами и графиком.

• Дизайн. Аккуратный интерфейс на основе шаблона или выразительный опыт бренда.

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

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

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

Что измерять после запуска. Полезные показатели: доля заказов через собственные каналы по сравнению с агрегаторами, конверсия из посещения меню в заказ, средний чек онлайн и офлайн, доля повторных заказов за 30 дней, среднее время от заказа до доставки и количество отмен. Эти цифры показывают, окупается ли собственный сервис и где теряются гости.

Кейс: сервис заказов Buddha Pizza

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

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

Чтобы опыт запоминался, мы добавили генератор заказов «Check Your Karma», который в игривой форме предлагает пиццу в соответствии с философией бренда. Вместе со смелыми текстами, выразительной анимацией и узнаваемым стилем он превратил обычный заказ в то, чем хочется поделиться. Историю проекта от первой идеи мы подробно рассказывали в статье Buddhapizza: пицца с заботой.

Технически проект построен на Laravel и PHP на бэкенде, Vue.js на фронтенде, базе данных PostgreSQL и REST API между ними. Такой стек позволил совместить насыщенный анимированный интерфейс с надежным бэкендом заказов. Если рассматриваете похожий стек, на странице разработка на Laravel объясняем, где он подходит лучше всего. От старта до запуска проект занял около четырех месяцев.

Результат превзошел ожидания. После запуска сайт быстро разлетелся по одесскому Facebook: люди делились ссылкой, потому что им было необычно и весело пользоваться. Проект получил награды Awwwards, CSS Design Awards, Web Awards UA и Ukrainian Design Awards. А главное, им пользовались гости, и клиент позже вернулся к нам с новым проектом. Детали есть в кейсе Buddha Pizza.

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

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