Запрос «нам нужно приложение» часто появляется раньше, чем ответ на вопрос «зачем». Конкурент выложил иконку в App Store, партнёр показал дашборд на смартфоне, собственник увидел рекламу «приложение под ключ за месяц». В итоге компания платит за приложение, которое никто не открывает повторно, а продажи по-прежнему идут через сайт, WhatsApp и звонки.
Проблема не в разработке как таковой. Проблема в том, что мобильное приложение — дорогой канал удержания и сервисный слой, а не витрина. Его имеет смысл заказывать, когда без нативных возможностей, повторных визитов или полевой работы бизнес теряет деньги. Если этой боли нет, приложение становится статусной тратой с ежегодной поддержкой.
Ниже — рабочая рамка для заказчика, внутренней IT-команды и компании, которая выбирает продукт для своих клиентов: зачем приложение вообще бывает нужно, как принять решение, какие ошибки повторяются и когда его сознательно не делать.
Зачем бизнесу приложение — не «потому что так принято»
Сайт отвечает на вопрос «кто вы и как с вами связаться». Приложение отвечает на другой: «как человек делает одно и то же действие снова и снова». Повторный заказ, статус доставки, смена слота, скан QR на объекте, push о готовности заказа, работа курьера офлайн — это сценарии, где иконка на экране экономит шаги.
Вторая причина — доступ к устройству. Камера, геолокация в фоне, NFC, Bluetooth, биометрия, офлайн-кэш, пуш-уведомления с высокой доставляемостью. Если продукт не использует ничего из этого списка, почти всегда хватает адаптивного сайта или PWA. Третья — операционка: сотрудники на складе, в салоне, на стройке не открывают CRM в браузере с ноутбука. Им нужен узкий инструмент под одну роль.
Практический фильтр: если пользователь заходит реже раза в неделю и каждый раз «с нуля» (узнать цену, оставить заявку, прочитать кейс), приложение почти наверняка избыточно. Если действие ежедневное или привязано к месту и устройству — разговор имеет смысл.
Кому это обычно нужно
- Сервисы с повторяющимися заказами: доставка, клиника, автосервис, образование, фитнес.
- Маркетплейсы и кабинеты, где клиент ведёт историю, чат, оплату, документы.
- B2B-поле: торговые представители, сервисные инженеры, приёмка на складе.
- Продуктовые компании, которые продают сам сервис, а не разовую заявку.
Нужно ли именно вам: критерии решения
Решение «делать / не делать» лучше принимать по пяти вопросам, а не по ощущению «мы современная компания». Запишите ответы письменно — это уже заготовка для брифа подрядчику или внутренней команде.
- Какое действие пользователь должен совершать чаще, чем раз в неделю? Если такого действия нет, сначала усиливайте сайт и процессы.
- Что ломается без приложения? Потеря заявок, долгий обзвон, ошибки в поле, низкий повторный чек, конкурент забирает удержание.
- Готовы ли вы к магазинам? Аккаунты разработчика, модерация, политика конфиденциальности, обновления под новые iOS и Android.
- Кто будет кормить продукт контентом и поддержкой? Без ответственного приложение устаревает за квартал.
- Есть ли данные и API? Каталог, статусы заказов, пользователи. Если источник — таблица «у менеджера в телефоне», сначала наведите учёт.
Для разработчиков тот же чек-лист звучит иначе: есть ли устойчивый backend, идентификация, роли, события аналитики. Без этого клиент в сторе — оболочка над хаосом. Для другой компании, которая внедряет продукт клиентам, добавьте вопрос white-label: одно приложение на всех или сборка под бренд каждого заказчика — это разные бюджеты.
Связанный выбор «сайт или приложение» разберите отдельно: см. статью сайт или приложение: что выбрать. Факторы бюджета — в материале о стоимости разработки приложения.
Как принять решение и с чего начать
Не стартуйте с выбора стека. Стартуйте с одного главного сценария на бумаге: кто пользователь, где он находится, что нажимает, какой результат считает успехом. Затем проверьте, нельзя ли закрыть сценарий сайтом, ботом или таблицей ещё 3–6 месяцев. Если нельзя — переходите к формату клиента.
Три рабочих формата, не один «стор»
- Мобильный веб / PWA — быстрые итерации, нет модерации магазинов, слабее пуши и доступ к железу.
- Кроссплатформа — один код на iOS и Android, разумный компромисс для большинства коммерческих продуктов.
- Натив — когда критичны производительность, сложные жесты, специфичные SDK платформы.
Дальше сузьте первую версию. Не «приложение компании», а «запись на услугу с напоминанием» или «статус заказа и чат с оператором». Остальное — backlog. Это та же логика, что у MVP: проверить ценность, а не выпустить витрину функций.
Соберите одностраничный бриф: аудитория, must-have, интеграции, кто принимает решения, как измерите успех через 30 и 90 дней. Без метрики (повторные открытия, заказы из приложения, время на задачу у сотрудника) вы не отличите «неудачный продукт» от «не довели до людей».
С чего начать на этой неделе: посчитайте, сколько повторных действий уже есть в бизнесе (заказы, визиты, заявки). Если повтор меньше 20–30% и вы не планируете его растить процессом, приложение скорее подождёт.
Подрядчику или своей команде отдайте не «сделайте как у конкурента», а сценарий, ограничения по платформам и критерии приёмки. Как формализовать требования — в статье как составить ТЗ на разработку. Направление работ по клиентам — разработка приложений, проверка гипотезы — разработка MVP.
Типичные ошибки
«Сначала дизайн всех экранов, потом подумаем, зачем». Красивый UI не заменяет ценность. Пользователь удаляет приложение, которое открывается ради той же формы, что на сайте, только с лишним шагом логина.
Вторая ошибка — две платформы «потому что так солиднее» при аудитории, которая на 90% в WhatsApp и не ищет вас в сторе. Публикация в магазине не создаёт спрос. Канал привлечения (реклама, QR в точке, рассылка клиентской базе) нужно планировать вместе с релизом, иначе скачивания будут нулевыми.
Третья — забыть админку, роли сотрудников и поддержку. Клиентское приложение без панели, где менеджер видит заказы, быстро превращается в ручной Excel плюс звонки разработчику. Четвёртая — экономия на тестах оплаты, пушей и плохой сети. В поле именно это ломается первым.
Ошибки, которые делают компании-заказчики для своих клиентов
- Обещать «приложение для всех ролей» в одном релизе: клиент, курьер, кладовщик, бухгалтер.
- Не закладывать бюджет на обновления ОС и модерацию — через год сборка не ставится на новые устройства.
- Копировать чужой UX без своего процесса: чужая корзина не равна вашей логике скидок и резерва.
- Игнорировать 152-ФЗ, согласия и политику в сторе — модерация отклоняет, запуск сдвигается.
Разбор со стороны постановки задач — в материале об ошибках заказчика при разработке.
Когда приложение не нужно
Не нужно, если бизнес живёт разовыми заявками: ремонт «под ключ», B2B-тендер раз в квартал, консультация юриста, продажа оборудования с длинным циклом. Здесь сильнее сайт, коммерческое предложение и CRM, а не иконка.
Не нужно, если нет повторного сценария и вы не готовы его строить маркетингом и сервисом. Приложение не научит клиента возвращаться, если товар одноразовый, а поддержка не отвечает.
Не нужно «для SEO». Поисковый трафик приходит на сайт. Приложение в магазине не заменяет посадочные страницы. Если цель — заявки из Яндекса, сначала сайт и SEO, см. также SEO для коммерческого сайта.
Не нужно внутренней команде из пяти человек, которая и так работает в браузере за десктопом. Мобильный клиент оправдан, когда руки заняты, сети нет или устройство — основной компьютер сотрудника.
Честный ответ «пока нет»: это нормальное управленческое решение. Отложенное приложение дешевле проваленного релиза, который все стесняются открыть.
Следующий шаг
Зафиксируйте один сценарий, частоту использования и то, чего не хватает сайту. Если после этой рамки ответ «да» — опишите must-have на одну-две страницы, выберите формат клиента (веб, кроссплатформа, натив) и критерии успеха на 90 дней. Если «нет» — усильте сайт, учёт заявок и повторные продажи, к приложению вернитесь с цифрами.
Нужна оценка scope — кратко в Grevin: grevin.info@mail.ru, +7 993 302-62-55, контакты.