Личный кабинет в B2B — это не витрина и не «модный раздел сайта». Это рабочее место закупщика, бухгалтера и снабженца, куда они заходят несколько раз в неделю, чтобы не писать письмо менеджеру. Мы делаем такие кабинеты и видим одну и ту же закономерность: полезным получается тот, что построен вокруг трёх-четырёх повторяющихся действий, а не тот, где выставлены наружу все возможности учётной системы. Ниже — как мы выясняем, что именно нужно клиенту, что кладём в кабинет обязательно и по каким признакам потом понимаем, что он работает.
С чего начинается кабинет: разбор переписки менеджеров
Перед проектированием мы просим доступ к обращениям: письма, переписку в мессенджерах, задачи в CRM или хотя бы список типовых тем от руководителя отдела продаж. Обычно набирается пять-семь формулировок, которые повторяются десятками раз: «где заказ», «пришлите счёт повторно», «какая у нас цена на эту позицию», «продублируйте закрывающие за прошлый квартал», «повторите прошлую заявку». Это и есть техническое задание на первый экран кабинета.
Такой разбор дешевле любого воркшопа с гипотезами и заодно защищает от типичной ошибки — попытки вынести в кабинет всю номенклатуру и все справочники из учётной системы. Корпоративный клиент редко работает с полным каталогом: у него есть ограниченный список позиций, которые он закупает регулярно, и договорные условия, которые его интересуют больше, чем описания товаров.
Второй источник данных — сами менеджеры. Мы спрашиваем не «что добавить в кабинет», а «на что вы тратите больше всего времени и что делаете вручную каждый день». Ответы обычно расходятся с представлениями руководства: чаще всего рутина — это повторная отправка документов и уточнение статусов, а не консультации по продукту.
Обязательный минимум
Набор разделов, без которого кабинет в B2B не окупается. Для каждого мы фиксируем не только состав, но и то, что проверяем на приёмке — иначе раздел легко сдать формально работающим и бесполезным на практике.
| Раздел | Какую задачу снимает | Что проверяем на приёмке |
|---|---|---|
| История заказов | Повтор прошлой закупки без обращения к менеджеру | Заказ годичной давности повторяется, даже если часть позиций снята с производства |
| Документы | Счета, акты, накладные и УПД доступны самому клиенту | Выгрузка пачкой за период, а не по одному файлу |
| Индивидуальные цены | Клиент видит свои договорные условия, а не общий прайс | Цены совпадают с учётной системой, скидка применяется на уровне позиции |
| Статусы отгрузки | Снимает основную часть звонков «где мой заказ» | Виден номер отгрузки и дата, статус обновляется без ручного вмешательства |
| Заявка на счёт | Сокращает цикл согласования и оплаты | Счёт формируется с реквизитами из карточки, доступен сразу |
| Взаиморасчёты | Долг, отсрочка и лимит видны без запроса в бухгалтерию | Сумма сходится с актом сверки, дата актуальности подписана явно |
| Пользователи и роли | Закупщик, бухгалтер и руководитель работают в одном контуре | Роли разделены по правам, приглашение сотрудника не требует нашего участия |
Несколько пользователей — это не «мелочь на потом»
В рознице покупатель один. В B2B решение принимают минимум двое: тот, кто формирует заявку, и тот, кто её согласует или оплачивает. Если кабинет спроектирован под одну учётную запись, клиент начнёт передавать пароль по кругу, и любая история действий потеряет смысл.
Мы закладываем роли на этапе прототипа, даже когда заказчик считает, что «пока хватит одного входа». Минимальная схема: закупщик оформляет заявки и видит цены, бухгалтер работает с документами и взаиморасчётами, руководитель видит всё и подтверждает заказы сверх лимита. Добавить роль в готовую систему дороже, чем предусмотреть её сразу: права затрагивают каждый экран.
Повторный заказ и ввод списком
Корпоративные закупки повторяются. Поэтому сценарий «повторить прошлый заказ» мы считаем главным, а не второстепенным, и проверяем его в крайних случаях: позиция подорожала, позиции нет на складе, часть номенклатуры заменена аналогом. Кабинет должен показать это до оформления, а не после.
Второй по важности сценарий — ввод по артикулам. Снабженец приходит с готовым списком в таблице и не собирается искать каждую позицию через каталог. Мы делаем поле быстрого ввода и загрузку файлом, а также разбор ситуаций, когда артикул написан с ошибкой или с другим разделителем. Обработка «грязного» списка с понятным отчётом о том, что распозналось, а что нет, экономит клиенту больше времени, чем любой фильтр в каталоге.
Как мы проектируем кабинет
- Собираем типовые обращения и составляем список повторяющихся действий.
- Описываем роли и то, что каждая из них должна делать самостоятельно.
- Рисуем структуру: что попадает на главный экран, что уходит в разделы второго уровня.
- Делаем кликабельный прототип без дизайна и проходим по нему сценарии вслух вместе с менеджерами.
- Показываем прототип двум-трём реальным клиентам и смотрим, где они останавливаются.
- Только после этого запускаем дизайн и обсуждаем интеграцию с учётной системой.
- После запуска собираем обратную связь и правим то, что мешает, а не то, что просто не нравится.
Порядок принципиален: прототип на бумаге переделывается за час, готовый экран с интеграцией — за несколько дней. Проверка на живых пользователях до дизайна снимает большую часть спорных решений.
Чего в корпоративном кабинете быть не должно
- Копии розничного магазина. Блоки «с этим товаром покупают» и подборки по настроению здесь не работают, а отсрочка, лимит и договорная цена работают.
- Карточки товара без остатка и срока поставки. Красивое описание не отвечает на единственный вопрос закупщика — когда будет и сколько есть.
- Обязательной регистрации через форму с длинной анкетой. Доступ выдаёт менеджер вместе с договором, а самостоятельная регистрация нужна разве что как заявка на подключение.
- Данных, которые обновляются раз в сутки, без указания времени актуальности. Если остаток вчерашний, это нужно писать прямо, иначе кабинету перестанут верить после первого расхождения.
- Обязательного заполнения полей, которые уже есть в договоре. Каждое лишнее поле в заявке — повод позвонить менеджеру и уточнить, что туда писать.
Интеграция и то, что с ней обычно идёт не так
Кабинет почти всегда живёт поверх учётной системы, и качество данных в ней определяет качество кабинета. До проектирования мы смотрим, что реально можно получить по обмену: остатки, цены по контрагенту, статусы документов, ссылки на печатные формы. Если каких-то данных нет или они появляются с задержкой, это меняет состав разделов — лучше честно показать меньше, чем показывать неверное.
Отдельно проговариваем поведение при недоступности обмена. Кабинет не должен показывать пустую таблицу как «нет заказов»: если данные не пришли, об этом нужно сказать словами и оставить возможность связаться с менеджером.
У производственной компании кабинет обычно показывает не только счета, но и стадию заказа: принят, в работе, готов к отгрузке. Эти статусы берутся из внутренней системы, поэтому кабинет проектируют вместе с ней — мы делаем CRM для производства, из которой такие данные и приходят.
Как понять, что кабинет работает
Мы не считаем успехом факт запуска. Признаки, что кабинет попал в задачу: доля заказов, оформленных без участия менеджера, растёт; типовые обращения «где заказ» и «пришлите документы» становятся редкими; клиенты заходят регулярно, а не один раз после рассылки о запуске. Обратный признак тоже понятен: если спустя несколько месяцев менеджеры отвечают на те же вопросы, что и раньше, кабинет закрывает не те задачи, и правильнее вернуться к разбору обращений, а не добавлять новые разделы.
Полезно смотреть и на поведение внутри: на каком шаге бросают оформление заявки, какие разделы не открывают вовсе, где чаще всего пользуются поиском. Раздел, в который не заходят полгода, — кандидат на удаление, а не на редизайн.
Если вы планируете кабинет для корпоративных клиентов или переделываете существующий, начните со сценариев и прототипов: это самая дешёвая стадия для изменений. Мы делаем проектирование веб-интерфейсов отдельным этапом — со сбором сценариев, кликабельным прототипом и проверкой на реальных пользователях. Расскажите о задаче, и мы предложим состав работ.
На проекте это отдельный этап: проектирование интерфейсов — сценарии, прототипы и проверка на живых пользователях.
