Мобильное приложение для бизнеса: когда оно окупается и чем его заменить

За что клиент согласится установить приложение

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

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

Главный вопрос — что человек будет делать снова. Повторить прежний заказ, увидеть состояние исполнения или выбрать свободное время полезнее, чем ещё раз прочитать историю компании, поэтому повод для возвращения формулируют через действие покупателя и проверяют на его обычной ситуации, а не через желаемое число экранов в презентации подрядчика. Установка требует отдельного усилия. Клиенту предстоит найти продукт, загрузить его и разобраться со входом. Если после этого он получает тот же каталог без дополнительного удобства, ценность такого перехода остаётся неясной.

Для такой компании я начал бы с повторного заказа, если его действительно часто оформляют вручную. У него можно сопоставить прежний путь и новый: сколько сведений требуется ввести заново и доходит ли запрос до исполнения. Это проверяемая задача. Общая цель «повысить лояльность» пока не объясняет ни состав разработки, ни способ приёмки.

Сайт, приложение или готовый сервис

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

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

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

Когда подходит готовый сервис

Готовый сервис становится моим первым кандидатом, когда его обычный процесс совпадает с работой компании и позволяет получить нужные данные. Это сокращает собственный объём поддержки. Если различия существенны, их описывают предметно: какой шаг нельзя выполнить, какие сведения теряются и почему обходной путь мешает покупателю. Ответ станет основанием для отдельной разработки.

Между обычным сайтом и отдельной разработкой стоит рассмотреть PWA — веб-приложение с возможностями, похожими на приложение устройства. MDN описывает его как продукт на веб-технологиях, который в том числе можно установить. Конкретные возможности зависят от реализации и среды. Для простой повторной заявки альтернативой может быть привычный клиенту мессенджер с ответственным за ответы. Я сравнил бы эти способы на одном действии: где человек быстрее завершает заказ и получает подтверждение от компании.

Как отделить полезную функцию от дорогого списка

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

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

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

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

Полезность требуется и при публикации. В правиле 4.2 App Store Apple просит функциональность и интерфейс, которые дают больше, чем переупакованный сайт. Это не обещание пройти проверку после добавления одной кнопки. Перед оценкой разработчик должен объяснить ценность приложения и ограничения выбранного способа распространения.

Публикация начинается с аккаунта компании

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

Условия зависят от площадки. В правилах регистрации Apple для организаций продавцом указано юридическое лицо. Для проверки обычно требуется D-U-N-S, исключение предусмотрено для государственных организаций. Представитель должен иметь полномочия связывать компанию соглашениями с Apple. Поэтому публикацию от имени компании нельзя молча подменить личной учётной записью исполнителя.

У Google Play есть личный и корпоративный типы аккаунтов, а проверки различаются в зависимости от выбранного типа. В RuStore управление приложениями происходит через Консоль с веб-интерфейсом и входом через VK ID. Эти различия проверяют до обещания единой даты запуска на всех устройствах, потому что доступность регистрации, подтверждение сведений и условия распространения относятся к конкретной компании и площадке, а наличие готового файла приложения не завершает этот путь.

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

Приёмка включает установку тем способом, который действительно получит клиент. Установку публичного выпуска клиентом испытывают отдельно от работы тестовой сборки у команды. Переход по ссылке, первый вход и получение помощи проверяют вместе. Тогда маркетолог планирует приглашение покупателей на действующий продукт, а не на техническую заготовку.

Что сравнить в стоимости владения

Смета на запуск не равна стоимости владения. После выпуска остаются обработка обращений, исправления, обновления и поддержание связей с учётной системой.

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

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

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

Окупаемость с учётом текущих затрат

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

Короткое задание до оценки разработки

До запроса окончательной цены достаточно описать одну проверяемую задачу. Такой бриф поможет получить сопоставимые предложения и увидеть неизвестные условия ещё до разработки.

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

Клиент: [кто возвращается и с какой задачей]. Сейчас он [как повторяет заказ и где теряет время]. В первой версии требуется [одно законченное действие] с актуальными условиями из [система или ответственный]. При потере связи пользователь видит [понятное состояние]; дубли обрабатываются [правило]. Компания проверит результат на [сопоставимые пользователи и события]. Каналы распространения: [площадки, устройства и подтверждённый способ публикации]. За аккаунты, содержание и поддержку отвечают [роли]. В оценке отдельно показать разработку, соединение с данными, публикацию, сопровождение и передачу обслуживания.

К брифу прикладывают прежний путь заказа и обезличенные примеры затруднений. Разработчику этого достаточно, чтобы задать предметные вопросы о данных и доступах. Если главный разрыв находится на сайте или в учёте обращений, сначала можно обсудить его со ШТАБ ИТ: решение о формате тогда опирается на работу клиента, а выбранная команда получает ясную границу задачи вместо пожелания сделать ещё один канал присутствия.