Владелец сети из пяти точек подключает к своей iiko надстройку QR-меню с заказом и оплатой. На старте это выглядит как разовое решение за 5 000 ₽ (≈185 BYN) в месяц. Через пару месяцев выясняются две вещи. Первая: каждая следующая точка сети — это ещё 3 000 ₽ (≈111 BYN) в месяц, и счёт растёт вместе с бизнесом. Вторая, менее очевидная: логику, которая нужна именно этому заведению — свой сценарий вызова официанта, нестандартную связку с программой лояльности, — в готовом модуле настроить нельзя. Он делает ровно то, что заложил вендор, и ни шагом больше.
К этому моменту вопрос «нужен ли нам заказ по QR-коду» уже неактуален. Гости сканируют код, смотрят меню, дозаказывают десерт и платят с телефона — это давно норма. Настоящий вопрос звучит иначе: взять готовый модуль своей кассы или заказать разработку под себя. И ответ зависит от трёх вещей — числа точек, потребности в нестандартной логике и горизонта планирования.
Мы сами прошли этот выбор на продукте Foodclick: начинали с собственного мобильного приложения, а в итоге перенесли весь заказ в QR-код — так оказалось удобнее гостям в зале. К этому кейсу ещё вернёмся: он показывает, почему гибкость иногда перевешивает цену подписки.
Сколько на самом деле стоят iiko, Poster и r_keeper для QR-заказа
«Бесплатно» и «$7 (≈20 BYN) в месяц» выглядят как итоговая цена только на первый взгляд. Дальше начинается арифметика, которая у каждого вендора устроена по-своему: у iiko цена привязана к числу заведений, у Poster — к тому, входит QR в тариф кассы или подключается отдельно, а у r_keeper публичной цены на заказ по QR-коду нет вообще. Цены в BYN здесь и далее приведены для сопоставимости — по курсу НБ РБ на июль 2026 (USD ≈ 2,89 BYN, российский рубль ≈ 0,037 BYN).
iiko. На официальной странице QR-меню (актуально на 28.07.2026, store.iiko.ru/qr-menu) действуют две версии. QR-меню только для просмотра блюд — бесплатно. Версия с заказом и оплатой — 5 000 ₽ (≈185 BYN) в месяц для первого заведения и 3 000 ₽ (≈111 BYN) в месяц за каждое следующее, первый месяц бесплатный. Если заведение уже работает на iikoCloud, QR-меню включено сразу. Ключевой момент — цена масштабируется по точкам: для одной кофейни это одна сумма, для сети из пяти заведений с заказом и оплатой набегает 5 000 + 3 000 × 4 = 17 000 ₽ (≈629 BYN) в месяц.
Poster POS. По официальному прайсу (актуально на 28.07.2026, joinposter.com/en/pricing) функция «QR-меню и отзывы» входит уже в начальный тариф Mini — от $26 (≈75 BYN) в месяц при годовой оплате (или $29, ≈84 BYN, помесячно) — и присутствует во всех тарифах выше. Отдельно QR-меню продаётся как надстройка Poster QR за $7 (≈20 BYN) в месяц: готовый QR-код, меню с автосинхронизацией ассортимента и цен из Poster, без затрат на разработку. Дополнительная касса стоит $19 (≈55 BYN) в месяц. Poster заявляет более 30 000 точек по миру и работает в том числе в Беларуси.
r_keeper. Публичного прайса на заказ по QR-коду у вендора найти не удалось, и это стоит назвать прямо: так устроена бизнес-модель вендора. r_keeper ориентирован на крупные сети и продаёт через отдел продаж по индивидуальному запросу. Само по себе это показательно: чем крупнее и закрытее платформа, тем меньше самообслуживания в самом процессе покупки — и, как правило, тем длиннее путь от «хочу заказ по QR-коду» до работающего решения.
| Вендор | QR только просмотр | QR с заказом и оплатой | Как растёт цена |
| iiko | Бесплатно | 5 000 ₽/мес (≈185 BYN) за 1-е заведение | +3 000 ₽/мес (≈111 BYN) за каждое следующее |
| Poster POS | Входит в тариф Mini (от $26/мес, ≈75 BYN) | Входит в тариф; отдельно Poster QR — $7/мес (≈20 BYN) | По числу касс/точек, тариф на аккаунт |
| r_keeper | Нет публичного прайса | Нет публичного прайса | Только индивидуальный расчёт |
Как касса связана с остальным стеком заведения — POS, KDS, лояльностью и доставкой — мы разбирали в обзоре технологий ресторана в 2026. А как удержать стабильность самого потока онлайн-заказов при росте — в материале «Онлайн-заказы без сбоев».
Что вы не сможете настроить в готовом QR-модуле
Готовый модуль закрывает типовой сценарий: гость сканирует код, видит меню, выбирает блюда, заказ уходит на кассу, гость платит. Пока задача укладывается в эту схему, модуль отрабатывает её отлично и дёшево. Потолок начинается там, где в логике заказа появляется правило, специфичное для конкретного бизнеса.
Пример из нашей практики — продукт Foodclick. Изначально мы задумывали его как полноценное мобильное приложение: вызов официанта, чаевые, отзыв о визите, бронирование стола. Всё, что положено хорошему ресторанному приложению. А потом столкнулись с поведением гостей, которое шло наперекор всей затее. Как это сформулировал наш разработчик:
Мы поняли, что клиенты в заведениях не хотят ничего скачивать. Поэтому сделали всё через QR-коды
Мы полностью пересобрали подход и перенесли весь функционал на QR-код — без установки приложения. Полную историю этого решения и остальные шесть выводов о создании продукта для ресторанов мы описали в отдельном разборе «7 уроков для тех, кто хочет создать SaaS-продукт для ресторанов». Здесь важно другое: такой разворот — от приложения к QR — невозможно быстро протестировать и переделать на готовой платформе с чужой, зашитой логикой. Мы могли менять сценарий гостя столько раз, сколько требовалось, потому что логика была наша.
Зависимость от вендора: что вы получаете вместе с готовым модулем
Готовый модуль — это постоянная связка с чужим бизнесом. Вместе с удобным QR-меню вы берёте на себя чужой тариф, чужой график обновлений и чужие ограничения API. API (программный интерфейс, через который системы обмениваются данными) у готовой платформы ровно такой, каким его сделал вендор: если нужного метода в нём нет, добавить его вы не можете — только ждать, пока это сделает вендор, если вообще сделает.
У каждого из трёх вендоров зависимость выглядит по-своещему. У iiko она денежная и линейная: цена растёт вместе с числом точек, и на большой сети подписка превращается в заметную постоянную статью расходов. У Poster модуль QR привязан к тарифу кассы — вы платите не только за QR, но и за всю обвязку тарифа, в котором он лежит. У r_keeper зависимость начинается ещё раньше, на входе: без отдела продаж вы даже не узнаете цену, а значит, и планировать бюджет самостоятельно не сможете.
Та же логика «строить или купить» применима не только к софту. Мы разбирали её на примере физического железа в материале «Почему рестораны выбирают кастомную разработку киосков самообслуживания» — там речь про капитальные затраты на терминалы, но выбор ровно такой же. А похожий управленческий выбор между готовым решением и своим — но уже про доставку — мы собрали в статье «Что выбирают QSR — агрегаторы или собственную доставку».
Когда кастом действительно окупается
Универсального ответа «стройте своё» или «берите готовое» не существует — есть выбор, который можно посчитать. Прогоните своё решение через четыре вопроса.
- Число точек. Для одного-двух заведений с типовым сценарием заказа готовый модуль почти всегда выгоднее: подписка небольшая, разработка не нужна вовсе. Чем больше точек, тем быстрее подписка накапливается в сумму, сопоставимую с разовой разработкой.
- Потребность в нестандартной логике. Если бизнесу нужен свой сценарий вызова официанта, особая связка с программой лояльности или правило, которого нет в готовом модуле, вопрос цены отходит на второй план: готовый модуль этого просто не умеет, и никакая экономия на подписке не компенсирует отсутствие нужной функции.
- Объём заказов. Чем выше поток, тем дороже обходятся мелкие ограничения чужой логики: секунды на лишнем шаге и сбои синхронизации на потоке превращаются в реальные потери.
- Горизонт планирования. Подписка — это платёж навсегда, разработка — разовое вложение с последующей поддержкой. На горизонте одного года подписка почти всегда дешевле. На горизонте двух-трёх лет для сети картина часто переворачивается.
| Ситуация | Что обычно выгоднее |
| 1–2 точки, типовой сценарий заказа | Готовый модуль кассы (iiko/Poster) |
| Сеть из нескольких точек, типовой сценарий | Считать накопленную подписку против разовой разработки |
| Нужна нестандартная логика заказа/лояльности | Кастомная разработка почти всегда |
| Своя продуктовая амбиция (как Foodclick) | Кастомная разработка |
Именно этот выбор мы уже проходили на Foodclick: в какой-то момент нужная логика перевесила любой расчёт по подписке, потому что готовая платформа её просто не поддерживала. Как считать полную интеграцию стека и когда она окупается — в обзоре технологий ресторана в 2026, а как оценивать устойчивость роста числа заказов — в материале «Онлайн-заказы без сбоев».
Что реально нужно для своей системы QR-заказа
Кастомная разработка системы заказа по QR-коду — это понятный интеграционный проект с предсказуемым объёмом работ, а не прыжок в неизвестность. Вот из чего он складывается.
Динамические QR-коды. Статичный QR ведёт на один и тот же адрес всегда — его удобно напечатать один раз, но нельзя привязать к конкретному столу или заказу, и его легко подделать наклейкой поверх. Динамический QR генерируется системой под конкретный контекст: стол №7, текущая сессия, открытый счёт. Это и защита от подмены, и точная привязка заказа к месту — гость сканирует код на своём столе и попадает ровно в свой заказ.
Передача заказа в реальном времени. Реальный поток данных выглядит так: скан → меню → заказ → касса и кухня → оплата. Заказ должен уходить на кассу и на кухню мгновенно, иначе гость нажал «заказать», а на кухне пусто. Именно в этом звене готовые модули чаще всего упираются в потолок чужой логики.
Интеграция оплаты и админ-панель. Оплата с телефона подключается через платёжного провайдера, а меню, стоп-листы и цены редактируются в собственной админ-панели — той, где у вас полный контроль над логикой, а не только над картинками блюд.
Интеграция с любой кассой через API. Кастомную систему заказа по QR-коду можно построить как надстройку практически над любой кассой через API-интеграцию — то есть подключить её к существующей кассовой системе, не меняя саму кассу. Это снимает ложную дилемму «либо меняем кассу, либо сидим на её QR-модуле».
Полный разбор того, как создавался Foodclick, — в материале «7 уроков... опыт Foodclick». Аналогичный разбор кастомной разработки для другого канала заказа — в статье про кастомные киоски самообслуживания.
FAQ
Что в итоге
Готовый модуль заказа по QR-коду — быстрый и дешёвый способ закрыть типовой сценарий на одной-двух точках. Кастомная разработка окупается там, где растёт число точек, где нужна логика, которой в готовом модуле нет, и где бизнес планирует не на год, а на несколько лет вперёд. Мы прошли через этот выбор на собственном продукте Foodclick и знаем, где именно готовое решение упирается в потолок.
Хотите понять, какой сценарий выгоднее именно вашему заведению или сети? Свяжитесь с нами — разберём вашу кассу, число точек и нужную логику, а расчёт по чужому прайсу оставим в стороне.
