Как запустить проект с сайтом и приложением

Денис Гордиенко, руководитель Bright Mobile, о проблемах, которые ждут руководителя бизнеса, когда идёт комплексная разработка ИТ-продукта, состоящего из сайта, приложения и интеграций со сторонними API.

Ozon, YouDo, Avito. Мы уже привыкли к тому, что у крупных сервисов есть и сайт, и приложение. Причём, сделанное практически полнофункционально: что есть на сайте, то дублируется и в приложение. Во второй половине 2019 года, вижу и в заказной разработке подобный тренд. Основатели все чаще приходят не только за приложением, а за целой системой: чтобы был сайт, приложение, и всем этим можно было управлять из единой панели (в одном из сервисов предполагалось аж 4 роли админа). Сегодня и пойдёт речь о нюансах в разработке таких проектов.

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

Ранее мы запускали проекты на webview-движке Сервис ПИ (модуль к 1С-Битрикс). Там говорить о полном функционале было легко - по факту менялся только адаптивный шаблон. В начале этого года перевели разработку на Ionic.Framework, а ядро переписали с нуля, получив RTPlatform. Хоть движок стал работать быстрее/круче/веселее, но фишка с функционалом сразу и на сайте, и в приложении пропала - нужно как минимум делать отдельный шаблон, а как максимум переделывать экран с нуля, оставляя только API.

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

Опросив 10 основателей, за месяц понял, что некоторые вещи, конечно, зависят от специфики бизнеса, но 80% - это общие правила для всех.

Внешний вид

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

SEO

SEO - это главное преимущество сайтов перед приложениями, поэтому, принебрегать его использованием не стоит. SEO продвижение на порядок дешевле, чем контекстная и прочая cpp реклама, где нужно платить за клики, показы, переходы. Для этого применяются разделы Новостей, Блога или Статей.

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

Личный кабинет

Этот раздел у меня под вопросом, потому что сильно зависит от специфики проекта. Если пользователь что-то покупает или заказывает на сайте и ему нужно отслеживать заказ, иметь возможность написать исполнителю и т.п., то раздел нужен. Если это не принципиально, то нет. Наглядный пример - такси. Вы заказываете мотор с приложения или с сайта? У Яндекса, например, есть и то, и другое, а запуская новый агрегатор делать заказ с сайта было бы излишней тратой денег.

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

В приложении важна оперативность передачи или получения данных. Для сравнения, у вебщиков загрузка страницы в 5 сек считается нормой, а для крупных проектов даже хорошим результатом, а для мобильщиков, если экран грузится больше 2-х сек, то уже зашквар. С учётом того, что единый функционал в приложении стоит дороже сайта, то приложение используется в проектах, где нужно оперативно выцеплять пользователя (push) или точно работать с его локацией (gps).

Push

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

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

GPS

Актуально, примерно в 70% случаях. Если основная идея продукта в том, чтобы найти или трекать ближайшего кого-то или что-то, то это всё выносится в приложение. На вскидку, в этом году запускали вот такие идеи, где GPS был, как кровь из носу:

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

Заказчики оставляют заявки, администратор перезванивает, уточняет детали. Исполнители уже получают подготовленную заявку, где отражена вся необходимая для них информация.

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

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

Запускать и сайт, и приложение, для пользователей и исполнителей - дорого. А, если есть работающий сайт, то бессмысленно, с точки зрения продвижения. Зачем тратиться на новый сайт, когда уже есть трафик на старом?

В таких случаях я рекомендую делать следующее.

Доработка сайта. На сайте добавляется виджет для сбора заявок, вместо обычной формы обратной связи. Она отправляет заявку не в админку или почту, а в CRM или админку управления заказами.

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

Приложение. Приложение в минимальной версии нужно только мастерам. Там они настраивают профиль, получают заявки по своей специализации и отчитываются за выполнение. Получается такой мини-планадо, только в своей отрасли.

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

Вроде бы выходит логика работы стандартного маркетплейса с промежуточным звеном, но за счёт готового сайта получается существенная экономия:

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