Всем привет! Меня зовут Олег Неклюдов, я работаю в МойСклад, крупнейшем SaaS-сервисе для торговли в России.
Мы автоматизируем управление торговлей для малого и среднего бизнеса уже 13 лет. Сейчас мы создаем маркетплейс приложений, чтобы представить сообщество различных сервисов, функционально связанных с нашим продуктом.
Рынок имеет несколько задач.
Во-первых, необходимо расширить возможности пользователей нашего сервиса с помощью приложений вендора.
Необходимо интегрировать сервис с другими продуктами.
Маркетплейс также поможет небольшим девелоперским компаниям выйти на рынок и получить прибыль, а также сократить затраты на продажи и маркетинг.
Наш продукт — это массовый сервис для торговли, а потому мы имеем доступ к полуторамиллионной аудитории представителей малого и среднего бизнеса: владельцев розничных и интернет-магазинов, оптовых компаний и небольших производств.
Ежедневная аудитория сервиса — 60 000 пользователей.
Клиенты могут работать с сервисом на всех платформах и устройствах.
Благодаря обширной базе пользователей и использованию API любой разработчик может сделать приложение для нашей аудитории.
Рынок.
Предварительные условия Два года назад у нас были хорошие стартовые позиции.
Во-первых, для реализации маркетплейса нужен хороший функциональный API, чтобы разработчики могли получать необходимые данные и автоматизировать процессы.
У нас уже был такой API. 
Во-вторых, наши партнеры уже разработали несколько десятков интеграций.
В-третьих, работало столько же собственных интеграций — мы делали то, что считали востребованным для наших клиентов: обмены с банками, интеграции с почтовыми сервисами, телефонией, движками для интернет-магазинов.
В-четвертых, наша большая база пользователей, часть из которых покупает интеграции и приносит деньги.
Мы поняли, что для клиента не имеет значения, чье решение он будет использовать, наше или партнерское: пользователь просто заходит на витрину приложения и выбирает то, что ему нужно.
Мы посмотрели на рынок и увидели, что у многих крупных SaaS-сервисов уже есть маркетплейс.
Это подтвердило эффективность такой модели и наличие адекватных льгот для всех участников проекта.
Кому нужен маркетплейс
И для нас, и для вендоров, и для наших пользователей, но по своим причинам.Зачем маркетплейсу нужен b2b-сервис? Во-первых, это повышает лояльность пользователей за счет увеличения полезного функционала, позволяя более полно автоматизировать бизнес-процессы.
Во-вторых, это деньги — увеличение среднего чека от продажи платных приложений плюс основная подписка.
В-третьих, стратегические для нас вещи: движение продукта в сторону ИТ-платформы, появление новых точек расширения и увеличение возможностей гибкой кастомизации.
Зачем вендору маркетплейс?
У нас есть два типа продавцов.
Первые зарабатывают на приложениях и внедрениях.
Они ориентированы на создание платных приложений.
И они хотят продать их через нас.
Вторые — это поставщики услуг, такие как курьерские компании и другие услуги SaaS. Они берут деньги за свои услуги и заинтересованы в получении доступа к огромной аудитории нашего продукта.
Они делают это через бесплатные приложения.
Почему торговая площадка служит пользователю? Клиенты получают расширенный функционал для бизнеса, могут выбирать из ряда интеграций и самостоятельно «дополнять» наш продукт, используя новые точки расширения.
Это приводит к большему удовлетворению от услуги и повышению лояльности к ней, а также это влияет на финансовый результат.
Стратегия развития маркетплейса
Важное замечание: клиентом торговой площадки является поставщик, а не пользователь услуги SaaS! Все просто — именно вендор вкладывает свои ресурсы в разработку приложения.По сути, вендор арендует место внутри нашего сервиса, публикует приложение и платит аренду в виде процента от пользовательских платежей.
Продавец сам определяет, какую продукцию он хочет выпустить на рынок.
Мы стремимся иметь больше приложений на рынке и чтобы они приносили деньги/установки — здесь мы говорим лишь косвенно о клиентах сервиса SaaS. Весь упор делается на сайт, вендоров и приложения.
Первые шаги мы делали с партнерами, которых давно знаем.
У них уже были хорошие интеграции с нашим продуктом, и мы предложили им упаковать готовые решения в маркетплейс-приложения, опубликовать их и попробовать заработать.
Обсудили, что должно быть в продукте — провели полноценную клиентскую разработку.
Мы не только говорили о наших требованиях к интеграциям, но и пытались понять, какими техническими возможностями должна обладать наша платформа для реализации этих интеграций.
Практически сразу у нас сформировался подход: планируя разработку той или иной фичи маркетплейса, мы сразу смотрим, какие конкретные приложения будут использовать эту фичу.
Наша цель — минимизировать, а в идеале свести к нулю время от выпуска функции до первых опубликованных приложений, использующих эту функцию.
Так мы обеспечиваем эффективность нашего процесса разработки с точки зрения продукта на этапе планирования.
И не только через показатель использования выпущенных функций, но и через проектирование реализации исходя из конкретных случаев.
Как мы выбираем участников маркетплейса и фичи для разработки
Если к нам обращается вендор с желанием сделать приложение для нашего маркетплейса, но на платформе требуются доработки/функции, мы оцениваем приоритетность этих доработок, исходя, в том числе, из потенциального спроса на эти приложения.Не каждый поставщик к нам придет: идет еще процесс отбора.
В первую очередь мы ориентируемся на уровень полезности приложения для наших пользователей и потенциальный доход. Размер рынка важен.
Во-вторых, важно посмотреть на текущие планы развития компании в целом и согласовать их с планами рынка.
Это позволяет максимально эффективно двигаться вперед, используя результаты работы других команд и не дублируя один и тот же функционал в разных частях системы.
Например, мы используем нашу единую систему биллинга в маркетплейсе для приложений и единый сервис аутентификации партнеров для личного кабинета вендора.
Также важно понимать сроки выхода приложения — не стоит затягивать реализацию.
Еще у нас есть внутренний мотиватор, который заставляет нас активно наполнять рынок — корпоративные OKR, мы их поставили себе в прошлом году.
Они предполагают вполне конкретные цифры, для достижения которых мы должны постоянно ускоряться.
Уже в 2019 году в OKR было зафиксировано: 20 приложений, разработанных вендорами, и 700 установок новых приложений на активных аккаунтах в сервисе.
В 2020 году у нас уже более 5000 установок, около 70 вендоров зарегистрированы в личном кабинете и занимаются разработкой приложений.
У нас пока не так много вендоров, а значит, «поляна» пуста с точки зрения конкуренции.
По планам на год есть рост доходов от приложений, и тут понятно, что если они растут у нас, то и у вендоров тоже.
Также мы расширяем возможности встраивания в пользовательский интерфейс сервиса, и это открывает принципиально новые возможности для приложений.
Люди будут видеть их постоянно и постепенно привыкнут к их использованию.
Это станет драйвером роста в 2020 году.
История запуска торговой площадки
Все началось с разработки API, и первые версии были не совсем успешными.Теперь у нас есть JSON API, который приобрел популярность и активно развивается.
Он обеспечивает доступ к подавляющему большинству объектов пользовательской информации.
Вы можете читать, удалять, обновлять и создавать все.
Это открывает очень большие возможности для интеграции и функциональности приложений.
Мы гарантируем обратную совместимость наших API, обеспечивая плавную интеграцию.
Несколько лет назад мы также разработали специализированные API для облачной телефонии и систем лояльности — мы можем быстро подключать новых вендоров в этих сферах.
Объединив на одной странице наши интеграции и первые интеграции для телефонии и систем лояльности партнеров, мы получили первую витрину приложений.
Это еще не был полноценный маркетплейс, так как они публиковались разработчиками вручную, там были только узкоспециализированные приложения от сторонних вендоров, а размещать интеграции «общего назначения» (с использованием JSON API) от третьих сторон не было возможности.
-сторона разработчиков.
Пришло время создать рынок.
Первая попытка создать маркетплейс
И она оказалась неудачной.Почему? Во-первых, не хватало ресурсов.
Мы не рассматривали маркетплейс как отдельный и самодостаточный продукт: это была просто одна из эпопей в общей разработке продукта.
И теперь все по-другому Сейчас есть отдельная команда маркетплейса со своим продуктом, разработчиками и тестировщиками.
В составе семи человек мы применяем и разрабатываем все необходимое для создания крупного ИТ-супермаркета.
Мы начали развивать маркетплейс с переноса на него существующих приложений телефонии — чтобы с чего-то начать, создавать структуры и все это бутстрапить.
Затем мы упаковали некоторые решения в очень простые iframe-приложения: показали сторонние сервисы во вкладках внутри нашего сервиса.
Для этого мы выбрали двух первых пользователей, с которыми провели простую интеграцию.
Это был простой и эффективный шаг — нужно было, чтобы первые поставщики появились у нас как можно быстрее и смогли убедиться, что все работает хорошо.
Опасения здесь понятны — не все хотели вкладываться в разработку «не попробовав», но эти очень простые приложения позволяли понять, заинтересованы ли наши клиенты.
Пример такого поставщика — сервис «на_полке».
Максимально быстро выпустив первые приложения на рынок, мы подогрели интерес других вендоров.
Далее мы сделали возможным хостинг полноценных приложений, которые после установки начинают обмениваться данными с сервисом через наш JSON API. По сути, это был наш MVP. На этапе появления MVP мы построили специальную среду, которую называем Песочницей.
Мы внедряем в него крупные функции в альфа-версиях, чтобы вендоры могли заранее начать разработку и отладку своих приложений применительно к этим функциям.
Так мы реализуем смысл нашей стратегии — выпустить большую фичу вместе с приложениями.
В случае с MVP было так: на момент выхода в производство разработка и отладка приложений вендорами в «Песочнице» уже шла полным ходом, и некоторые решения были уже готовы.
В результате между выходом MVP и публикацией первых приложений к нему прошло всего несколько дней.
Следующим шагом стало добавление в маркет платных приложений с самым простым вариантом тарификации в стиле Fix Price — стоимостью 500 рублей в месяц.
Такое упрощение позволило нам максимально быстро запустить продажи на рынке.
Поначалу на сайте не было личного кабинета продавца.
Взаимодействие с ними осуществлялось вручную: поставщики передавали нам информацию, мы вводили ее через внутреннюю админку.
Это хорошо сработало для небольшого числа поставщиков и позволило сократить время выпуска MVP. Теперь вендор может самостоятельно создавать и управлять приложениями в маркете через личный кабинет. После выхода первой версии личного кабинета вендора мы вернулись к активной разработке платных приложений и сделали несколько важных функций:
- пробный период для платных приложений — позволяет клиентам бесплатно устанавливать и использовать их от 1 до 14 дней.
Срок определяется поставщиком;
- перевод приложения из бесплатного в платное по требованию производителя - без этой функции приходилось удалять бесплатное приложение и публиковать такое же, но уже платное.
При этом существующие пользовательские настройки были потеряны.
Сейчас они уже сохраняются;
- расширены возможности ценообразования: теперь приложения могут стоить не только 500 рублей в месяц.
Что теперь?
Мы продолжаем двигаться и работать над увеличением количества вендоров (кстати, применять )! Мы не замедляем темпы выпусков продуктов: мелких есть много, но они постоянны.Основное направление, над которым мы сейчас работаем, — это возможность гибкой интеграции приложений в UI сервиса.
Мы начали с виджетов — позволяем приложениям встраивать части пользовательского интерфейса в карточки контрагентов, товаров, заказов и других объектов.
Многим производителям действительно не хватает этой функциональности.
Не будем ограничиваться виджетами: на очереди пользовательские действия и столбцы в списках сущностей и документов, модальные диалоги, возможность общения между виджетами одного приложения, повторное использование приложениями существующих объектов интерфейса сервиса, например, селекторов и диалоговые окна и многое другое.
Мы ведем разработку виджетов через кейсы поставщиков.
Мы сами решили встать на место этих компаний и реализуем большую прикладную функцию основного продукта в виде отдельного приложения, активно использующего функционал виджетов.
Мы решили убить двух зайцев одним выстрелом.
С одной стороны, мы создаем полезную функцию для пользователей – она востребована оптовыми компаниями и клиентами нашего сервиса.
С другой стороны, делая фичу в виде собственного приложения для маркетплейса, которое встраивает свой виджет в карточку контрагента, мы продолжаем гонять механизм виджета в платформе под конкретный случай.
Но, конечно, есть и несколько кейсов от вендоров.
И немного лайфхаков
Могу я? У вас есть свой продукт, например, SaaS-сервис, и вы задаетесь вопросом, пора ли создавать маркетплейс или еще рано? Рассмотрим две вещи.Первый — это варианты интеграции с вашим продуктом и API для разработчиков.
Во-вторых, у вас должно быть достаточное количество пользователей, чтобы поставщики были заинтересованы в создании приложений для вашего рынка.
Могу, но что мне делать дальше? Решать:
- кто и как будет создавать и развивать маркетплейс: будет ли это отдельная команда или придется использовать ресурсы коллег, которые занимаются другими задачами;
- где найти поставщиков с приложениями;
- что делать в первую очередь;
- как поставщики будут отлаживать приложения во время разработки и какие инструменты им понадобятся для поддержки приложений после публикации.
- вопрос продукта — что вы хотите делать и для кого;
- риски: не дублируйте то, что делает сам сайт; с ним может быть сложно конкурировать;
- требования к приложениям и другие политики рынка.
Их необходимо знать, чтобы разработанное приложение было опубликовано.
Если есть сомнения, нужно связаться с рынком и все обсудить;
- поддержка клиентов: все это будет на вашей стороне;
- маркетинговая деятельность: убедитесь, что вас продвигают по службе.
- Мы думаем о том, как оценить рынок;
- Сравниваем со стоимостью разработки и поддержки;
- Мы учитываем вопросы конкуренции.
- оценить размер целевой аудитории;
- начните с простого варианта измерения процентов и не инвестируйте во что-то убыточное.
Маркетплейс как вклад в МСП
Мы видим в маркетплейсе очень хороший, недорогой и простой способ повысить уровень автоматизации малого и среднего бизнеса.Я считаю, что такие платформы с приложениями внутри повысят связность информационных систем — есть много мелких неконкурентных ниш, которые не актуальны для крупных разработчиков, а для небольших компаний и индивидуальных разработчиков это как раз самое то.
Это их хлеб, и, зарабатывая деньги, они закроют пробелы в автоматизации малого бизнеса.
Мы уже получили более сотни заявок от вендоров на размещение, обсуждаем реализацию этих интеграций, имеем хороший опыт быстрого запуска приложений, и это дает нам основания полагать, что маркетплейс взлетел.
Теги: #мой склад #мой склад #маркетплейс #магазин приложений #SaaS/S+S #Монетизация ИТ-систем #Управление продуктом #Бизнес-модели #облачные сервисы
-
Рунит Мини Пройдет На Риф 2022
19 Oct, 24 -
Алгоритмы Движения Опоздавшего Пассажира
19 Oct, 24 -
Мерч! Мерч! Мерч! И... Единороги
19 Oct, 24 -
Динамическое Размытие На Android
19 Oct, 24 -
Транспорт И Платежные Терминалы
19 Oct, 24 -
Еще Один Стартап Прощается С Нами
19 Oct, 24
