Почему я сначала ищу момент, когда пользователь перестаёт возвращаться к продукту

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

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

Регистрация ещё ничего не обещает

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

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

Я отделяю первый интерес от повторной пользы. Интерес отвечает на вопрос «почему человек попробовал». Повторная польза — «почему ему есть смысл открыть продукт снова в следующий раз». Между этими вопросами часто лежит настоящая работа над SaaS-сервисом.

Искать нужно не отток, а незавершённый смысл

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

Поэтому я спрашиваю не «сколько людей ушли», а «какую полезную работу человек пытался сделать перед тем, как исчезнуть». Такой вопрос заставляет смотреть не на красивую воронку, а на обычный рабочий сценарий.

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

Три места, где чаще всего обрывается возвращение

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

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

Третье — исключение. Красивый сценарий на демо почти всегда проходит. Реальная жизнь начинается, когда заказ меняет условия, клиент просит нестандартный документ, сотрудник в отпуске, данные пришли не полностью. Если для исключения нужно искать человека, который «знает, как тут принято», пользователь возвращается к ручному пути.

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

Четыре вопроса, которые я задаю до новой функции

Какое повторяющееся действие должно стать привычкой? Не «пользоваться CRM», а «менеджер после разговора фиксирует следующий шаг, чтобы руководитель видел сделку без отдельного звонка». Чем конкретнее действие, тем легче проверить, существует ли оно в реальности.

Что человек делает вместо продукта? Это может быть Excel, личные сообщения, старая программа или память опытного сотрудника. Замена часто не идеальна, но она уже встроена в день. Бороться нужно не с её недостатками в презентации, а с причиной, по которой она всё ещё удобнее.

Какой сигнал покажет, что польза случилась? Не обязательно сложная метрика. Иногда достаточно увидеть, что заявку передали без повторного ввода, отчёт использовали на планёрке или второй сотрудник смог продолжить работу без объяснения автора.

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

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

Пример без магии

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

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

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

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

Не все уходы надо исправлять

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

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

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

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

Как обсудить это с командой

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

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

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

Не путайте возврат с привычкой открывать экран

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

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

Здесь особенно важен контекст роли. Руководителю может быть достаточно вернуться раз в неделю и увидеть достоверную картину. Оператору требуется работать в системе весь день. Нельзя применять к ним одно ожидание частоты. Вопрос всегда один: помог ли продукт выполнить обещанную часть их работы без лишних обходных путей?

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

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

Что можно сделать на этой неделе

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

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

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