Личный кабинет клиента, партнёра и сотрудника: отличия и функции

Личный кабинет клиента, партнёра или сотрудника: чем отличаются сценарии

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

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

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

Почему нельзя начинать проектирование личного кабинета со списка функций

Список функций сам по себе не описывает будущий продукт. Одинаковые названия разделов могут скрывать совершенно разные процессы.

Например, раздел «Документы» в трёх системах будет решать разные задачи:

То же самое происходит с заявками, уведомлениями, историей операций и профилем. Поэтому проектирование начинается не с экранов, а с пользовательских сценариев.

Для каждого типа пользователя нужно определить:

С какой целью он входит в систему.

Какие данные должен увидеть сразу после авторизации.

Какие действия должен выполнить самостоятельно.

Какие действия требуют согласования или участия сотрудника компании.

Откуда поступают необходимые данные.

Что должно произойти после выполнения операции.

Только после этого имеет смысл формировать структуру интерфейса и функциональные требования.

Чем отличаются кабинет клиента, партнёра и сотрудника

Основное отличие заключается в характере отношений пользователя с компанией.

Такое деление не всегда бывает строгим. Один продукт может сочетать несколько моделей. Например, система может одновременно обслуживать дилеров, сотрудников дилера, внутреннего менеджера компании и администратора.

Но для каждого пользователя всё равно потребуется собственный сценарий и соответствующий уровень доступа.

Личный кабинет клиента: главный сценарий — самообслуживание

Клиентский кабинет должен позволять пользователю выполнять типовые действия без звонка оператору, переписки с менеджером и повторной передачи уже известных компании данных.

Конкретный набор функций зависит от бизнеса.

Такое деление не всегда бывает строгим. Один продукт может сочетать несколько моделей. Например, система может одновременно обслуживать дилеров, сотрудников дилера, внутреннего менеджера компании и администратора.

Но для каждого пользователя всё равно потребуется собственный сценарий и соответствующий уровень доступа.

Хороший клиентский кабинет отвечает минимум на пять практических вопросов:

что сейчас происходит с моим заказом или услугой;

какое действие я могу выполнить самостоятельно;

какие операции уже были выполнены;

сколько и за что я плачу;

что делать, если возникла проблема.

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

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

Личный кабинет партнёра или дилера: почему он сложнее обычного B2C-кабинета

B2C — business-to-consumer, то есть взаимодействие бизнеса с конечным потребителем. B2B — business-to-business, взаимодействие между организациями.

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

Например:

• руководитель;
• закупщик;
• бухгалтер;
• логист;
• менеджер;
• администратор организации.

Им требуются разные права и разные рабочие сценарии.

В B2B-кабинете могут использоваться:

• персональный каталог;
• индивидуальные цены и договорные условия;
• остатки;
• создание и повторение заказов;
• черновики;
• несколько адресов;
• статусы поставок;
• счета;
• акты;
• накладные;
• взаиморасчёты;
• претензии;
• коммерческие предложения;
• отчёты;
• управление сотрудниками организации.

Поэтому партнёрский кабинет нередко становится внешним интерфейсом сразу к нескольким внутренним системам компании. Пользователь видит единое пространство, хотя данные могут поступать из CRM, ERP, складского учёта, 1С и других решений.

ERP — система управления ресурсами предприятия. CRM — система управления взаимоотношениями с клиентами.

Главная задача здесь уже не просто «сделать обслуживание удобнее», а обеспечить устойчивый цифровой процесс взаимодействия двух организаций.

Чем кабинет партнёра отличается от кабинета обычного B2B-клиента

Партнёр и B2B-клиент — не всегда одно и то же.

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

• управление дилерскими точками;
• регистрация сделок;
• работу с закреплёнными территориями;
• получение маркетинговых материалов;
• подачу заявок на совместные активности;
• обучение;
• сертификаты;
• работу с лидами;
• отчётность;
• специальные партнёрские программы.

Поэтому сценарий определяется не самим термином B2B, а характером отношений между компаниями.

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

Это уже не классический сценарий «выбрать товар — оформить заказ». Кабинет становится рабочим инструментом для управления объектами партнёрской сети.

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

Личный кабинет сотрудника: другая логика продукта

Сотрудник не является покупателем компании, поэтому внутренняя система должна проектироваться вокруг рабочих и административных процессов.

Часто для таких решений используется понятие Employee Self-Service — сервис самообслуживания сотрудников.

Через кабинет сотрудник может:

• просматривать и изменять разрешённые персональные данные;
• подавать заявления;
• оформлять отпуск;
• создавать запросы на справки;
• работать с кадровыми документами;
• получать расчётные листки;
• отправлять обращения в HR;
• создавать заявки в IT;
• заказывать доступы и оборудование;
• отслеживать статусы запросов;
• пользоваться инструкциями и базой знаний;
• проходить обучение;
• получать внутренние уведомления.

При этом личный кабинет сотрудника и корпоративный портал — не обязательно одно и то же.

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

Одна функция — три разных пользовательских сценария

Наиболее заметно различие видно, если сравнить одинаковые функции.

Поэтому перенос структуры успешного клиентского кабинета в партнёрскую или внутреннюю систему практически всегда требует переработки бизнес-логики.

Какие интеграции нужны разным типам личных кабинетов

Личный кабинет редко является первичным источником всех отображаемых данных. Чаще он объединяет информацию из нескольких систем.

HRM — система управления кадровыми процессами, LMS — система управления обучением.

До разработки важно определить, где находится эталонная версия каждого типа данных.

Если информация о клиенте хранится в CRM, остатки — в ERP, заказы — в 1С, а бонусы — в программе лояльности, кабинет должен получать и обновлять эти данные по заранее определённым правилам.

Иначе возникает риск, что несколько систем начнут хранить разные версии одной информации.

Какие роли пользователей нужно определить до разработки

Роли нужно определить до проектирования интерфейсов и бизнес-логики, потому что они влияют не только на видимость разделов, но и на доступные действия.

В клиентском кабинете могут существовать пользователь, представитель клиента, специалист поддержки и администратор.

В партнёрской системе модель обычно сложнее:

• администратор организации;
• закупщик;
• бухгалтер;
• менеджер;
• руководитель;
• сотрудник компании — владельца платформы.

У сотрудника роли могут зависеть от должности и подразделения:

• сотрудник;
• руководитель;
• HR;
• бухгалтерия;
• IT;
• администратор.

При этом права следует описывать не только в формате «видит раздел / не видит раздел».

Для конкретной сущности могут отдельно разрешаться:

• просмотр;
• создание;
• редактирование;
• согласование;
• подтверждение;
• удаление;
• экспорт.

Подробное проектирование ролевой модели требует отдельной проработки, но базовые роли необходимо определить уже на старте проекта.

Когда несколько типов пользователей можно объединить в одной системе

Объединение возможно, если пользователи работают с общими данными и процессами, а права можно чётко разграничить.

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

Единая архитектура оправдана, когда:

• используются общие справочники и данные;
• процессы пересекаются;
• есть общие сервисы и интеграции;
• роли можно однозначно разделить;
• единая система упрощает сопровождение.

Но единая система не означает одинаковый интерфейс.

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

Как определить MVP личного кабинета

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

Плохой вариант первой версии:

«Профиль, новости, уведомления и несколько разделов, которые пока почти ничего не умеют».

Более полезный подход:

пользователь авторизуется → получает нужные данные → выполняет ключевую операцию → видит результат или статус.

Состав первой версии всегда зависит от конкретного бизнеса.

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

Чем отличается UX для клиента, партнёра и сотрудника

UX — пользовательский опыт взаимодействия с системой. Он должен учитывать не только внешний вид интерфейса, но и характер работы пользователя.

Поэтому визуально эффектный интерфейс не компенсирует плохо спроектированный рабочий сценарий.

Какие требования безопасности различаются

Безопасность зависит от типов данных и полномочий пользователей.

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

Но риски различаются.

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

В кабинете сотрудника права могут меняться вместе с должностью, подразделением и статусом работника.

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

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

Какие показатели использовать после запуска

Количество зарегистрированных аккаунтов само по себе мало говорит о пользе системы. Измерять стоит выполнение тех процессов, ради которых кабинет создавался.

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

Как проходит разработка личного кабинета

Процесс разработки обычно начинается задолго до программирования.

1. Определение пользователей. Фиксируются все группы, которые будут работать с системой.
2. Анализ бизнес-процессов. Описывается, как нужные операции выполняются сейчас и что должно измениться.
3. Определение ролей. Фиксируются полномочия и ограничения разных пользователей.
4. Описание пользовательских сценариев. Для каждого типа пользователя формируется последовательность действий от входа до результата.
5. Определение источников данных. Для каждого типа информации устанавливается система, в которой хранится эталонная версия.
6. Формирование интеграций. Определяется, какие данные должны передаваться между личным кабинетом и CRM, ERP, 1С, HRM и другими системами.
7. Приоритизация функций. Отделяется критически необходимая первая версия от функций последующего развития.
8. Проектирование архитектуры. Определяется техническая структура будущего решения и связи между компонентами.
9. UX-прототипирование. Пользовательские сценарии переводятся в экраны и взаимодействия.
10. Разработка. Реализуется утверждённая бизнес-логика и интерфейс.
11. Тестирование. Проверяются функции, интеграции, роли, права и ключевые сценарии.
12. Пилотный запуск. Система проверяется на ограниченной группе реальных пользователей.
13. Сбор аналитики. Анализируются ошибки, незавершённые сценарии и фактическое использование функций.
14. Развитие. Приоритет следующих доработок определяется на основе данных и обратной связи.

Приоритет следующих доработок определяется на основе данных и обратной связи.

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

Что нужно определить до обращения к разработчику

Заказчику не обязательно самостоятельно готовить подробное техническое задание. Гораздо важнее чётко описать бизнес-задачу.

Такого уровня описания уже достаточно, чтобы начать предпроектное обследование и перейти к формированию требований.

Основные ошибки при проектировании личного кабинета

Сначала придумать интерфейс, а потом бизнес-процесс.

В результате появляются аккуратно оформленные экраны, через которые невозможно нормально выполнить рабочую операцию.

Сделать одинаковый сценарий для всех пользователей.

Человек видит лишние функции, навигация усложняется, а управление доступом становится запутанным.

Перенести B2C-логику в B2B.

В продукте не учитываются организации, несколько сотрудников одного контрагента, договорные условия, документы и роли.

Проектировать кабинет сотрудника как клиентский сервис.

Не учитываются внутренние маршруты согласования, HR-процессы и корпоративная авторизация.

Не определить источники данных.

Одни и те же сведения начинают храниться в нескольких местах и постепенно расходятся.

Оставить роли на конец разработки.

Изменение ролевой модели может затронуть архитектуру, интерфейсы и бизнес-логику уже реализованных функций.

Попытаться автоматизировать всё в первом релизе.

Проект усложняется, а основной пользовательский сценарий остаётся незавершённым.

Не назначить владельца продукта после запуска.

Система продолжает работать, но перестаёт развиваться вместе с бизнес-процессами компании.

Как выбрать подходящий сценарий личного кабинета

Исходную модель можно определить по задаче пользователя.

Если человек покупает товар, получает услугу или управляет своим обслуживанием, нужен прежде всего клиентский сценарий.

Если пользователь действует от имени организации и участвует в коммерческих процессах, речь идёт о B2B-кабинете.

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

Если пользователь работает внутри организации, требуется внутренний кабинет сотрудника или Employee Self-Service.

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