Я считаю B2B-продукт привычным только тогда, когда его перестают обходить в Excel

Я считаю B2B-продукт привычным не в тот день, когда команда закончила разработку. И даже не в тот день, когда клиент подписал акт. Продукт становится частью работы, когда люди перестают держать рядом свой Excel-файл, чат с ручными напоминаниями и фразу «на всякий случай сделаю по-старому».

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

Покупка доступа — ещё не внедрение

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

Поэтому я не меряю старт количеством созданных учётных записей. Гораздо полезнее спросить: в каком конкретном рабочем моменте человек должен открыть систему сам, без напоминания? Не «использовать CRM», а проверить статус заказа перед звонком. Не «вести проект», а увидеть, кто ждёт решения по задаче до пятницы.

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

Обходной путь — это полезный сигнал

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

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

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

Сначала один сценарий, потом широкий запуск

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

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

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

Четыре вопроса к первому рабочему дню

Перед широким внедрением я бы обсудил с командой четыре простых вопроса.

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

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

Не путать обучение с поддержкой

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

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

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

Что считать хорошим признаком

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

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

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

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