Я проектирую SaaS вокруг прогресса клиента, а не вокруг активности

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

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

Прогресс — не то же самое, что активность

Активность соблазнительно проста: входы, клики, созданные записи, открытые разделы. Эти цифры легко собрать. Прогресс сложнее, потому что он зависит от задачи клиента.

Допустим, руководитель подключил сервис, чтобы перестать узнавать о срыве заказа из звонка клиента. Его прогресс — не десять открытий раздела «Заказы». Прогресс наступает, когда он впервые увидел отклонение вовремя, задал вопрос ответственному и предотвратил неприятный разговор. Если продукт не ведёт к этому моменту, высокая активность ничего не доказывает.

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

Первый полезный результат должен быть конкретным

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

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

У хорошего первого результата есть четыре признака:

• он связан с работой клиента, а не с демонстрационным заданием;
• его можно получить без постоянного сопровождения менеджера;
• человеку понятна причина результата и следующий шаг;
• после него не требуется переносить всё обратно в Excel или чат.

Последний пункт я считаю важным тестом. Когда сотрудники продолжают вести параллельную таблицу «на всякий случай», это не их упрямство. Часто продукт ещё не взял на себя часть решения, ради которой его включили. Об этом хорошо напоминает ситуация, когда B2B-продукт перестают обходить в Excel: привычка возвращаться к старому инструменту обычно показывает незакрытую рабочую потребность.

Не обещать путь, который продукт не может провести

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

Я предпочитаю честно разделять два типа шагов. Есть то, что продукт может сделать сам: подсказать, проверить, напомнить, показать незаполненное поле. И есть то, что остаётся бизнес-решением: выбрать правило, назначить владельца, согласовать исключение. Второе нельзя прятать за кнопкой «Далее». Лучше объяснить, зачем решение нужно и кто должен его принять.

Это не делает путь длиннее. Напротив, он становится предсказуемым. У клиента не возникает ощущения, что сервис внезапно требует непонятной организационной работы. А у команды не появляется соблазн считать «неактивность» пользовательской проблемой, когда на самом деле не решён вопрос внутри компании.

Проверять прогресс в живом рабочем дне

Перед выпуском новой логики полезно взять один обычный сценарий и пройти его вместе с человеком, который будет пользоваться продуктом. Не просить его оценить интерфейс. Лучше спросить: «Как вы узнали бы об этом без системы? Что сделали бы дальше? Где пришлось бы остановиться?»

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

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

Три слоя, без которых прогресс не виден

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

Вторая вещь — доказательство движения. Оно должно быть ближе к работе, чем общий процент заполнения профиля. Например, «первый заказ передан без ручного письма» или «три позиции сверены по новому правилу». Человеку не нужно объяснять, почему это важно: он узнаёт свою задачу.

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

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

Онбординг не должен быть экскурсионным маршрутом

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

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

Прогресс клиента — повод для разговора, а не автоматическая оценка

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

Такой разговор даёт продукту больше, чем попытка построить единый «балл здоровья» клиента. Балл может подсветить, куда посмотреть. Но ценность всегда живёт в конкретной работе: кто-то ускорил согласование, кто-то перестал сверять таблицы, кто-то впервые спокойно передал задачу коллеге.

Где команда чаще всего обманывает себя

Первая ловушка — принять завершение настройки за результат. Клиент подключил интеграцию, пригласил коллег и заполнил поля. Для команды это заметное событие, и его хочется считать успехом. Но настройка только открывает возможность работать. Пока она не изменила действие человека, ценность остаётся гипотезой.

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

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

Небольшая проверка перед следующим релизом

Я бы собрал команду на полчаса и попросил её закончить три предложения. «После релиза пользователь сможет…». «Мы увидим, что это случилось, когда…». «Если этого не произойдёт, сначала проверим…». Эти фразы убирают часть спорных задач ещё до разработки.

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

Результат должен быть доступен без перевода с языка продукта

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

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

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

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

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

Если продукт развивается быстро, очень легко добавлять возможности по очереди. Одна просьба клиента, затем другая, затем новая настройка. В какой-то момент список функций растёт, а путь к результату становится менее понятным.

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

SaaS становится частью работы не тогда, когда в нём много возможностей. Он становится частью работы, когда человеку проще пройти важный путь в нём, чем рядом с ним.