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