Я не добавляю новый тариф в SaaS, пока не вижу, какой рабочий шаг он делает возможным

Я не добавляю новый тариф в SaaS только потому, что конкурент уже вывел похожую строчку в прайс. Тариф — это не ценник на витрине. Он обещает человеку, что в его рабочем дне станет возможным: согласовать заказ, подключить коллегу, увидеть картину по своему участку, не потерять историю при росте команды.

Если такого шага нет, тариф превращается в набор ограничений, которые приходится объяснять в переписке. Продажа вроде бы состоялась, а клиент через неделю спрашивает, почему привычное действие вдруг недоступно. Это плохое начало отношений с продуктом.

Сначала рабочий момент, потом название пакета

Я начинаю не с вопроса «какие функции положить в новый план», а с более приземлённого: в какой момент пользователь упирается в границу и что он хочет сделать дальше?

Например, небольшая команда ведёт заявки в одном пространстве. Пока ей достаточно одного ответственного, простой план честен. Но в какой-то момент руководитель хочет видеть, где заявка остановилась, а сотрудник — передать её коллеге без пересказа в мессенджере. Ценность следующего тарифа здесь не в абстрактной «расширенной версии». Она в сохранённом рабочем контексте.

Похожая логика работает с доступами, экспортом, интеграциями и хранением данных. Важно не назвать функцию «премиальной», а понять, какую самостоятельность она даёт. Я уже писал о моменте, когда SaaS становится готов к самостоятельной покупке: это происходит, когда базовый путь не приходится каждый раз объяснять вручную. Здесь полезно сначала проверить сам путь пользователя.

Три вопроса перед изменением тарифа

Первый: у кого именно появляется новая задача? Не «у бизнеса вообще», а у конкретной роли. Владелец хочет контролировать деньги, оператор — быстрее обработать обращение, администратор — безопасно выдать доступ. Один и тот же пункт прайса может быть полезен каждому из них по-разному.

Второй: можно ли описать результат без названия функции? «Сотрудник подключает коллегу и не теряет уже начатую работу» понятнее, чем «доступ для трёх пользователей». Это проверка на честность: если ценность нельзя рассказать простыми словами, возможно, в пакете пока лежит техническая деталь, а не готовый результат.

Третий: что случится, если человек останется на прежнем тарифе? Хорошая граница не наказывает. Она оставляет прежний процесс рабочим, но показывает, где новый способ экономит время, снижает риск или открывает следующий этап. Когда старый вариант намеренно ломают ради апгрейда, продукт начинает спорить с клиентом вместо того, чтобы помогать ему.

Ограничение должно быть видно раньше, чем оно остановит работу

Самый неприятный сценарий — обнаружить границу после уже проделанной работы: данные подготовлены, коллега ждёт приглашения, отчёт нужен к встрече, а система отвечает сухим запретом. В этот момент разговор уже идёт не о ценности тарифа, а о досаде.

Поэтому я предпочитаю показывать ограничение в контексте будущего действия. Не баннером на главной, а рядом с тем шагом, который человек действительно собирается сделать. И сразу объяснять две вещи: что останется доступно сейчас и какой рабочий результат появится после подключения следующего уровня.

Это не означает, что каждый экран должен продавать. Иногда человеку достаточно подсказки и возможности обсудить сценарий с командой. Но система не должна превращать важный рабочий шаг в загадку.

Не путать рост тарифа с ростом сложности

Есть соблазн сделать старшие планы просто длиннее: больше переключателей, больше ролей, больше интеграций. Так возникает дорогой тариф, который трудно настроить и ещё труднее поддерживать. Пользователь покупает свободу, а получает второй набор обязанностей.

Я смотрю на старший уровень иначе: он должен убирать ручную связку между людьми или делать ответственность понятнее. К примеру, передача владения аккаунтом — не смена адреса в профиле, а отдельный процесс с проверкой доступа, истории и дальнейших прав. На этом примере хорошо видно, почему «добавить возможность» недостаточно.

Если новая функция требует отдельного обучения, стоит честно заложить это в сценарий: шаблон, подсказку, короткий мастер настройки или помощь специалиста. Тариф не обязан быть полностью без участия человека, но он обязан быть понятным по пути от оплаты до первого полезного результата.

Как проверить идею до изменения прайса

Я бы не начинал с массовой перестановки планов. Достаточно выбрать несколько реальных ситуаций, в которых команда уже дошла до границы. В каждой спросить: что человек хотел закончить, какое решение принял, где потерял время, какая помощь была бы для него естественной?

После этого полезно собрать короткую карту: роль → момент → препятствие → нужный результат → понятная граница тарифа. Она быстро показывает, где один новый пакет пытается решить пять несвязанных проблем. Такие случаи лучше разделить: часть задач может относиться к настройке продукта, часть — к поддержке, а часть вообще не должна быть платным ограничением.

Хороший тариф похож на хорошо устроенный инструментальный ящик: не радует количеством отделений, а помогает быстро найти нужное в нужный момент. Если после его появления клиент делает важный шаг спокойнее и без обходных путей, у изменения есть смысл.

Отделить ценность от способа реализации

Пользователь редко покупает «три автоматизации» или «десять интеграций» как таковые. Он покупает возможность не собирать сводку вручную по пятницам, вовремя передать задачу или не держать список доступов в заметках телефона. Техническое решение может меняться, а обещание рабочему процессу остаётся. Именно его стоит держать в центре тарифа.

Это особенно заметно, когда команда просит добавить в старший пакет новый отчёт. Сначала полезно выяснить, какое решение должен поддержать отчёт. Если он нужен, чтобы руководитель заметил риск до звонка клиента, важно не только отдать таблицу, но и определить свежесть данных, владельца показателя и момент, когда на него надо реагировать. Иначе дорогая функция будет использоваться как ещё один файл в папке.

Проверка простая: если заменить название функции на результат, не изменится ли смысл предложения? «В этом тарифе команда видит просроченные согласования до того, как они сорвали срок» — понятное обещание. «В этом тарифе есть модуль контроля» — только техническая этикетка.

Когда не нужно делать отдельный тариф

Не каждая просьба означает новый пакет. Иногда нестандартный процесс лучше решить внедрением, консультацией или отдельным дополнением. Иногда возможность нужна всем пользователям ради безопасности и её нельзя прятать за уровнем. А иногда проблема возникает из-за запутанного базового пути — и тогда честнее улучшить сам продукт.

Я считаю полезным прямо фиксировать такие решения. Это защищает команду от коллекции случайных исключений, а клиента — от ощущения, что за каждую мелочь нужно доплачивать. Тарифная сетка остаётся небольшим набором понятных ступеней, а не музейной витриной всех когда-либо появившихся функций.

Что проверить после запуска

После изменения тарифа я бы смотрел не только на выручку. Важнее первые рабочие сигналы: где люди останавливаются, о чём спрашивают поддержку, сколько раз менеджер вручную объясняет разницу, удалось ли пользователю завершить обещанный шаг. Если обращения повторяются вокруг одного места, это повод поправить путь, а не сразу писать новый скрипт продаж.

Стоит отдельно следить за ситуациями, когда команда сама переводит клиента на другой план. Разовый перенос может быть заботой. Постоянный — знак, что границы тарифов не соответствуют реальным сценариям. Такие случаи лучше собирать как продуктовую обратную связь, а не считать исключениями, которые надо забыть.

Со временем тариф становится частью архитектуры продукта: он влияет на роли, права, данные и поддержку. Поэтому изменения полезно обсуждать с теми, кто отвечает не только за продажи, но и за внедрение, сопровождение и развитие. Тогда обещание в прайсе не расходится с тем, что человек увидит после оплаты.

Короткая проверка

• Названа конкретная роль и её рабочая ситуация.
• Ценность объясняется результатом, а не названием функции.
• Старый тариф остаётся честно работоспособным.
• Ограничение видно до того, как пользователь потратил время.
• Первый полезный результат нового уровня можно пройти без догадок.

Тогда тарифы помогают продукту расти вместе с клиентом, а не становятся таблицей, которую приходится защищать на каждом созвоне.