Я проверяю B2B-продукт на передаче дела коллеге, а не на красивой демонстрации

Я проверяю B2B-продукт не только на первом пользователе. Настоящая проверка начинается в день, когда человек уходит в отпуск, меняет роль или просто передаёт участок коллеге. Если в этот момент работа останавливается и нужен созвон с «тем, кто всё знает», продукт пока держит не процесс, а память одного человека.

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

Передача дела — обычный рабочий сценарий

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

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

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

Что должно остаться после передачи

Для этого не нужен многотомный регламент. Чаще достаточно, чтобы в системе были видны пять вещей.

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

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

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

Не путать передачу дела с обучением интерфейсу

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

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

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

Где обычно теряется нить

Самое слабое место — исключение. Обычный заказ идёт по понятному маршруту, а нестандартный попадает в «потом разберёмся». Менеджер помнит, что клиенту обещали особый срок. Руководитель помнит, что по этому договору нельзя менять цену. Бухгалтер знает, что документ уже исправляли. В системе при этом остаётся общий статус, который выглядит спокойно.

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

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

Какие детали стоит сделать видимыми

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

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

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

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

Проверка в трёх ролях

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

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

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

Небольшая проверка без большого проекта

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

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

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

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

Передача дела показывает зрелость продукта

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

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

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

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