Бизнес-модель Подписка - основные элементы сервиса

Введение 

Сервисы по подписке набирают свою силу. Многие крупные компании начинают предлагать свои товары и услуги именно по подписке. Причем это может быть не только виртуальный товар, но реальный физический. 

В этой статье разберем, что должно быть в сервисе по подписке. 

Ключевой субъект сервиса по подписке

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

Нам необходимо знать как можно больше о клиенте: 

• что он делал на сервисе? 
• чем интересовался?
• его анкетные данные; 
• с кем взаимодействовал.

Собирая подобную информацию, можно делать определенные выводы о том, что можно предложить конкретно этому клиенту. 

Ключевой объект в сервисе подписки

Все крутится в подобных сервисах вокруг заказов, заявок. Т.е. это единица запроса клиента к сервису для получения некоторой ценности.

Заявка - ключевой объект системы. Заявка характеризуется следующими параметрами: 

• статус - определяет текущее состояние заявки, т.е. кто над данной заявкой работает и в чем заключается эта обработка;
• детали заявки - заявка на что? какие данные предоставил клиент? как эта заявка связана с реальным миром? (гео данные, номер склада и т.д.);
• история заявки - по ходу движения заявки она обретает свою историю (статусы меняются, добавляются комментарии и т.д). 

Заявка может быть очень короткой, а может длиться несколько месяцев (по сути это уже проект, как особая форма заявки). 

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

Оплата

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

Как будет клиент оплачивать услуги на сервисе. Есть несколько разных вариантов по оплате: 

• клиент оплачивает отдельные платные услуги на сервисе;
• клиент платит за доступ к аккаунту в течении периода;
• клиент платит за привилегии в течении периода. 

Как мы реализуем оплату в Falcon Service (сервис подписки для обработки заказов) и Falcon Auction  (площадка услуг)

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

Чтобы пополнить баланс используется платежный шлюз - это внешняя компания, которая берет на себя функцию приема оплаты с клиента и переводит средства на ваш расчетный счет (за вычетом своей комиссии в 1-5%). 

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

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

Каталог

Для каталога важно иметь хорошо структурированную информацию. Это значит, что вы храните объекты не просто как Название, Описание и Картинка, а как набор параметров, по которым можно построить фильтры и искать информацию.

Каталог - способ поиска информации на сервисе. Он есть практически в любой системе. 

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

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

Взаимодействие

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

Чем точнее эти правила, тем проще сориентироваться пользователю на сервисе. Если же сервис построен по принципу "делай что хочешь", то вероятно большая часть пользователей будет дезориентирована. 

Кто взаимодействует на сервисе: 

• клиент с клиентом;
• клиент с администрацией;
• клиент с другим типом пользователей на сайте (поставщики);
• администрация с поставщиками;
• неавторизованный пользователь с администрацией.

Каким может быть взаимодействие: 

• форма обратной связи;
• переписка на сайте;
• комментарии к заявке (оставляют разные лица и как бы общаются по этой заявке);
• стена в сервисе;
• операторский чат (например, Jivosite, Replain);
• позвонить на мессенджер;
• написать на почту. 

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

Заключение

Мы рассмотрели ключевые элементы сервиса подписки. Помимо этого есть еще менее важные элементы - аналитика, диагностика, профили, карточки профилей и т.д. 

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

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

Насколько полезной была статья?