Сыграем в стартап-бинго? Платформа, экосистема, интеграции, маркетплейс, апи, синергия. Бинго!
Тема внутренних маркетплейсов интегрированных решений очень горячая в продуктовом мире. Мы в Poster POS для себя поняли преимущества открытого API и построения экосистемы достаточно давно. Меня особенно впечатлила глава «The Platform» в книге «The Facebook Effect», которая укрепила понимание, что нужно идти в платформы. 3 года назад мы открыли API, 2 года назад запустили Marketplace, год назад запустили технологию, которая дает возможность бесшовно расширять функциональность основного продукта и влиять на его поведение, около 3 месяцев назад перезапустили каталог интеграций и начали активно маркетировать приложения партнеров.
Когда мы начинали, мне не хватало публичных кейсов на эту тему, руководства к действию. В статье я расскажу, как SaaS-сервису без каталога интеграций стать SaaS-сервисом с каталогом интеграций. Моя статья будет полезна продуктам, которые уже прошли стадию product-market fit и готовы начать строить свою экосистему.
Чтобы дать немного контекста, Poster — это SaaS система автоматизации ресторанного и розничного бизнеса. То, что мы делаем, называют Point of Sale или «касса». Наш продукт разделен на две части — терминал и админка. Терминал запускается на планшетах iPad и Android или Windows-устройствах. На терминале кассиры и официанты вбивают заказ, принимают оплату, печатают чеки. В админке работают владелец заведения, управляющий, кладовщик: ведут складской и управленческий учет, смотрят статистику продаж, управляют товарами и т.д. Сейчас продуктом пользуются 6000 активных заведений в 53 странах мира.
Тема маркетплейсов и платформ не нова. Первые платформы — операционные системы, которые позволили разработчикам самостоятельно не заниматься управлением памятью, i/o, процессорным временем и т. д. Затем начали появляться десктопные приложения с add-on, plugins. У меня знакомство с плагинами началось с Total Commander и Winamp. Затем были Java-апплеты для смартфонов, в iOS 2.0 выпустили App Store. Веб-сервисы тоже начали обрастать интеграциями и плагинами, например Facebook, SalesForce, Basecamp, Xero и т. д. Открытый API и маркетплейсы стали частью нашей повседневной жизни и мы с ними сталкиваемся постоянно.
Давайте посмотрим правде в глаза: ваш беклог будет всегда расти. У вас всегда будет недостаточно ресурсов, чтобы запускать все функции, которые просят ваши пользователи. Более того, если постоянно добавлять новые функции в продукт, рано или поздно он превратится в жуткое неудобное месиво из кнопок, галочек и переключателей. Лучше сделать продукт, который качественно будет решать 3-7 задач, чем 50, но посредственно. Поэтому интеграции помогают продукту качественно расти в глазах пользователя, расширяют его функционал, а значит менее вероятно, что ваш клиент уйдет к конкурентам.
Интеграции с другими компаниями на рынке могут стать хорошим драйвером продаж вашего основного продукта. Например, в нашем случае, к партнерам, которые занимаются системами лояльности могут приходить потенциальные клиенты с устаревшим кассовым ПО или вообще без него. В этот момент партнер будет рекомендовать ту кассу, с которой у него есть интеграция и хорошие отношения.
Раньше, когда к нам приходил запрос на доработку продукта на большую сеть с нетипичными требованиями, нам приходилось отказывать, чтобы не закапывать себя в яму enterprise-решений, в которых на каждом шагу в коде встречаются ветвления вроде:
Теперь мы можем реализовать практически любые надстройки в системе, не затрагивая ядро продукта. Или, что еще лучше, отдать доработки на аутсорс.
Обычно каталоги берут комиссию с продаж приложений, которые в нем размещены. Размер комиссии от 30 (стандарт индустрии) до 80% (в совсем экстремальных случаях, например в Одноклассниках). Но, при этом, лично я слабо верю в идею того, что бизнес-модель компании можно построить вокруг маркетплейса. К примеру, у Apple 62% дохода приносит продажа iPhone, а вся категория услуг (приложения в AppStore, Apple Music, iCloud, Apple Pay) — 13%. В нашем случае, мы ставим перед маркетплейсом задачу быть самоокупаемым.
Мы для себя разделили варианты интеграции на 3 основных типа: Backend, Manage platform, POS platform.
Самый базовый вариант интеграции, с него мы начали и первые интеграции работали именно таким образом. Backend сервиса-партнера через HTTP JSON API достает данные, каким-то образом их обрабатывает и отображает клиенту, возможно что-то обновляет внутри нашей системы. Пример — системы аналитики, лояльности, рассылок, видеонаблюдение.
По сути та же backend-интеграция, но встроенная в личный кабинет пользователя. Под капотом для этого обычный iFrame и свой протокол для бесшовной авторизации. Намного удобнее для пользователя, т.к. не нужно никуда уходить из системы. Подходит для приложений с простым интерфейсом.
В какой-то момент нам и партнерам стало не хватать backend-интеграции. Нужно было решение для интеграции с кассой напрямую, хотелось расширять функционал, нативно встраиваться в кассу, менять ее поведение. Поэтому год назад мы запустили POS Platform с механикой плагинов или виджетов. Вы могли видеть подобные решения в вебе, например в Trello.
Примеры интеграций на этой технологии — системы лояльности, которые требуют идентификацию гостя возле кассы, мобильные кошельки и другие системы оплат. Вот, например, приложение от Paytomat, которое позволяет оплатить заказ криптовалютами:
Дальше расскажу про техническую составляющую реализации этой технологии.
Наше кассовое решение построено на гибридных технологиях, что позволяет поддерживать его на всех платформах: iOS, Android, Windows. Весь интерфейс и бизнес-логика написана на HTML/JS. А под нативные платформы мы пишем обертки вокруг WebView и реализовываем драйверы для работы с периферийным оборудованием (принтеры, фискальные регистраторы, весы и т. д.)
Если вы тоже пишете приложение на веб-стеке, сэкономлю вам время на исследование и расскажу, как мы сделали приложение расширяемым. В процессе изучения вдохновлялись решениями Trello, Shopify и Atom.io. В результате пришли к следующей модели.
Главный экземпляр приложения создает отдельный контейнер для каждого подключенного стороннего виджета. Контейнер — это iFrame, в котором загружается JS-файл с исполняемым кодом приложения партнера. В контейнере автоматически доступны методы с нашим API. Контейнер кешируется на фронте (Appcache или Service Workers) и может запускаться, работать без интернета.
Решение с iFrame позволяет изолировать логику стороннего приложения от основного и в случае каких-то проблем виджета не сломать основной флоу кассового приложения. Еще рассматривали вариант с WebWorkers, но у скриптов внутри воркера нет доступа к DOM, а мы даем виджетам возможность отображать интерфейсы, поэтому этот вариант отбросили сразу.
Разработчики пишут свое приложение с использованием JS или любого языка, который компилируется в JS (CoffeeScript, Typescript...), с любыми фреймворками или библиотеками. Дальше код и все ресурсы вебпаком собираются в один bundle.js, который консольной утилитой деплоится к нам на серверы и доставляется пользователям.
Виджеты в iFrame обмениваются сообщениями с основным приложением через postMessage и могут отправлять кассе команды через встроенный в глобальную область видимости объект Poster. Например:
Мы реализовали очередь колбеков, которая позволяют сторонним приложениям подписываться на события кассы, реагировать на них и изменять логику работы приложения. Например:
Кстати, в случае событий before*, которые, по сути, блокируют работу выполнения какой-то операции на кассе, нам пришлось вводить время ответа от стороннего виджета. К примеру, есть приложение которое слушает событие beforeOrderClose и делает запрос с деталями заказа, который кассир планирует оплатить, к себе на сервер. Чтобы пользовательский опыт не страдал, мы даем приложению не более 5 секунд, чтобы реализовать свою логику и вызвать next() или отобразить интерфейс, который покажет пользователю прогресс.
Каждый раз собирать все приложение и деплоить его к нам на серверы в процессе разработки неудобно, поэтому мы сделали дев-режим. В нем виджет постоянно собирается с помощью webpack-dev-server с hot-reloading и в приложении кассы на аккаунте разработчика код приложения запускается не с production, а с локальной машины разработчика. При этом в интерфейсе всегда есть возможность переключаться между dev и prod. Скоро мы введем еще одну ветку — beta. Код для беты будет тоже деплоиться к нам на сервера, но будет доступен только бета-тестировщиками приложения.
Долгое время мы регистрировали приложения и меняли настройки вручную, по запросу разработчиков. Каждый контакт на этапе создания приложения позволил нам больше общаться с разработчиками, узнавать про то, какие продукты они хотят интегрировать, каких методов в API им не хватает.
Но когда мы достигли отметки в 40-50 одновременных интеграций, механическая работа начала занимать у команды интеграций достаточно много времени. Поэтому мы запустили кабинет разработчика, в котором автоматизировали все эти процессы.
У нас в ДНК компании качественная техническая поддержка. Поэтому, когда мы начали растить историю с партнерами-разработчиками, решили сделать самую крутую поддержку разработчиков на рынке.
С каждым партнером мы созваниваемся, помогаем составить флоу интеграции и даже готовим детальный фоллоу-ап со списком методов, которые им нужно использовать для реализации. На вопросы отвечаем в общем Telegram-чате с разработчиками партнера.
Кстати, тут иногда возникает проблема, когда менее опытные разработчики задают вопросы не по нашей платформе, API, а просто по программированию или не хотят заниматься отладкой, когда проблема на их стороне. В таких ситуациях мы используем прием «не отвечать в течение 1-2 часов», в большинстве случаев за это время разработчик самостоятельно решает проблему :)
Для документации используем Slate. Авто-генерация документации из комментариев к исходникам нам не подошла по той причине, что нужно поддерживать несколько языковых версий документации — русский и английский.
Ну и конечно важно понимать, что для сторонних разработчиков мы — всего лишь еще одна дополнительная интеграция, поэтому они должны сделать ее максимально быстро и с максимальной пользой для своего бизнеса. Поэтому мы делаем готовые boilerplate, примеры кода и всячески стараемся помочь в процессе.
Чтобы все получали пользу: заведения — дополнительный функционал и решение своих бизнес-задач, разработчики — новых клиентов, а мы — более глубокое замыкание клиентов в своей экосистеме, приложения нужно маркетировать. Для маркетинга приложений среди наших пользователей мы используем следующие инструменты.
Это самое простое, что можно сделать: анонсируем новую интеграцию в соцсетях и ежемесячной рассылке про новые функции. Сообщения получаются нетаргетированные, по всем нашим контактам, и могут теряться среди информационного шума.
Мы выделяем клиентов, которым может быть интересна та или иная категория приложений (системы лояльности, видеонаблюдение, документооборот и т.д.), и делаем им точечные рассылки с предложением посмотреть, что у нас есть в маркете из этой категории.
Например, для заведений, которые забили в базу больше 100 контактных данных своих гостей, мы делаем триггер про интеграции с системами лояльности и рассказываем, что он может работать со своими гостями еще более эффективно и возвращать их к себе в заведение. Для заведений, в которых работает больше 5 сотрудников (это уже не семейный бизнес), мы отправляем триггер про интеграции с облачными системами видеонаблюдения, чтобы сотрудников было проще контролировать.
Это письмо и пуш мы добавляем в нашу структуру онбординга, оно приходит клиенту, когда он уже стал платным и начал пользоваться всеми основным функциями. Если прислать ему информацию про расширение функционала до того, как он научится пользоваться основным — это будет абсолютно бесполезно.
Пользователи достаточно часто игнорируют письма и пуши в потоке информационного мусора, поэтому мы добавили ненавязчивые баннеры в самом продукте. Мы обнаружили, что этот один из самых эффективных способов направить трафик на страницу приложения. Баннеры появляются в контексте. К примеру, баннер про продукты для глубокой аналитики появляется в разделе с чеками — там, где владелец анализирует свои продажи.
Сейчас мы экспериментируем с форматом статей в блоге с кейсами решения бизнес-задач с помощью интегрированных решений. Скоро запустим совместные вебинары с партнерами.
С перечисленными выше инструментами мы научились приводить сторонним разработчикам 20-100 лидов в месяц, и это только начало.
Естественно, продажа не происходит сама по себе после того, как мы приводим лида стороннему разработчику. Обычно b2b-продукты сложнее в освоении и самостоятельной работе, поэтому мы передаем контактные данные клиента (с его согласия) партнерам и настаиваем на том, чтобы с клиентами связались и помогли в процессе онбординга.
Мы считаем, что биллить клиента нужно в одном месте, чтобы максимально упростить флоу работы и подключения для него. Сейчас мы заканчиваем поддержку биллинга для сторонних приложений.
Кстати, тут много сложностей в реализации, например:
Сейчас ревью приложения проводится единоразово при попадании приложения в маркет. Хотим внедрить обязательное, но быстрое ревью при каждом деплое, чтобы помочь отследить какие-то edge-кейсы.
Чтобы сохранить единый опыт от использования нашего продукта и интегрированных продуктов, мы даем рекомендации по дизайну и флоу партнерам, но формализованного свода правил еще нет.
Разрабатываем гайдлайны для внутреннего использования дизайнерами и разработчиками Poster, а затем откроем их и сторонним разработчикам.
На самом деле мы только в начале пути. Еще много работы, чтобы стать полноценной платформой, но мы уже и многому научились за это время. Дальше — только интереснее. Если у вас есть вопросы, пишите в комментариях, буду стараться отвечать максимально полно.
А если вы делаете продукт для кафе, ресторанов, магазинов — давайте менять рынок вместе! Напишите прямо сейчас на dev@joinposter.com, уверен, что мы сможем быть полезны друг другу.
Тема внутренних маркетплейсов интегрированных решений очень горячая в продуктовом мире. Мы в Poster POS для себя поняли преимущества открытого API и построения экосистемы достаточно давно. Меня особенно впечатлила глава «The Platform» в книге «The Facebook Effect», которая укрепила понимание, что нужно идти в платформы. 3 года назад мы открыли API, 2 года назад запустили Marketplace, год назад запустили технологию, которая дает возможность бесшовно расширять функциональность основного продукта и влиять на его поведение, около 3 месяцев назад перезапустили каталог интеграций и начали активно маркетировать приложения партнеров.
Когда мы начинали, мне не хватало публичных кейсов на эту тему, руководства к действию. В статье я расскажу, как SaaS-сервису без каталога интеграций стать SaaS-сервисом с каталогом интеграций. Моя статья будет полезна продуктам, которые уже прошли стадию product-market fit и готовы начать строить свою экосистему.
Про нас
Чтобы дать немного контекста, Poster — это SaaS система автоматизации ресторанного и розничного бизнеса. То, что мы делаем, называют Point of Sale или «касса». Наш продукт разделен на две части — терминал и админка. Терминал запускается на планшетах iPad и Android или Windows-устройствах. На терминале кассиры и официанты вбивают заказ, принимают оплату, печатают чеки. В админке работают владелец заведения, управляющий, кладовщик: ведут складской и управленческий учет, смотрят статистику продаж, управляют товарами и т.д. Сейчас продуктом пользуются 6000 активных заведений в 53 странах мира.
Немного истории
Тема маркетплейсов и платформ не нова. Первые платформы — операционные системы, которые позволили разработчикам самостоятельно не заниматься управлением памятью, i/o, процессорным временем и т. д. Затем начали появляться десктопные приложения с add-on, plugins. У меня знакомство с плагинами началось с Total Commander и Winamp. Затем были Java-апплеты для смартфонов, в iOS 2.0 выпустили App Store. Веб-сервисы тоже начали обрастать интеграциями и плагинами, например Facebook, SalesForce, Basecamp, Xero и т. д. Открытый API и маркетплейсы стали частью нашей повседневной жизни и мы с ними сталкиваемся постоянно.
Что дают маркетплейсы?
Больше функций, выше вовлечение пользователей
Давайте посмотрим правде в глаза: ваш беклог будет всегда расти. У вас всегда будет недостаточно ресурсов, чтобы запускать все функции, которые просят ваши пользователи. Более того, если постоянно добавлять новые функции в продукт, рано или поздно он превратится в жуткое неудобное месиво из кнопок, галочек и переключателей. Лучше сделать продукт, который качественно будет решать 3-7 задач, чем 50, но посредственно. Поэтому интеграции помогают продукту качественно расти в глазах пользователя, расширяют его функционал, а значит менее вероятно, что ваш клиент уйдет к конкурентам.
Драйвер роста ваших продаж
Интеграции с другими компаниями на рынке могут стать хорошим драйвером продаж вашего основного продукта. Например, в нашем случае, к партнерам, которые занимаются системами лояльности могут приходить потенциальные клиенты с устаревшим кассовым ПО или вообще без него. В этот момент партнер будет рекомендовать ту кассу, с которой у него есть интеграция и хорошие отношения.
Возможность делать нестандартные решения для крупных клиентов
Раньше, когда к нам приходил запрос на доработку продукта на большую сеть с нетипичными требованиями, нам приходилось отказывать, чтобы не закапывать себя в яму enterprise-решений, в которых на каждом шагу в коде встречаются ветвления вроде:
if (account===’very_important_enterprise_customer’) { ... }Теперь мы можем реализовать практически любые надстройки в системе, не затрагивая ядро продукта. Или, что еще лучше, отдать доработки на аутсорс.
Дополнительный канал заработка
Обычно каталоги берут комиссию с продаж приложений, которые в нем размещены. Размер комиссии от 30 (стандарт индустрии) до 80% (в совсем экстремальных случаях, например в Одноклассниках). Но, при этом, лично я слабо верю в идею того, что бизнес-модель компании можно построить вокруг маркетплейса. К примеру, у Apple 62% дохода приносит продажа iPhone, а вся категория услуг (приложения в AppStore, Apple Music, iCloud, Apple Pay) — 13%. В нашем случае, мы ставим перед маркетплейсом задачу быть самоокупаемым.
Какие бывают интеграции
Мы для себя разделили варианты интеграции на 3 основных типа: Backend, Manage platform, POS platform.
Backend интеграция
Самый базовый вариант интеграции, с него мы начали и первые интеграции работали именно таким образом. Backend сервиса-партнера через HTTP JSON API достает данные, каким-то образом их обрабатывает и отображает клиенту, возможно что-то обновляет внутри нашей системы. Пример — системы аналитики, лояльности, рассылок, видеонаблюдение.
Manage Platform
По сути та же backend-интеграция, но встроенная в личный кабинет пользователя. Под капотом для этого обычный iFrame и свой протокол для бесшовной авторизации. Намного удобнее для пользователя, т.к. не нужно никуда уходить из системы. Подходит для приложений с простым интерфейсом.
POS Platform
В какой-то момент нам и партнерам стало не хватать backend-интеграции. Нужно было решение для интеграции с кассой напрямую, хотелось расширять функционал, нативно встраиваться в кассу, менять ее поведение. Поэтому год назад мы запустили POS Platform с механикой плагинов или виджетов. Вы могли видеть подобные решения в вебе, например в Trello.
Примеры интеграций на этой технологии — системы лояльности, которые требуют идентификацию гостя возле кассы, мобильные кошельки и другие системы оплат. Вот, например, приложение от Paytomat, которое позволяет оплатить заказ криптовалютами:
Дальше расскажу про техническую составляющую реализации этой технологии.
Как сделать JS-приложение, расширяемое сторонними разработчиками
Наше кассовое решение построено на гибридных технологиях, что позволяет поддерживать его на всех платформах: iOS, Android, Windows. Весь интерфейс и бизнес-логика написана на HTML/JS. А под нативные платформы мы пишем обертки вокруг WebView и реализовываем драйверы для работы с периферийным оборудованием (принтеры, фискальные регистраторы, весы и т. д.)
Если вы тоже пишете приложение на веб-стеке, сэкономлю вам время на исследование и расскажу, как мы сделали приложение расширяемым. В процессе изучения вдохновлялись решениями Trello, Shopify и Atom.io. В результате пришли к следующей модели.
Главный экземпляр приложения создает отдельный контейнер для каждого подключенного стороннего виджета. Контейнер — это iFrame, в котором загружается JS-файл с исполняемым кодом приложения партнера. В контейнере автоматически доступны методы с нашим API. Контейнер кешируется на фронте (Appcache или Service Workers) и может запускаться, работать без интернета.
Решение с iFrame позволяет изолировать логику стороннего приложения от основного и в случае каких-то проблем виджета не сломать основной флоу кассового приложения. Еще рассматривали вариант с WebWorkers, но у скриптов внутри воркера нет доступа к DOM, а мы даем виджетам возможность отображать интерфейсы, поэтому этот вариант отбросили сразу.
Разработчики пишут свое приложение с использованием JS или любого языка, который компилируется в JS (CoffeeScript, Typescript...), с любыми фреймворками или библиотеками. Дальше код и все ресурсы вебпаком собираются в один bundle.js, который консольной утилитой деплоится к нам на серверы и доставляется пользователям.
Виджеты в iFrame обмениваются сообщениями с основным приложением через postMessage и могут отправлять кассе команды через встроенный в глобальную область видимости объект Poster. Например:
Poster.interface.popup({width: 500, height: 300, title: "Списание бонусов"});Мы реализовали очередь колбеков, которая позволяют сторонним приложениям подписываться на события кассы, реагировать на них и изменять логику работы приложения. Например:
Poster.on('beforeOrderClose', (data, next) => {
alert("Сейчас закроем заказ");
next();
});Кстати, в случае событий before*, которые, по сути, блокируют работу выполнения какой-то операции на кассе, нам пришлось вводить время ответа от стороннего виджета. К примеру, есть приложение которое слушает событие beforeOrderClose и делает запрос с деталями заказа, который кассир планирует оплатить, к себе на сервер. Чтобы пользовательский опыт не страдал, мы даем приложению не более 5 секунд, чтобы реализовать свою логику и вызвать next() или отобразить интерфейс, который покажет пользователю прогресс.
Дев-режим
Каждый раз собирать все приложение и деплоить его к нам на серверы в процессе разработки неудобно, поэтому мы сделали дев-режим. В нем виджет постоянно собирается с помощью webpack-dev-server с hot-reloading и в приложении кассы на аккаунте разработчика код приложения запускается не с production, а с локальной машины разработчика. При этом в интерфейсе всегда есть возможность переключаться между dev и prod. Скоро мы введем еще одну ветку — beta. Код для беты будет тоже деплоиться к нам на сервера, но будет доступен только бета-тестировщиками приложения.
Кабинет разработчика
Долгое время мы регистрировали приложения и меняли настройки вручную, по запросу разработчиков. Каждый контакт на этапе создания приложения позволил нам больше общаться с разработчиками, узнавать про то, какие продукты они хотят интегрировать, каких методов в API им не хватает.
Но когда мы достигли отметки в 40-50 одновременных интеграций, механическая работа начала занимать у команды интеграций достаточно много времени. Поэтому мы запустили кабинет разработчика, в котором автоматизировали все эти процессы.
Документация, примеры, поддержка партнеров
У нас в ДНК компании качественная техническая поддержка. Поэтому, когда мы начали растить историю с партнерами-разработчиками, решили сделать самую крутую поддержку разработчиков на рынке.
С каждым партнером мы созваниваемся, помогаем составить флоу интеграции и даже готовим детальный фоллоу-ап со списком методов, которые им нужно использовать для реализации. На вопросы отвечаем в общем Telegram-чате с разработчиками партнера.
Кстати, тут иногда возникает проблема, когда менее опытные разработчики задают вопросы не по нашей платформе, API, а просто по программированию или не хотят заниматься отладкой, когда проблема на их стороне. В таких ситуациях мы используем прием «не отвечать в течение 1-2 часов», в большинстве случаев за это время разработчик самостоятельно решает проблему :)
Для документации используем Slate. Авто-генерация документации из комментариев к исходникам нам не подошла по той причине, что нужно поддерживать несколько языковых версий документации — русский и английский.
Ну и конечно важно понимать, что для сторонних разработчиков мы — всего лишь еще одна дополнительная интеграция, поэтому они должны сделать ее максимально быстро и с максимальной пользой для своего бизнеса. Поэтому мы делаем готовые boilerplate, примеры кода и всячески стараемся помочь в процессе.
Маркетинг приложений
Чтобы все получали пользу: заведения — дополнительный функционал и решение своих бизнес-задач, разработчики — новых клиентов, а мы — более глубокое замыкание клиентов в своей экосистеме, приложения нужно маркетировать. Для маркетинга приложений среди наших пользователей мы используем следующие инструменты.
Анонс интеграции
Это самое простое, что можно сделать: анонсируем новую интеграцию в соцсетях и ежемесячной рассылке про новые функции. Сообщения получаются нетаргетированные, по всем нашим контактам, и могут теряться среди информационного шума.
Триггерные рассылки
Мы выделяем клиентов, которым может быть интересна та или иная категория приложений (системы лояльности, видеонаблюдение, документооборот и т.д.), и делаем им точечные рассылки с предложением посмотреть, что у нас есть в маркете из этой категории.
Например, для заведений, которые забили в базу больше 100 контактных данных своих гостей, мы делаем триггер про интеграции с системами лояльности и рассказываем, что он может работать со своими гостями еще более эффективно и возвращать их к себе в заведение. Для заведений, в которых работает больше 5 сотрудников (это уже не семейный бизнес), мы отправляем триггер про интеграции с облачными системами видеонаблюдения, чтобы сотрудников было проще контролировать.
Это письмо и пуш мы добавляем в нашу структуру онбординга, оно приходит клиенту, когда он уже стал платным и начал пользоваться всеми основным функциями. Если прислать ему информацию про расширение функционала до того, как он научится пользоваться основным — это будет абсолютно бесполезно.
Информационные баннеры внутри продукта
Пользователи достаточно часто игнорируют письма и пуши в потоке информационного мусора, поэтому мы добавили ненавязчивые баннеры в самом продукте. Мы обнаружили, что этот один из самых эффективных способов направить трафик на страницу приложения. Баннеры появляются в контексте. К примеру, баннер про продукты для глубокой аналитики появляется в разделе с чеками — там, где владелец анализирует свои продажи.
Что еще?
Сейчас мы экспериментируем с форматом статей в блоге с кейсами решения бизнес-задач с помощью интегрированных решений. Скоро запустим совместные вебинары с партнерами.
С перечисленными выше инструментами мы научились приводить сторонним разработчикам 20-100 лидов в месяц, и это только начало.
После передачи лида
Естественно, продажа не происходит сама по себе после того, как мы приводим лида стороннему разработчику. Обычно b2b-продукты сложнее в освоении и самостоятельной работе, поэтому мы передаем контактные данные клиента (с его согласия) партнерам и настаиваем на том, чтобы с клиентами связались и помогли в процессе онбординга.
Что у нас в работе?
Биллинг
Мы считаем, что биллить клиента нужно в одном месте, чтобы максимально упростить флоу работы и подключения для него. Сейчас мы заканчиваем поддержку биллинга для сторонних приложений.
Кстати, тут много сложностей в реализации, например:
- У приложений может быть абсолютно разная модель монетизации: ежемесячная подписка, транзакционные платежи, подписка в зависимости от использования
- Клиента нужно автоматически уведомить в случае смены тарифов
- Клиенты могут платить из разных стран, а договор с партнером обычно в одной
- У клиента может быть привязана карточка для оплат, а может быть оплата по счетам на юр. лицо.
Ревью приложений
Сейчас ревью приложения проводится единоразово при попадании приложения в маркет. Хотим внедрить обязательное, но быстрое ревью при каждом деплое, чтобы помочь отследить какие-то edge-кейсы.
Гайдлайны для сторонних приложений
Чтобы сохранить единый опыт от использования нашего продукта и интегрированных продуктов, мы даем рекомендации по дизайну и флоу партнерам, но формализованного свода правил еще нет.
Разрабатываем гайдлайны для внутреннего использования дизайнерами и разработчиками Poster, а затем откроем их и сторонним разработчикам.
Вот и все
На самом деле мы только в начале пути. Еще много работы, чтобы стать полноценной платформой, но мы уже и многому научились за это время. Дальше — только интереснее. Если у вас есть вопросы, пишите в комментариях, буду стараться отвечать максимально полно.
А если вы делаете продукт для кафе, ресторанов, магазинов — давайте менять рынок вместе! Напишите прямо сейчас на dev@joinposter.com, уверен, что мы сможем быть полезны друг другу.