Бизнес-модель продажи и использования ПО
Отток в массовом B2B SaaS почти всегда рождается не в недовольстве продуктом, а в первых днях после покупки, до того как клиент дошёл до реального результата. Чинит его онбординг, а не запуск программы удержания.
Пользователи открывали мое приложение VibeLing и не понимали, что учить. Я добавил готовые коллекции и долго считал проблему решенной.
Но однажды открыл собственный словарь сербского и понял: все это время я решал не ту проблему.
С этого материала хочу начать небольшую серию квартальных обзоров рынка конструкторов сайтов и CMS. Сервисы сейчас развиваются настолько быстро, что уследить за всеми релизами, сменой подходов и новыми технологиями становится все сложнее. Поэтому раз в несколько месяцев буду собирать наиболее заметные изменения в одном месте и смотреть не только на то, какие функции появились, но и на то, куда в целом движутся сами платформы. Этот летний дайджест будет первым выпуском такой серии.
Всем привет! Это Денис Сметнев. Я тут рассказываю про вайбкодинг, про то, как один человек теперь может заменить команду, и как узкое горлышко переместилось из разработки в сторону маркетинга. При этом я наставник у ребят, которые пилят SaaS, но не справились бы без разработчиков. Речь про Reels-Boss — сервис, который нарезает длинные видео на вирусные вертикальные куски для Shorts, Reels и TikTok. Рассказываю, как ребята втроем обслуживают 50 000 клиентов и почему вайбкодеры не справятся с таким сервисом.
Первый запуск рекламы:
5 929 переходов
3 289 целевых действий
CR (доля посетителей, которые совершили нужное нам действие) — 55,47%
CPA (сколько нам стоило одно такое действие) — 6,89 ₽
Для нас целевым действием было первое реальное действие на онлайн-доске. Больше половины людей не просто приходило, а реально начинало пользоваться доской. На первый взгляд результаты были почти идеальными. Оставалось прикрутить монетизацию и можно было считать будущую выручку.
Или же нет? Мы детальнее посмотрели, возвращались ли пользователи.
Почти никто.
AI-сервисы, API и SaaS всё чаще переходят от фиксированной подписки к оплате за фактическое использование. Если клиент пользуется сервисом больше, он платит больше, если меньше — меньше. Такой подход кажется простым, пока не начинаешь внедрять его в реальном продукте. Здесь легко ошибиться и с самой тарифной логикой, и с учётом потребления. В статье собрала 10 ошибок, которые встречаются при внедрении pay as you go.
Я делаю сервис, который разворачивает проекты юзеров на их серверах.
Разбираю на своём примере три вещи, которые нужны любому, кто просит доступ к секретам пользователя. Что просить, как хранить и что делать, когда сузить права нельзя в принципе.
Дальше практика с кодом. Почему в ключе стоит метка, почему сам ключ встречается в команде ровно один раз, и три места, где я налажал.
Кому полезно: тем, чей сервис просит доступ к секретам своих пользователей (серверы, репозитории, токены), да и в общем всем кто как-то связан с этой темой.
За последнее время с помощью вайбкодинга я сделал пять сервисов, которые реально используются в работе: мониторинг резервных копий, управление доступами, контроль дежурств, сканер уязвимостей и интерфейс для управления firewall.
Но все они решали внутренние задачи компании. Теперь хочу проверить более интересную гипотезу: можно ли тем же способом одному человеку сделать полноценный продукт для внешних пользователей — и в итоге получить сервис, за который люди действительно будут готовы платить.
В статье рассказываю, почему после пяти рабочих внутренних проектов решил взяться за собственный SaaS, что именно собираюсь делать и почему выбрал для этого AI-сервис для разбора юридических документов.
Собрал 6 AI-роутеров с бесплатным доступом к Claude, GPT, DeepSeek, Qwen и другим моделям. Показываю, что реально дают после регистрации: баланс, доступные модели, лимиты и нюансы работы через API.
Это разбор одного канала для B2B-сервиса со сложным продуктом: как за 18 месяцев переходы из нейросетей выросли практически с нуля до 845 и почему три четверти этого трафика дала Алиса, а ChatGPT остался далеко позади. Если вы отвечаете за привлечение в онлайн-сервисе и прикидываете, стоит ли вкладываться в оптимизацию под нейросети, дальше механика без маркетинговой воды: схема замера из трех сигналов, что чинили на сайте, какую микроразметку раскладывали и как выглядит выгрузка по шести нейросетям. Клиент под NDA, поэтому обезличиваю по роду деятельности, но цифры реальные, из Яндекс Метрики, выборка 100 процентов.
За месяц восемь почтовых ящиков отправили 6021 письмо по 2107 компаниям, и с этого объема пришло 204 ответа и 19 квалифицированных лидов, при этом баунс так и остался на четырех процентах, а из строя за все время не вышел ни один ящик. Пишу для тех, кто отвечает за лидогенерацию в узком B2B-сервисе и приглядывается к холодному аутричу как к дополнительному каналу. Маркетинговую часть я тут почти опущу и разберу инженерную: как считали дневные лимиты, чем и по сколько грели ящики, зачем городили домены-двойники и как ответы уходили в CRM, минуя ручной разбор почты.
Привет, на связи Дмитрий. У меня на руках аккаунт, в котором поисковый и охватный контуры размечены раздельно, а замеры доведены до квалифицированной заявки и продажи в CRM. Если вы отвечаете за рекламу веб-сервиса и в команде идёт вечный спор, надо ли держать горячий и латентный спрос в разных кампаниях, дальше цифры этого аккаунта и решения, которые из них следуют.
Привет, на связи Дмитрий. У меня на руках аккаунт, в котором поисковый и охватный контуры размечены раздельно, а замеры доведены до квалифицированной заявки и продажи в CRM. Если вы отвечаете за рекламу веб-сервиса и в команде идёт вечный спор, надо ли держать горячий и латентный спрос в разных кампаниях, дальше цифры этого аккаунта и решения, которые из них следуют.
Содержание
1. Почему одна структура аккаунта не тянет оба типа спроса?
2. Как разметить аккаунт, чтобы замеры вообще стали возможны?
3. Что показали замеры по типам трафика?
4. Почему дешёвый клик не означает дешёвую заявку?
5. Что происходит внутри автотаргетинга и что там можно отключать?
6. Почему по цене формы нельзя резать бюджет?
7. Сколько данных нужно, чтобы решение по кампании не было случайным?
8. Как собрать структуру под каждый контур и как делить бюджет?
9. Где структура ломается чаще всего?
10. Частые вопросы
Привет, на связи Дмитрий Шестаков. Мы в агентстве собираем сквозную аналитику для онлайн-сервисов с длинным циклом сделки, и почти каждый проект начинается с одной и той же сцены: Директ показывает одно число заявок, Метрика другое, CRM третье, и все три системы уверены в своей правоте. Ниже разберу наш стек как он есть — какие слои данных нужны, по каким ключам они связываются, чем забираем выгрузки, где спотыкались сами. С замерами реального проекта, где расход в Директе за период превысил полтора миллиона рублей. Если вы отвечаете за окупаемость трафика SaaS-сервиса, схема переносится почти без изменений.
Привет, меня зовут Надя, я продуктовый менеджер сервиса «Фейскит». Наша команда делает программу, которая помогает не терять шуруповерты, болгарки и пассатижи в суровой реальности стройки. Изначально мы задумывали продукт как простой и надежный способ учета инструментов и материалов. Но жизнь распорядилась иначе: за четыре года мы прошли путь от систематизации данных из Excel-таблиц до запроса на интеграцию с бухгалтерией. Рассказываю по порядку, как все было.
Открыть ТОО в Казахстане можно быстро. Сложнее понять, как это ТОО будет принимать платежи от клиентов из США и Европы.
Привет! Меня зовут Даша, я занимаюсь развитием сервиса Скорозвон — облачного решения для автоматизации коммуникаций в отделах продаж и колл-центрах. И я менеджер продукта.
На первый взгляд, продакт не самый очевидный автор статьи о работе с клиентами: текущими вопросами обычно занимается клиентский сервис. Но чтобы развивать продукт, недостаточно получать отдельные запросы через заявки, продажи и интервью. Важно понимать, как устроен бизнес клиента, с какими проблемами он сталкивается и каких результатов хочет достичь.
Собрать этот контекст нам помогли QBR — регулярные встречи, на которых клиент, сервис и продукт вместе обсуждают текущую работу, планы и дальнейшее развитие.
В статье расскажу, как мы пришли к этому формату, почему первая попытка собирать идеи клиентов в Excel не сработала, как устроены наши QBR и что они изменили для всех участников.
Привет, на связи Дмитрий Шестаков. Мы двенадцать лет строим управляемый маркетинг для SaaS и онлайн‑сервисов, и почти на каждом длинном цикле всплывает один и тот же спор: продукт должен продавать себя сам, или без отдела продаж платящих не будет. Триалы капают, а выручка прирастает там, где в сделку заходит живой менеджер, и непонятно, в какую модель вкладывать следующий бюджет. Ниже — как мы честно измеряли стоимость платящего клиента для product‑led и sales‑led модели на одном проекте, почему дешёвая на первый взгляд модель роста SaaS часто выходит дороже и какой контур аналитики для этого нужен. Если вы отвечаете за рост B2B SaaS или онлайн‑платформы, дальше будет по делу.
Содержание
1. Почему спор «продукт продает сам или продают менеджеры» нельзя решить на глаз
2. Что именно мы сравниваем: стоимость платящего клиента
3. Почему нельзя мерить модель по первому месяцу
4. Как мы собрали сквозной контур: от клика до оплаченной подписки
5. Что показал замер: где выигрывает самообслуживание, а где окупаются менеджеры
6. Как выбрать модель под свой продукт: 4 вопроса к юнит‑экономике
Слово «агент» в 2026 году встречается в описаниях почти любой CMS или конструктора сайтов – от Webflow до uCoz. Однако появление рядом с кнопкой «Редактировать» новой кнопки «Спросить AI» еще не означает, что архитектура платформы действительно изменилась.
Зачастую речь идет о переименованной функции генерации текста: это все же маркетинговое решение, а не появление полноценного агента. Различать эти сценарии важно не ради терминологической точности. От того, генерирует ли система один ответ или самостоятельно планирует и выполняет последовательность действий, напрямую зависят требования к правам доступа, аудиту, откату и подтверждению операций.
Ниже – попытка разобрать происходящее с точки зрения архитектуры, а не, порой, “пустозвонных” пресс-релизов сервисов.
Почему-то никто не говорит о том, кто будет поддерживать систему через год. Все обсуждают только, насколько быстро её можно написать.
Синяя галочка есть. Ответа нет. Мой собственный бот в MAX игнорирует моё же сообщение: сервер отвечает 200 OK, в логах чисто, а человек на другом конце ничего не видит. Так начались четыре вечера отладки Bot API нового российского мессенджера — четыре грабли, которых нет в документации. Где живёт токен. Почему 404 на чат, в котором ты прямо сейчас переписываешься. Как молча испаряется webhook-подписка. И почему MAX не говорит, которому из твоих ботов написали. Собрал всё, чтобы следующему хватило получаса вместо недели.