Личный кабинет есть, а клиент всё равно пишет менеджеру. Что пошло не так?

Клиент видит цену, но уточняет её у менеджера. Заказ отправляет через кабинет, а статус узнаёт по телефону. Разбираем, почему B2B-самообслуживание не работает и как найти причину до новых доработок.

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

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

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

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

Здесь начинается продуктовая задача, а не просто задача интерфейса. Где рассчитывается окончательная стоимость — в 1С, ERP, отдельном модуле? Когда цена пересчитывается: при открытии каталога, добавлении товара или подтверждении заказа? Что увидит пользователь, если условия договора изменились, а обновление ещё не дошло до кабинета? Если разработчики повторят сложные правила расчёта внутри личного кабинета, компания рискует получить две версии цены, которые рано или поздно разойдутся.

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

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

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

Закупка на несколько десятков строк мало похожа на поход по интернет-магазину. Часть артикулов приходит из системы клиента, по некоторым нужна кратность упаковки, какие-то позиции временно недоступны, а другие можно заменить аналогами. Если система заставляет добавлять всё по одной позиции, менеджер с Excel оказывается быстрее разработанной для самообслуживания корзины. Пять баннеров на главной странице тут не помогут.

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

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

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

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

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

Для продуктовой команды здесь важны границы ответственности систем. Где хранится заказ до передачи в ERP? Как кабинет узнаёт, что его приняли, а не отклонили из-за условий договора или отсутствия товара? Что увидит клиент, если ERP временно недоступна? И главное — что произойдёт, если он нажмёт кнопку ещё раз: появится второй заказ или система поймёт, что это повтор той же операции?

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

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

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

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

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

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

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

Такой сценарий есть в проекте VEKA, над которым работал DIGITAL SECTOR. Компания использует единое пространство для сотрудников, партнёров и дилеров: заявки поступают с сайта и других площадок, назначаются по установленным правилам, а каждая сторона видит данные в пределах своих полномочий. Если клиент выбрал конкретную точку продаж, заявка направляется ей; если нет, получатель определяется по правилам системы.

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

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

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

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

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

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

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

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

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

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

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

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