Смотря сколько details, смотря какой fabric
Блог: Сережа Будяков про всякое · Обновлено
Многие компании используют ценообразование в зависимости от размера использованных ресурсов своего сервиса. По английски это называется usage, и хрен нормально это на русский переведешь. Например AWS — облачный хостинг от Амазона, стоимость считается не за размер арендованного сервера, а за количество ресурсов, потраченных в месяц. Ресурсы в данном случае, это мегабайты, минуты процессорного времени и т.п.
На старте идея кажется отличной: пока мы используем сервис по минимуму, потому что у нас мало клиентов, чек за услуги получается небольшим. Все классно до момента, когда начинается рост. Затраты на сервис могут расти быстрее, чем новые клиенты будут платить за наши услуги, а значит юнит экономика может перестать сходиться. Но ведь мы не только AWS используем, а еще кучу других сервисов с похожими ценообразованием. В общем, вероятность вылететь в трубу растет, при этом управлять всем этим почти невозможно.
Плюс есть еще один неожиданный способ заполучить проблему — всплески использования из-за недобросовестных или добросовестных, но необдуманных действий юзеров. Какую-нибудь рассылку они отправят по сегменту «вообще всем», и вот мы в минусе на сотню-другую тысяч денег.
Допустим мы выжили, стали компанией побольше и у нас есть подобие закупочных процедур и бюджетирования. Как вообще засовывать все эти сервисы в бюджет? Может быть мы потратим 100 тысяч, а может быть 5 миллионов. «В зависимости от использования». Тут и для самого сервиса возникает неудобство: если непонятно сколько их клиент заплатит, значит вероятно платить он будет постоплатой. А это риск роста дебиторки.
В общем ни одного плюса в использовании такого способа монетизации для клиента в любом состоянии кроме самого начального, не наблюдается.
Если мы делаем сервис, и во что бы то не стало хотим брать плату за количество использованных ресурсов, то стоит предусмотреть плоский тариф, при котором мы можем ограничить количество ресурсов и получить фиксированную стоимость с клиента. Хорошим промежуточным решением могут быть пакеты: например миллион писем, или 1 терабайт места для вложений. Если пакет скоро закончится, можно купить новый. Или не покупать.
@twotimes
