{"id":14283,"url":"\/distributions\/14283\/click?bit=1&hash=8766cc03cba44a6d934ee26f882971a64223452448548d2fc3a5f37339e77cfa","title":"\u0412\u0438\u0434\u0435\u043b\u0438 \u0432 \u0421\u043e\u0447\u0438 \u0443\u0436\u0435 \u0432\u0441\u0451? \u0412\u043e\u0442 \u043d\u0435\u043e\u0431\u044b\u0447\u043d\u0430\u044f \u0438\u0434\u0435\u044f \u0434\u043b\u044f \u043e\u0442\u0434\u044b\u0445\u0430 \u043d\u0430 \u043a\u0443\u0440\u043e\u0440\u0442\u0435 ","buttonText":"","imageUuid":""}

«Ценовая дискриминация« и »модель подписки» — как изнутри устроены эти инструменты увеличения выручки

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

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

Коммерческая политика такого класса невозможна без специального ИТ-решения, «коммерческой платформы». Наибольший опыт внедрений такого типа накоплен в телеком-бизнесе, и я вижу большое будущее в переносе этой методологии на другие бизнесы: продажу контента, EdTech, SAAS, логистику. Более того, мне кажется, что и традиционный ритейл скоро придет к схожей схеме ценообразования.

С вопросами тарификации и ценовой дискриминации я сталкивался в самых в разных проектах: отмена накопительных скидок в OZON. ru, реализация конвергентной тарификации в PRICE. RU, запуск «Клубной программы» в RuCenter. Наиболее же значимым опытом в этой области для меня стал запуск коммерческой платформы РБК-ПРО, осуществленный на базе программных продуктов российского ИТ-разработчика Forward Telecom. Именно этот проект, в рамках которого мы опирались на опыт коллег из телеком-индустрии, сформировал у меня в голове ясное понимание того, как устроена современная конвергентная тарификация и биллинг. Этому и посвящен данный текст и видеосюжет.

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

Терехов Антон
Генеральный Директор ООО «Экспертные системы» (Phenomen. org ™)

Прайс-лист и тарифный план.

Для начала представим себе простой прайс-лист, в котором перечислены цены на товары и услуги.

Рис.1. Структура типичного прайс-листа 

Сразу обратите внимание, что я вынес «единицы измерения» в отдельную колонку, и что «время» — это такая же единица измерения, как штуки или килограммы. Это нам потом пригодится. Конечно же, реальный прайс-лист практически всегда выглядит сложнее. Товары и услуги в нем могут быть сгруппированы в иерархическую структуру, в них могут быть выделены группы и подгруппы. Также в прайс-листе зачастую присутствует еще одно измерение – это клиенты. Они, эти самые клиенты, могут быть указаны в прайс-листе в явном виде. В микроэкономике предоставление разных цен разным типам клиентов называют ценовой дискриминацией третьего типа.

Рис.2. Зависимость цены от формальных «статических» признаков клиента.

Также клиенты могут «присутствовать» в прайс-листе в неявном виде, в этом случае цена зависит не от их «статических», а от «поведенческих» характеристик. Такой подход в микроэкономике называют ценовой дискриминацией второго типа. Наиболее известный пример дискриминации второго типа – это колонка «оптовые цены». Они доступны только тем, чье поведение подпадает под некоторые, заранее установленные критерии (либо они покупают регулярно, либо средний чек их заказа велик и т. п.).

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

Рис. 3. Зависимость цены от поведенческих характеристик клиента

Таким образом, мы приходим к тому, что в «основном» прайс-листе компании есть некие «столбцы», своего рода «мини-прайс-листы», которые отличаются для разных групп клиентов. Это и есть «Тарифные планы». Тарифный план – это перечень всех услуг и продуктов компании и их цен, который включает в себя:

  • Маркетинговое название;
  • Уникальный идентификатор;
  • Перечень доступных товаров и услуг, каждому элементу списка соответсвтует: единица измерения; доступность в рамках данного тарифного плана (да/нет); Стоимость; Ограничительные квоты и стоимости в рамках квоты и при выходе за ее границы;
  • Период действия – период, в рамках которого данная линейка цен вообще актуальна, например, интервал с 2022 по 2025 годы.
  • Длительность предоставления — период, на который конкретному клиенту передается «доступ к линейке цен» (например, 1 месяц с момента подключения) .

Таким образом, разные тарифные планы по сути своей предоставляют доступ к «линейкам цен» для разных групп клиентов. Один клиент всегда пользуется одним тарифным планом. Это и понятно, в противном случае, возникнет путаница — по какой цене отгружать ему конкретную позицию прайс-листа. Это значит, что тарифный план может быть «подключен» и «отключен».

Подключение / отключение тарифного плана и «офферы»

Мы пришли к тому, что должны существовать процедуры подключения / отключения тарифных планов, а значит возникает понятие «Стоимость подключения». Для особенно жадных существует еще и «Стоимость отключения».

Логичнее всего реализовать подключение и отключение тарифного плана через отдельные сущности, так называемые «офферы».

Оффер определяет условия подключения и отключения тарифного плана и включает в себя:

  • Маркетинговое название;

  • Поведенческие таргетинги - характеристики профиля клиента (объем и история покупок, текущий тарифный план и т.п.);

  • Статические таргетинги - характеристики профиля клиента (например физ. лицо/юр. лицо, пол, возраст);

  • Стоимость подключения данного тарифного плана.

  • ID_Тарифного плана. Упоминание тарифного плана, который подключается с помощью данного оффера;

  • Период действия оффера - в какой промежуток времени клиенты могут воспользоваться условиями оффера.Другие условия предоставления (например способ оплаты и т.п.).

Другими словами, оффер – это то, кому и на каких условиях мы открываем тарифный план.

Подписка

Каждый конкретный клиент имеет свою историю взаимодействия с компанией. Один и тот же тарифный план может быть подключен разным клиентам в разные даты на основании разных офферов. Возникает понятие «подписка клиента». Чтобы избежать путаницы, я настойчиво предлагаю всем использовать термин «подписка» именно для обозначения подключения конкретного клиента к конкретному тарифному плану путем покупки конкретного оффера!

Подписка – сущность, определяющая набор условий потребления товаров и услуг компании конкретным клиентом и включает в себя:

  • ID_клиента;

  • ID_подключенного оффера (который в свою очередь определяет ID_тарифного плана);
  • Дату старта и дату окончания (Дата окончания определяется из настроек тарифного плана – к дате старта добавляется длительность предоставления);
  • Текущий статус (активна, приостановлена и т.п.).

Еще раз:

«Тарифный план» - это некий «шаблон», регламентирующий набор, период предоставления и ограничения услуг. «Оффер» – это то, на каких условиях и кому мы этот «шаблон» продаем. А «подписка» - это оффер, подключенный конкретному клиенту, имеющий конкретную дату старта и окончания.

Например:

- Тарифный план «Овощной» подразумевает что стоимость всех овощей очень низкая, а стоимость всех фруктов, наоборот высокая. Действует он 3 месяца с момента подключения.

- Оффер «Урожай 2022»» позволяет купить клиентам физ-лицам данный тарифный план со скидкой 50% при условии оплаты в августе 2022 года.

- А конкретная «подписка» определяет то, что конкретный клиент Вася подключил данный оффер 12 августа и пользуется набором входящих в данный тарифный план цен в интервале с 12 августа по 12 ноября 2022 года.

Длящиеся услуги и другая интерпретация термина «подписка»

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

Итак, услуги и товары, входящие в прайс-лист, бывают разного типа:

  • Разовые. Товары и услуги, действующие относительно короткий промежуток времени, имеющие «единицу измерения». Пример: покупка 1 кг морковки, прочтение одной статьи, один час просмотра видео, один час разговора с консультантом, 1 СМС, 1 Гбайт интернета. В рамках тарифного плана должна быть определена единица измерения таких продуктов, их стоимость и квоты. Важно, что время (например доступ на 1 час, 1 день, 1 неделю) в данном случае – это просто единица измерения разовой услуги;
  • Длящиеся. Услуги, доступные на протяжении всего периода действия тарифного плана. Для таких услуг время перестает быть единицей измерения, а слово «длящаяся» обозначает сам факт того, что услуга предоставляется в течение всего периода действия тарифного плана. В рамках одного тарифного плана такую услугу нельзя раздробить, и нельзя купить несколько одинаковых услуг такого типа. Например это может быть: «Доступ в библиотеку», «Абонемент в фитнес-центр»;
  • Вечные покупки. Это разовые продукты и услуги, потребление которых возможно после окончания действия подписки. Например, в рамках подписки клиент получил доступ к PDF файлу по определенной цене, подписка закончилась, но сам файл остался доступен навсегда.

Так вот, как маркетолог, я могу ввести в тарифный план некую «виртуальную длящуюся услугу», которая «обнулит» стоимость других товаров и услуг в рамках установленных квот.

Рис.4. Абонентская плата обнуляет стоимость других услуг в пределах установленной квоты

Таким образом, возникает понятие «Абонентская плата» (которую как раз часто и называют «Подпиской») – это виртуальная длящаяся услуга, задающая квоты бесплатного потребления других продуктов и услуг.

С точки зрения рекламного нарратива можно громко заявить: «Всего за 5 000 руб. в месяц вы можете подписаться на бесплатную доставку овощей и фруктов».

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

Как именно рассчитать величину стоимости Абонентской платы в зависимости от уровня потребления клиентами «реальных» продуктов мы обсудим в следующих материалах.

Отмечу, что никаких противоречий понятия «Абонентская плата» с вышесказанным о структуре «Тарифный план --- Оффер --- Подписка» нет. Ведь абонентская плата — это не техническая, а маркетинговая сущность, ее появление в прайс-листе компании это своего рода маркетинговый ход, позволяющий «обнулить» цены на определенные продукты в рамках квот тарифного плана.

Коммерческая политика

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

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

Коммерческая политика – совокупность правил формирования тарифных планов и офферов для разных групп клиентов.

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

В случае РБК-ПРО коммерческая политика разрабатывалась исходя из:

- Тематических предпочтений пользователей. Отдельно были вынесены доступы к материалам разных тематик, соответствующим предпочтениям пользователей. Для них были сформированы отдельные "тематические тарифные планы".

- Хорошей иллюстрацией конвергентности было, наряду с собственным контентом, подключение продуктов внешнего партнера, компании Smart-Reading, предлагающей саммари бизнес-литературы.

- Система коммерческих офферов РБК-ПРО подразумевает пошаговое вовлечение пользователей с момента подключения так называемого триала и последующий поэтапного перевода с тарифа на тариф.

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

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

Понятие «Коммерческой платформы» и ее взаимодействие с другими компонентами ИТ-решения.

Поговорим теперь, о том, как воплотить все вышесказанное в ИТ-решении.

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

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

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

Другими словами «управление коммерческим продуктом» и «управление реальным продуктом», я настойчиво рекомендую отделить друг от друга и разносить в разные слои ИТ-архитектуры, чтобы их развитие не тормозило друг друга. Это, хотя и общий, но очень ценный совет – прочитайте его два раза 😉.

Подход «сервисной архитектуры» правильно использовать и для внутреннего устройства коммерческой платформы. Она состоит из разных компонент - сервисов, каждая из которых инкапсулирует внутри себя определенную часть общей бизнес-логики, а взаимодействие этих компонент друг с другом осуществляется посредством программных интерфейсов, синхронных или асинхронных.

Рис. 5. Компоненты слоя "Коммерческой платформы" на примере продуктов Forward Telecom.

Разберем чуть подробнее компоненты коммерческой платформы.

Продуктовый каталог \ Product catalog.

  • Обеспечивает создание иерархии коммерческих продуктов, реестр услуг, товаров, формирование тарифных планов. По сути, формирует глобальный прайс-лист, иерархический справочник тарифных планов;

  • Обеспечивает управление сроками действия, ценами и другими параметрами офферов;
  • Содержит настройки жизненного цикла продукта (длительность, наличие suspend периода и т.п.);

  • Обеспечивает управление условиями доступности офферов (позволяет выбрать «свойства клиента» которым доступен оффер (свойства клиентов определяются по заранее согласованному списку этих свойств, определяющих т.н. Golden Record (см. ниже), указать «контекст» при котором он показывается (например маску URL);

  • Обеспечивает другие связи между тарифными планами (запреты доступности, политика апгрейдов и даунгрейдов и т.п.);

  • Обеспечивает интеграцию с биллингом, то есть передает в биллинг всю необходимую информацию о продуктах, декомпозированную до самого низкого уровня иерархии, которая позволит биллингу с помощью инструмента service provisioning (см ниже) включать и выключать конкретные услуги и доступы конкретному клиенту.

CRM

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

Чтобы выполнять свои функции, CRM должна собирать максимальное количество информации о клиенте на некий универсальный ключ, так называемый Master_ID из разных источников. Для этого CRM должна поддерживать логику «сквозной аналитики», в которой существует возможность MDM (master data management – метчинг данных - сопоставление master_ID и соответствующих ему клиентских идентификаторов в других системах: кука на веб-сайте, емэйл в почтовом рассыльщике, логин в системе авторизации, телефон в контактном центре и т.п.).

В CRM операторы и менеджеры получают доступ к статическому и поведенческому профилю клиента и к системе «управления сделками».

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

DMP - Data Management Platform

Это система быстрого обмена данными о клиенте на основе краткой выжимки о его профиле. Такую выжимку еще называют «Golden Record». Она содержит ограниченное количество информации о клиенте, только той, которая важна для таргетинга коммерческих офферов. При этом DMP способна быстро в режиме онлайн отдавать эту информацию, снижая тем самым нагрузку на БД CRM и обеспечивая высокую скорость работы системы таргетинга офферов. Это своего рода быстрая кеширующая надстройка над CRM.

Состав золотой записи может выглядеть, например так:

Рис.6. Пример полей "Золотой Записи"

В зависимости от значений этих параметров система может «открывать» и «рекомендовать» клиенту те или иные офферы. Настройки же, что и кому рекомендовать, напомню, осуществляются в продуктовом каталоге.

Другими словами, DMP – это такой технологичный инструмент цифровой дискриминации. Она содержит параметры необходимые как для ценовой дискриминации третьего типа - «статический» профиль клиента, так и для ценовой дискриминации второго – его «поведенческий» профиль.

Order Capture - "Захват заказа"

Система взаимодействия с пользователем, - инструмент формирования динамической витрины офферов. Определяет ID клиента, контекст его посещения (например, по маске урла) и формирует для него витрину офферов на основании настроек, сделанных в продуктовом каталоге и Golden Record клиента. «Витрина» - это условное название набора офферов, которые компания рекомендует клиенту в данный момент времени в данном месте. Витрина может быть реализована как «плашка, закрывающая контент», или как серия экранных форм, реализующая «выбор оптимального тарифа» для апсейла или как отдельный лендинг. Важно то, что пользователь видит только те офферы, которая предоставляет ему система, основываясь на его профиле (полях Golden Record) и их доступности, заведенной маркетологом в продуктовом каталоге.

Рис.7. Реализация принципа таргетинга коммерческих офферов на базе Order Capture и DMP Forward Telecom.
Рис.8. Динамические "Витрины офферов" в виде рекламных плашек на РБК-ПРО.

Также Order Capture осуществляет заказ выбранного пользователем оффера:

  • Формирование и расчет стоимости корзины (этого этапа на уровне пользовательского сценария может не быть);

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

  • Генерация «Thank you page».

Биллинг

Система, которая управляет подписками для конкретных клиентов:

  • Обеспечивает управление жизненным циклом подписок: старт, напоминания о необходимости продления, реализует саспенд-период и т.п.;

  • Обеспечивает инвойсинг, выставление счетов, отслеживания статусов оплат, активацию / дезактивацию подписок;

  • Обеспечивает акаунтинг – собирает и передает в бухгалтерские системы данные актирования услуг по согласованному протоколу;
  • Управляет личным счетом (монетарным балансом) клиента:

    - Формирует дефицит бюджета за счет списаний связанных с продажами и продлением услуг по тарифным планам;

    - Пополняет бюджет по информации от платежного шлюза или по банковской выписке;

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

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

Servive Provisioning. Включение / выключение услуг.

После того как подписка пользователя оплачена и активирована в биллинге – необходимо открыть доступы. Сигнал об этом со стороны коммерческой платформы отдает модуль SP.

Важной особенностью описанной архитектуры является то, что SP отдает не просто ID тарифного плана, но и набор входящих в него «атомарных» услуг. Это позволяет на стороне продуктового каталог и биллинга как угодно их группировать, управлять их ценами и т.п. «Продуктовое приложение» же ничего про эти группировки не знают – от SP они получают сигнал «Включить для пользователя Васи такой-то набор атомарных услуг / Выключить для Васи такой-то набор атомарных услуг».

* В исходном примере с овощами – можно провести следующую аналогию. В коммерческом офисе овощебазы пользователь оформил заказ на определенный объем продукции, там ему сделали расчет цен, оформили все необходимы документы, пробили кассовые чеки и выдали специальную накладную для склада, в которой содержится короткая выжимка – сколько какого товара ему нужно отгрузить. Кладовщик на складе таким образом может, не вдаваясь в детали коммерческой политики и даже не зная отпускных цен – отгрузить клиенту необходимый товар. Вот процедура обмена такими накладными между коммерческим офисом и складом и есть service provisioning.

В случае продаж контента, ИТ услуг – таким «продуктовым складом» может выступать веб-сайт, мобильное приложение, LMS, SAAS, телекоммуникационная система и т.п.

Заключение

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

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

С Уважением,
Терехов Антон.

0
Комментарии
-3 комментариев
Раскрывать всегда