Онлайн-замовлення для ресторану: сайт чи додаток?

Для багатьох ресторанів і кафе онлайн-замовлення починалися як допоміжний канал і непомітно стали великою частиною виручки. Найшвидший шлях був очевидним: підключитися до 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 працюють разом: багато гостей шукають «піца поруч» саме на карті. Для одного закладу чи невеликої мережі сайт — часто найкращий перший крок до прямих замовлень. Такі рішення ми робимо в межах розробки веб-порталів і сервісів, від простих сайтів замовлення до платформ для мереж з адмін-панеллю.

Не забувайте про сторінку меню в Google Business Profile і посилання на замовлення там: багато гостей шукають заклад саме в Картах, і прямий шлях до вашого сайту з картки закладу забирає частину замовлень в агрегаторів.

Брендований мобільний додаток

Брендований додаток дає найтісніший прямий зв’язок з гостями. Він «живе» на головному екрані телефону, пам’ятає адреси та улюблені замовлення і дозволяє надсилати 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 і аналітики.

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

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

Вартість і терміни власного рішення

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

Основні фактори вартості:

• Формат. Сайт, сайт плюс PWA або сайт плюс нативні додатки для iOS і Android.

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

• Інтеграції. Яку POS, платіжний сервіс, ПРРО, службу доставки, CRM і аналітику треба підключити і чи мають вони зручні API.

• Лояльність і маркетинг. Бали, реферальна програма, персональні пропозиції, push-сповіщення.

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

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

Плануйте й поточні витрати: хостинг і підтримка, комісії платіжних сервісів, акаунти в магазинах застосунків, невеликі доопрацювання після запуску.

Щодо термінів, реалістичні середні такі. Сфокусований сайт замовлень як MVP з меню, кошиком, оплатою і базовою адмінкою зазвичай займає два-чотири місяці. Сайт з інтеграцією POS, зонами доставки і програмою лояльності займає три-п’ять місяців. Нативні додатки на вже готовому бекенді зазвичай додають ще два-три місяці. Почати з MVP часто найрозумніше: ви запускаєте основний сценарій замовлення, дивитеся, як ним користуються гості, і інвестуєте в наступні функції на основі даних. Саме так побудована наша розробка MVP для стартапів.

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

Що вимірювати після запуску. Корисні показники: частка замовлень через власні канали порівняно з агрегаторами, конверсія з відвідування меню в замовлення, середній чек онлайн і офлайн, частка повторних замовлень за 30 днів, середній час від замовлення до доставки і кількість скасувань. Ці цифри показують, чи окупається власний сервіс і де втрачаються гості.

Кейс: сервіс замовлень Buddha Pizza

Buddha Pizza — це бренд доставки піци з Одеси. Засновник прийшов до нас з чіткою проблемою: він втомився від холодної піци і байдужого сервісу і хотів створити доставку, яка відчувається зовсім інакше.

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

Щоб досвід запам’ятовувався, ми додали генератор замовлень «Check Your Karma», який у грайливій формі пропонує піцу відповідно до філософії бренду. Разом зі сміливими текстами, виразною анімацією і впізнаваним стилем він перетворив звичайне замовлення на те, чим хочеться поділитися.

Технічно проєкт побудований на Laravel і PHP на бекенді, Vue.js на фронтенді, базі даних PostgreSQL і REST API між ними. Такий стек дозволив поєднати насичений анімований інтерфейс з надійним бекендом замовлень. Якщо розглядаєте схожий стек, на сторінці розробка на Laravel пояснюємо, де він підходить найкраще. Від старту до запуску проєкт зайняв близько чотирьох місяців.

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

Що з цього кейсу можна взяти на свій проєкт? По-перше, коротший шлях до замовлення завжди виграє: кожен зайвий екран і кожне зайве поле коштують частини замовлень. По-друге, айдентика і сайт мають розроблятися як одне ціле, тоді сайт підсилює бренд, а не просто показує меню. По-третє, одна запам’ятовувана функція, пов’язана з характером бренду, дає більше, ніж десяток стандартних віджетів.

Висновок для інших закладів не в тому, що кожному сайту замовлень потрібні анімації і нагороди. Висновок у тому, що прямий канал замовлень працює найкраще, коли його спроєктовано навколо бренду і шляху гостя до покупки, а не скопійовано з шаблону.