В предыдущей статье мы разобрали, что такое оплата за использование и почему она все чаще становится стандартом для SaaS и AI-сервисов. Если коротко: она выравнивает интересы - вы зарабатываете больше тогда, когда пользователь получает больше ценности.
Но между «хочу перейти на UBP» и «биллинг по потреблению работает в продакшне» - несколько месяцев работы, несколько архитектурных решений и одна фундаментальная ошибка, которую совершает большинство команд. О ней - в шаге 2.
Это руководство для продуктовых команд, которые уже приняли решение о переходе и хотят понять: с чего начать, что строить самим, что брать готовым и как не застрять на полпути.
Но между «хочу перейти на UBP» и «биллинг по потреблению работает в продакшне» - несколько месяцев работы, несколько архитектурных решений и одна фундаментальная ошибка, которую совершает большинство команд. О ней - в шаге 2.
Это руководство для продуктовых команд, которые уже приняли решение о переходе и хотят понять: с чего начать, что строить самим, что брать готовым и как не застрять на полпути.
Шаг 1. Определите единицу тарификации до написания первой строки кода
Это единственное решение, которое сложнее всего изменить после запуска. Если ошибиться здесь, то придется переписывать логику сбора метрик, переучивать пользователей и объяснять, почему «раньше считали токены, а теперь считаем запросы».
Хорошая единица тарификации отвечает трём критериям:
Хорошая единица тарификации отвечает трём критериям:
- Коррелирует с ценностью. Пользователь понимает, за что платит, и воспринимает это как справедливое. «Токены» понятны разработчикам API, но не директорам по закупкам. «Обработанных документов» или «выполненных задач» - говорит на языке бизнеса.
- Масштабируется вместе с ростом. Когда пользователь получает больше ценности, то метрика растёт, выручка растёт автоматически. Не нужно звонить клиенту и уговаривать его «перейти на тариф выше».
- Легко объясняется в двух словах. Единицу, которую нужно объяснять со схемой на салфетке, не примут. Она вызывает недоверие и споры в поддержку.
Как выбрать: практический подход
Составьте список из 5 -10 кандидатов. Для каждого ответьте на вопрос: «Если наш лучший клиент удвоит потребление, то эта метрика удвоится?» Если нет, то это плохая единица.
Затем проверьте на простоту: объясните метрику вслух за 10 секунд. Если не получается, то выбирайте другую.
Затем проверьте на простоту: объясните метрику вслух за 10 секунд. Если не получается, то выбирайте другую.
Важно: начинайте с одной единицы. Усложнять всегда успеете - а вот упрощать уже работающую схему гораздо сложнее.
Шаг 2. Выстройте сбор метрик - это самая недооцениваемая часть
Вот та фундаментальная ошибка, о которой мы предупреждали в начале: команды начинают с биллинговой системы, не выстроив надежный сбор событий. В результате биллинг есть, но считает неправильно - пропускает события, задваивает их или теряет при сбоях сети.
Ключевое правило: данные о потреблении должны быть надежнее, чем все остальное в вашей системе. Потеря события - это потеря денег и, что хуже, потеря доверия клиента, которому потом придётся объяснять, почему сумма не сошлась.
Ключевое правило: данные о потреблении должны быть надежнее, чем все остальное в вашей системе. Потеря события - это потеря денег и, что хуже, потеря доверия клиента, которому потом придётся объяснять, почему сумма не сошлась.
Архитектурные требования к системе сбора метрик
Идемпотентность событий. Каждое событие должно иметь уникальный идентификатор. Если событие пришло дважды - оно учитывается один раз. Без этого любой сетевой сбой или повторная попытка превращается в двойное списание.
Буферизация и очереди. Не пишите метрики напрямую в биллинговую базу в момент события. Используйте очередь сообщений (Kafka, RabbitMQ, AWS SQS). Это защищает от потерь при перегрузке и позволяет обрабатывать пики без деградации core-продукта.
Атомарность транзакций. Если ваш продукт выполнил операцию - событие должно быть записано. Либо оба действия произошли, либо ни одно. Реализуйте через паттерн «outbox»: сначала пишите событие в локальную базу вместе с бизнес-транзакцией, затем асинхронно передаёте в биллинг.
Гранулярность хранения. Храните сырые события, а не только агрегаты. Это позволит пересчитать историю при изменении правил тарификации, разобрать спор с клиентом по детализации и отладить ошибки постфактум.
Буферизация и очереди. Не пишите метрики напрямую в биллинговую базу в момент события. Используйте очередь сообщений (Kafka, RabbitMQ, AWS SQS). Это защищает от потерь при перегрузке и позволяет обрабатывать пики без деградации core-продукта.
Атомарность транзакций. Если ваш продукт выполнил операцию - событие должно быть записано. Либо оба действия произошли, либо ни одно. Реализуйте через паттерн «outbox»: сначала пишите событие в локальную базу вместе с бизнес-транзакцией, затем асинхронно передаёте в биллинг.
Гранулярность хранения. Храните сырые события, а не только агрегаты. Это позволит пересчитать историю при изменении правил тарификации, разобрать спор с клиентом по детализации и отладить ошибки постфактум.
Шаг 3. Выберите модель тарификации под вашу аудиторию
В первой статье мы описали основные тарифные модели. Здесь - практические критерии выбора.
Pay-as-you-go (чистая постоплата)
Когда подходит: широкая аудитория с сильно разным потреблением, ранняя стадия продукта, когда вы еще не знаете паттерны использования.
Главный риск: непредсказуемость выручки. В месяц с низкой активностью счета у всех маленькие - ваш P&L зависит от потребления клиентов.
Решение: гибридная схема - фиксированный минимальный тариф плюс доплата за потребление сверх включенного объема. Минимальный тариф дает предсказуемую базу, компонент по потреблению добавляет рост сверху.
Главный риск: непредсказуемость выручки. В месяц с низкой активностью счета у всех маленькие - ваш P&L зависит от потребления клиентов.
Решение: гибридная схема - фиксированный минимальный тариф плюс доплата за потребление сверх включенного объема. Минимальный тариф дает предсказуемую базу, компонент по потреблению добавляет рост сверху.
Кредитная модель (предоплатные пакеты)
Когда подходит: AI-сервисы и API-платформы, нерегулярное потребление, B2C и SMB, которым сложно согласовывать переменные счета.
Главный плюс: предсказуемый cash flow - деньги приходят при покупке пакета, а не по факту потребления. Снижается и страх клиента перед «неожиданным счётом».
Детали реализации: у каждого клиента есть баланс. При каждом событии потребления баланс уменьшается на стоимость единицы. Когда баланс исчерпывается нужно уведомить клиента или заблокировать доступ.
Главный плюс: предсказуемый cash flow - деньги приходят при покупке пакета, а не по факту потребления. Снижается и страх клиента перед «неожиданным счётом».
Детали реализации: у каждого клиента есть баланс. При каждом событии потребления баланс уменьшается на стоимость единицы. Когда баланс исчерпывается нужно уведомить клиента или заблокировать доступ.
Шаг 4. Автоматизируйте расчет и выставление счетов
Если на предыдущих шагах все сделано правильно, этот шаг становится техническим: нужно периодически агрегировать сырые события, применять к ним тарифные правила и генерировать счета.
Требования к биллинговой системе для UBP
Прием статистики потребления через API. Биллинг должен принимать объемы потребления либо через прямые вызовы API, либо через загрузку файлов со статистикой. Важно: некоторые системы поддерживают только подписки с фиксированной ценой и не умеют работать с переменными объёмами.
Гибкие правила тарификации. Система должна позволять настраивать телескопические скидки, разные ставки для разных диапазонов, индивидуальные цены для конкретных клиентов - без разработки.
Автоматическая генерация документов. Счета должны формироваться по расписанию и уходить клиентам без ручного участия. Для B2B критично: акты, УПД, счета-фактуры с правильным НДС.
Интеграция с 1С. Для большинства российских B2B-компаний двусторонний обмен с 1С не опция, а обязательное условие. Без него бухгалтерский контур остаётся ручным.
Автоплатежи и grace-период. Когда счет выставлен - он должен быть оплачен. Хорошая система не просто делает один запрос на списание, а уведомляет клиента при ошибке и блокирует доступ только после дополнительного периода ожидания.
👉 Подробнее о том, как работают автоплатежи в LBX Биллинг, читайте в описании возможностей платформы.
Гибкие правила тарификации. Система должна позволять настраивать телескопические скидки, разные ставки для разных диапазонов, индивидуальные цены для конкретных клиентов - без разработки.
Автоматическая генерация документов. Счета должны формироваться по расписанию и уходить клиентам без ручного участия. Для B2B критично: акты, УПД, счета-фактуры с правильным НДС.
Интеграция с 1С. Для большинства российских B2B-компаний двусторонний обмен с 1С не опция, а обязательное условие. Без него бухгалтерский контур остаётся ручным.
Автоплатежи и grace-период. Когда счет выставлен - он должен быть оплачен. Хорошая система не просто делает один запрос на списание, а уведомляет клиента при ошибке и блокирует доступ только после дополнительного периода ожидания.
👉 Подробнее о том, как работают автоплатежи в LBX Биллинг, читайте в описании возможностей платформы.
Что строить самим, что брать готовым
Граница простая: все, что является конкурентным преимуществом вашего продукта делаете сами. Биллинговую инфраструктуру берёте готовой и интегрируете через API.
Шаг 5. Дайте клиентам прозрачность в реальном времени
Что должен видеть клиент:
Как реализовать:
Самый быстрый путь - встроить виджет LBX в личный кабинет вашего продукта. Клиент видит текущий баланс, историю потребления и управляет подпиской - внутри вашего интерфейса, без редиректа на сторонний портал. Настройка занимает один день.
Альтернатива - разработать собственный интерфейс на данных из биллингового API. Дольше, но даёт полный контроль над UX.
Важный принцип: прозрачность должна быть доступна до того, как клиент получит счет. Уведомление после выставления счета - уже слишком поздно.
- Текущее потребление за период - в единицах тарификации и в деньгах
- Уведомление об исчерпании лимита или по достижению заданного значения баланса
- Детализацию по дням или операциям (для разбора нетипичных всплесков)
Как реализовать:
Самый быстрый путь - встроить виджет LBX в личный кабинет вашего продукта. Клиент видит текущий баланс, историю потребления и управляет подпиской - внутри вашего интерфейса, без редиректа на сторонний портал. Настройка занимает один день.
Альтернатива - разработать собственный интерфейс на данных из биллингового API. Дольше, но даёт полный контроль над UX.
Важный принцип: прозрачность должна быть доступна до того, как клиент получит счет. Уведомление после выставления счета - уже слишком поздно.
Шаг 6. Запустите поэтапно - не переводите всех сразу
Переход на usage-based ценообразование для существующей клиентской базы - это изменение коммерческих условий, к которым клиентов нужно готовить заранее. Резкий переход без предупреждения ведет к оттоку, даже если новая модель объективно выгоднее для большинства.
Рекомендуемый порядок запуска
Фаза 1 - Новые клиенты (месяц 1 - 2). Переводите на новую модель только новых клиентов. Так вы тестируете всю систему - сбор метрик, тарификацию, биллинг, документооборот - на реальных данных без риска для существующей выручки.
Фаза 2 - Добровольная миграция (месяц 2 - 4). Предложите существующим клиентам перейти на новый тариф с явными преимуществами: первые 3 месяца по старой цене или расширенный пробный период. Часть перейдет сама. Это даёт данные о том, кто в каком сегменте потребления находится.
Фаза 3 - Принудительная миграция (месяц 4 - 6). Переведите оставшихся с уведомлением за 60 дней. Предоставьте инструменты для оценки нового счета: калькулятор на сайте или персональная оценка от менеджера. Клиентам, для которых новая модель явно невыгодна, - индивидуальные условия.
Фаза 2 - Добровольная миграция (месяц 2 - 4). Предложите существующим клиентам перейти на новый тариф с явными преимуществами: первые 3 месяца по старой цене или расширенный пробный период. Часть перейдет сама. Это даёт данные о том, кто в каком сегменте потребления находится.
Фаза 3 - Принудительная миграция (месяц 4 - 6). Переведите оставшихся с уведомлением за 60 дней. Предоставьте инструменты для оценки нового счета: калькулятор на сайте или персональная оценка от менеджера. Клиентам, для которых новая модель явно невыгодна, - индивидуальные условия.
Как подготовить клиентов к переходу
Распространенная ошибка - сообщать об изменении тарифов письмом «в лоб». Лучший подход - показать клиенту его текущее потребление в единицах новой тарификации еще до перехода: «Если бы вы уже платили по-новому, ваш счет за последние 3 месяца составил бы X, Y, Z рублей». Конкретные цифры убирают страх неопределённости.
Чеклист требований к биллинговой системе для UBP
Перед выбором или оценкой платформы проверьте наличие каждого пункта:
Тарификация
Сбор данных
Документы
Платежи
Клиентский интерфейс
Интеграция
- Объемные услуги с тарификацией по факту потребления
- Индивидуальная цена для конкретного клиента или договора
- Гибридный тариф: фиксированная часть + объемная
- Произвольные периоды тарификации
Сбор данных
- API для передачи статистики потребления
- Загрузка данных файлом (для batch-обработки)
- Детализация в счёте по услугам
Документы
- Автоматическое выставление счетов по расписанию
- Акты, УПД, счета-фактуры с правильным НДС
- Интеграция с 1С
- ЭДО (Диадок или аналог)
- Фискализация (для физлиц)
Платежи
- Автоплатежи
- Прямые интеграции с банками для загрузки выписок
- Управление финансовой блокировкой с настраиваемой отсрочкой
Клиентский интерфейс
- Виджет или ЛК с отображением текущего потребления
- Уведомления при достижении лимитов
- История финансовых операций и документов
Интеграция
- REST API с документацией и возможностью тестирования
- Вебхуки на ключевые события (изменение подписки, новый документ, блокировка)
- Sandbox для разработки и тестирования
Частые ошибки при внедрении
Запустили биллинг раньше, чем сделали сбор метрик. Результат: счета есть, но данные в них неточные. Разбирательства с клиентами, потеря доверия. Исправление занимает столько же времени, сколько первичное внедрение.
Выбрали единицу тарификации «по умолчанию» без проверки гипотезы. Технически удобная метрика (например, CPU-время или ГБ RAM) не всегда коррелирует с ценностью для клиента. Поговорите с 5 -10 клиентами до финализации решения.
Не настроили уведомления о потреблении. Клиент получает крупный счёт без предупреждения. Даже если счет справедлив - воспринимается как сюрприз и становится поводом для оттока или спора.
Перевели всех клиентов одновременно. Даже хорошо спланированное изменение вызывает поток вопросов в поддержку. Поэтапный запуск позволяет масштабировать поддержку по мере роста числа мигрировавших.
Не заложили в договор право изменять тарифные условия. Юридический вопрос, который обычно замечают слишком поздно: если договор зафиксировал конкретный тариф - его нельзя изменить без согласия клиента. Проверьте текущие договоры перед началом миграции.
Недооценили сложность для B2B-бухгалтерии. Переменный счет каждый месяц усложняет бюджетирование на стороне клиента. Решение: предложить минимальный фиксированный тариф как «потолок предсказуемости».
Выбрали единицу тарификации «по умолчанию» без проверки гипотезы. Технически удобная метрика (например, CPU-время или ГБ RAM) не всегда коррелирует с ценностью для клиента. Поговорите с 5 -10 клиентами до финализации решения.
Не настроили уведомления о потреблении. Клиент получает крупный счёт без предупреждения. Даже если счет справедлив - воспринимается как сюрприз и становится поводом для оттока или спора.
Перевели всех клиентов одновременно. Даже хорошо спланированное изменение вызывает поток вопросов в поддержку. Поэтапный запуск позволяет масштабировать поддержку по мере роста числа мигрировавших.
Не заложили в договор право изменять тарифные условия. Юридический вопрос, который обычно замечают слишком поздно: если договор зафиксировал конкретный тариф - его нельзя изменить без согласия клиента. Проверьте текущие договоры перед началом миграции.
Недооценили сложность для B2B-бухгалтерии. Переменный счет каждый месяц усложняет бюджетирование на стороне клиента. Решение: предложить минимальный фиксированный тариф как «потолок предсказуемости».
Сколько времени занимает внедрение
Реалистичные сроки при использовании готовой биллинговой платформы:
Итого от принятия решения до полного перехода - 4 - 6 месяцев. Критический путь - обычно интеграция сбора метрик, а не сама биллинговая система.
Итог
Переход на биллинг по потреблению - это проект, а не настройка.
Он требует правильной последовательности:
сначала единица тарификации → надёжный сбор метрик → выбор и интеграция биллинговой платформы → прозрачность для клиента → поэтапный запуск.
Самый частый способ застрять - начать с биллинговой системы, не выстроив надёжный сбор данных. Второй по частоте - переводить всех клиентов сразу.
Если вы сейчас на стадии выбора инструментов - посмотрите, как LBX Биллинг работает с объёмными услугами: тарификация по потреблению, телескопические скидки, передача статистики через API и двусторонняя интеграция с 1С уже есть в стандартной поставке.
👉 Записаться на демо - разберём вашу модель монетизации и покажем, как реализовать её технически.
Он требует правильной последовательности:
сначала единица тарификации → надёжный сбор метрик → выбор и интеграция биллинговой платформы → прозрачность для клиента → поэтапный запуск.
Самый частый способ застрять - начать с биллинговой системы, не выстроив надёжный сбор данных. Второй по частоте - переводить всех клиентов сразу.
Если вы сейчас на стадии выбора инструментов - посмотрите, как LBX Биллинг работает с объёмными услугами: тарификация по потреблению, телескопические скидки, передача статистики через API и двусторонняя интеграция с 1С уже есть в стандартной поставке.
👉 Записаться на демо - разберём вашу модель монетизации и покажем, как реализовать её технически.
Частые вопросы
Сколько стоит перейти на UBP?
При использовании готовой биллинговой платформы основные затраты - это разработка интеграции (сбор метрик, передача данных в биллинг).
Реалистично - 2-4 недели работы backend-разработчика. Разработка собственного биллинга с нуля обходится в 1 млн рублей и 3 - 6 месяцев.
Можно ли сочетать фиксированную подписку и оплату за потребление?
Да, и это самая распространённая схема в B2B SaaS. Фиксированный тариф покрывает базовый объём и даёт клиенту предсказуемость, доплата за превышение обеспечивает рост выручки пропорционально использованию.
Как отреагируют существующие клиенты на переход?
Реакция зависит от того, насколько прозрачно вы подготовите переход. Клиенты, которые потребляют мало, как правило, в выигрыше - их счёт снижается. Тяжёлые пользователи могут уйти или потребовать индивидуальных условий. Поэтапный запуск с данными о прогнозируемом счёте значительно снижает сопротивление.
Какой минимальный технический стек нужен для внедрения?
Для простого сценария достаточно: очередь сообщений (можно начать с Redis или даже PostgreSQL LISTEN/NOTIFY), API-интеграция с биллинговой платформой, webhook-обработчик для событий биллинга. Полный Kafka-стек нужен при высоких нагрузках (от нескольких тысяч событий в минуту).
При использовании готовой биллинговой платформы основные затраты - это разработка интеграции (сбор метрик, передача данных в биллинг).
Реалистично - 2-4 недели работы backend-разработчика. Разработка собственного биллинга с нуля обходится в 1 млн рублей и 3 - 6 месяцев.
Можно ли сочетать фиксированную подписку и оплату за потребление?
Да, и это самая распространённая схема в B2B SaaS. Фиксированный тариф покрывает базовый объём и даёт клиенту предсказуемость, доплата за превышение обеспечивает рост выручки пропорционально использованию.
Как отреагируют существующие клиенты на переход?
Реакция зависит от того, насколько прозрачно вы подготовите переход. Клиенты, которые потребляют мало, как правило, в выигрыше - их счёт снижается. Тяжёлые пользователи могут уйти или потребовать индивидуальных условий. Поэтапный запуск с данными о прогнозируемом счёте значительно снижает сопротивление.
Какой минимальный технический стек нужен для внедрения?
Для простого сценария достаточно: очередь сообщений (можно начать с Redis или даже PostgreSQL LISTEN/NOTIFY), API-интеграция с биллинговой платформой, webhook-обработчик для событий биллинга. Полный Kafka-стек нужен при высоких нагрузках (от нескольких тысяч событий в минуту).
