{"id":14277,"url":"\/distributions\/14277\/click?bit=1&hash=17ce698c744183890278e5e72fb5473eaa8dd0a28fac1d357bd91d8537b18c22","title":"\u041e\u0446\u0438\u0444\u0440\u043e\u0432\u0430\u0442\u044c \u043b\u0438\u0442\u0440\u044b \u0431\u0435\u043d\u0437\u0438\u043d\u0430 \u0438\u043b\u0438 \u0437\u043e\u043b\u043e\u0442\u044b\u0435 \u0443\u043a\u0440\u0430\u0448\u0435\u043d\u0438\u044f","buttonText":"\u041a\u0430\u043a?","imageUuid":"771ad34a-9f50-5b0b-bc84-204d36a20025"}

No-code подход в мобильной разработке: будущее или мелкая ниша?

Меня зовут Алексей Жилин, я основатель агентства мобильной разработки SMD Agency, а также сооснователь стартапа Wiby, размышления о котором и натолкнули меня на написание этой статьи. Wiby - это сервис, в котором рестораны и доставки еды могут получить нативное мобильное приложение с бэк-офисом и интеграциями с основными CRM этой отрасли для своего ресторана или сервиса доставки еды. Вместо многомиллионного бюджета на разработку и дальнейшую поддержку своего приложения, наш сервис предлагает подписку от 4900 рублей в месяц. Мы совсем недавно начали свою деятельность и целью этой заметки вижу рассказать свои наблюдения и получить обратную связь от заинтересованной аудитории.

Существующие решения на рынке

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

Napsy - более универсальная модель, для ecommerce в целом.

Loyaltyplant - больше упор на систему лояльности, но много интересных клиентов в нашей нише.

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

Общий сценарий работы с нашим и аналогичными сервисами выглядит следующим образом: клиент регистрирует аккаунт, вносит контент своего приложения (товары, акции, статичная информация), при необходимости запрашивает интеграции с внутренними системами своей компании, оплачивает выбранный тариф и приложение публикуется в Play Google и AppStore. Все обновления и фиксы выпускаются автоматически для всех подключенных к сервису компаний. Заказы поступают либо в личный кабинет сервиса, либо в CRM с которой проведена интеграция. Казалось бы - все логично, и спрос должен быть высокий, ведь мы предлагаем клиентам качественное решение в десятки раз дешевле. Но масштаб существующих решений с точки зрения количества подключенных компаний совсем не впечатляет: речь не идет о тысячах подключенных компаний, максимум о 2-3 сотнях. Отсюда вопрос:

Почему в сфере мобильных приложений нет такого спроса на подобные сервисы, по аналогии с wix или tilda в веб отрасли?

  • Когда мы начали общаться с реальными клиентами, нам стало ясно, что ценность мобильного приложения как такового ясна в полной мере только крупным компаниям, которые могут себе их позволить, и нам - тем, кто их разрабатывает. Мы начинаем говорить о деталях, а клиент не понимает - зачем оно в принципе? И это вполне оправдано - небольшим компаниям не всегда нужно приложения, они попросту не имеют нужного уровня компетенций, чтобы использовать этот инструмент эффективно. В этой части мы пришли к тому, что помимо продвижения конкретно своего решения, необходимо иметь некую образовательную миссию - рассказывать, зачем бизнесу нужно приложение, как увеличить прибыль и уменьшить цену лида с помощью него.
  • Даже небольшие компании, по каким-то очень невнятным причинам хотят «свое» решение. Кто-то ошибочно считает, что выгоднее заплатить один раз, и не учитывает постоянную поддержку проекта на плаву, актуализацию кодовой базы. У кого-то невероятные амбиции касаемо функциональности проекта, и в приложении нужно либо все, либо ничего. Этот пункт тоже можно отнести к необходимости образовательной функции в продажах и маркетинге подобных решений.

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

0
80 комментариев
Написать комментарий...
Andy Avramenko

Привет, мы в сети dark-kitchen ресторанов OKRA25 тоже делаем своё мобильное приложение и не используем волшебные nocode платформы.

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

Ресторану нужно не мобильное приложение, ему нужны заказы. Агрегаторы это дают, а вы нет. Если кто-то делает собственное, то знает зачем - например, конвертить из офлайна в онлайн. Гости офлайн ресторана будут скачивать приложение для лояльности, а ресторан потом будет присылать офер на доставку (кейс кофемании, например). У вас это есть?

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

Ответить
Развернуть ветку
Алексей Жилин
Автор

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

Ответить
Развернуть ветку
Andy Avramenko

Алексей, так устроен этот несправедливый мир, если ты даёшь ценность - можешь брать 20-35%, если не даёшь, то даже если будете доплачивать, никто пользоваться не будет.

Скажите мне лучше еще один момент, а с чем вы интегрированы, потому что тезис "добавить блюда в каталог" меня пугает. С iiko и аналогами есть интеграция? Если нет, то мало того что заказов нет от вас, так еще и вручную нужно стоп-листы держать?

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

Ответить
Развернуть ветку
Алексей Жилин
Автор

Да, у нас есть интеграция с iiko и r-keeper, которая позваляет синхронизировать стоп-листы, отправлять заказы из приложения напрямую в CRM предприятия и не вносить все позиции в ручную, в случае если в iiko они все внесены в корректном виде.

Ответить
Развернуть ветку
Grigoriy Malyshev
в случае если в iiko они все внесены в корректном виде

Так бывает?

Ответить
Развернуть ветку
Алексей Жилин
Автор

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

Ответить
Развернуть ветку
77 комментариев
Раскрывать всегда