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