Запуск собственного канала продаж для доставки еды: что нужно знать бизнесу и как избежать ошибок

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

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

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

Если бизнес планирует масштабироваться или запускать франшизу, без собственной цифровой инфраструктуры ошибки будут возникать все чаще, а рост будет очень медленным.

Как в примере с кафе: с ростом бизнеса владелец столкнулся с распространенной проблемой: агрегаторы помогли увеличить продажи, но 15-30% комиссии съедали прибыль, а клиенты оставались "чужими" – без истории заказов и возможности прямого контакта. Решение стало очевидным – пора запускать собственное мобильное приложение.

Но на практике всё оказалось сложнее.

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

Нестандартный учёт

Только в России рынок представляет около десятка систем внутреннего учета, которые позволяют управлять заказами, остатками, бонусами, аналитикой. Самые распространенные – iiko и R-Keepper, реже QuickResto – гибко настраиваются, упрощают работу персонала и адаптируются под задачи клиента, а значит, у каждого бизнеса есть свои нюансы, о которых стоит знать.

В чем могут быть отличия? Например, в одной сети заведений технологические карты блюд включают упаковку, салфетки, приборы – и это нужно учитывать. Модификаторы товаров в меню, их добавки и варианты, сортировка по категориям могут быть использованы самым разным образом: как реальные добавки, так и как вспомогательные элементы учета, например, для добавления тары, упаковки и дополнительных приборов (салфетки, пластиковые приборы) в заказ клиента.

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

Отсутствие отраслевой экспертизы у подрядчика

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

При выборе подрядчика, обращайте внимание на релевантные кейсы.

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

Неготовность компании

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

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

Подготовьте команду к цифровой трансформации.

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

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

Ограничения со стороны POS-систем

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

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

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

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

Учётная система (например, iiko) в таком подходе остаётся источником базовых данных. Номенклатура, остатки, приём заказов и отслеживание статуса – эти данные хранятся в iiko. А всё, что связано с внешним видом, UX (пользовательским опытом) и маркетингом, – выносится в отдельную административную панель, с которой может работать команда заказчика.

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

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

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

В такой архитектуре мобильное приложение получает информацию из iiko (номенклатура, остатки) и передаёт заказы на обработку. А всё, что видит пользователь приложения – внешний вид, акции, порядок отображения, состав корзины, – управляется централизованно из панели администратора и доставляется во все цифровые каналы продаж. Мобильное приложение при этом становится частью системы и полностью интегрируется со всеми процессами, что снижает вероятность ошибок и доработок в будущем.

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

Сделать приложение, которое встроится в бизнес – ёмкая задача. Она требует времени, внимания к деталям, готовности клиента и экспертизы со стороны подрядчика.

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