1 подписчик
Подписная дилемма
Я условно делю модели продаж на два типа: транзакционная и подписная.
Транзакционная подразумевает разовое взаимоотношение по необходимости. Захотел сегодня кофе — купил. То, что я буду покупать его регулярно, через одинаковые промежутки времени, не подразумевается.
Подписная же, наоборот, подразумевает. Онлайн-кинотеатр, страховка машины, аренда квартиры — чтобы это у меня было нужно платить по расписанию, регулярно.
Любопытный факт: значительная часть дохода онлайн-кинотеатров от людей, которые забыли про свою подписку. А ещё в фитнес-клубах годовые абонементы продаются со значительными скидками, потому что многие их покупатели посещают зал всего пару месяцев.
Заказная разработка дизайна или программы — это проект. Она заканчивается в тот момент, когда достигается цель. И оплачивается транзакционно. Чтобы заработать денег разработчик должен взять следующий заказ.
Заказы в разработке разные по сложности, объему и продолжительности. Из-за этого деньги поступают неравномерно: то пусто, то густо.
Что происходит, когда денег не хватает? Правильно, кассовый разрыв. Деньги как бы будут, но не сейчас. А расходы-то производить сейчас.
Где взять денег на расходы? Правильно, перекрыть авансом от следующего заказа. И с горящей задницей одновременно доделывать предыдущий заказ и начинать новый — деньги же взяли. Из-за этого страдают качество и сроки, а также отношения между заказчиком и исполнителем. Сплошной стресс для всех участников процесса.
Как же на этом фоне заманчиво выглядит подписная модель работы: предсказуемый объем работы в сочетании с предсказуемой оплатой по расписанию! Почти как в найме, только опции масштабирования нет.
Проблема в том, что характер продукта разработки обычно подписки не предусматривает. В отличие от коллег по цеху: СММщиков, таргетологов, директологов и прочих СЕОшников.
Или же есть конфигурация, когда разработчик дизайна или программ, работающий на заказ, может продавать свой продукт по подписной модели?
1 минута
21 ноября 2023