Выбираем полезное действие и пробный лимит
Попросите потенциального клиента показать процесс, который сейчас выполняется вручную. Например, команда ежедневно сверяет обновления каталога. Предложите ограниченный метод, который возвращает только нужное изменение. Опишите объём выдачи, задержку обновления, ошибки и действия при повторной попытке. Дайте несколько тестовых запросов и попросите клиента встроить их в реальную задачу. Покупка полезна как проверка спроса, если команда действительно продолжает пользоваться методом после первой недели.
Для тарификации выберите понятную единицу: успешно обработанный запрос, объём записей или фиксированный пакет. Повтор не должен внезапно увеличивать счёт из-за сетевой ошибки. Согласуйте, как считаются ошибки, пробные запросы и выход за лимит. Покажите клиенту текущий счётчик и порог уведомления. Для пилота достаточно одного пакета и простого правила превышения. Заранее проверьте права на выдаваемые данные.
Документация Stripe о тарификации по использованию
Считаем затраты и сверяем фактическую выборку
Учебный пример: пять клиентов платят по 3 000 ₽, включая по 20 000 запросов. Выручка равна 15 000 ₽. За месяц прошло 60 000 учтённых запросов. Обработка одного стоит 0,06 ₽, всего 3 600 ₽. На поддержку и мониторинг ушло 4 000 ₽. Остаётся 7 400 ₽ до прочих расходов. Если клиенты использовали бы все 100 000 запросов, обработка стоила бы 6 000 ₽. Проверьте запас тарифа при полной загрузке и при росте тяжёлых запросов, а не только в среднем месяце.
Перед выставлением первого счёта сравните данные клиента с журналом сервера. Сохраните идентификатор операции, статус, дату, пакет и счётчик. На примере нескольких повторов проверьте, какое действие учитывается один раз. Если на стороне клиента другой часовой пояс, заранее согласуйте момент закрытия месяца.
Решаем, расширять ли тариф
После первого периода измерьте число активных интеграций, повторные запросы, долю успешных ответов, расходы и обращения в поддержку. Если все пять клиентов перестали пользоваться методом после пробы, сначала уточните, решает ли он регулярную задачу. Если нагрузка растёт, посмотрите, какие методы действительно создают издержки. Переносите их в отдельную тарификацию только после проверки и понятного объяснения клиентам.
Сохраните условия перехода с пилота. Укажите, когда включается новый лимит, как клиент увидит изменение и что произойдёт при превышении. Такая сверка помогает сначала продать полезный результат, затем масштабировать учёт и биллинг.