Разработка личного кабинета: что закладывать в первую версию, а что отложить
Менеджер отдела продаж тратит часть рабочего дня не на продажи, а на ответы: где мой заказ, пришлите счёт, дайте акт сверки за прошлый квартал, когда будет следующая поставка. Каждый такой вопрос — это переключение с текущей задачи, поиск информации в учётной системе и письмо или звонок. При десяти клиентах это терпимо. При сотне это уже отдельная должность, которую никто не вводил в штатное расписание.
Личный кабинет клиента или партнёра забирает эту рутину на себя: человек заходит и сам видит статус заказа, скачивает документы, смотрит историю платежей. Разработка личного кабинета в этом смысле не про «цифровизацию» — это способ убрать повторяющиеся запросы из очереди на менеджера и дать ответ мгновенно, без участия человека с обеих сторон. Разработка личных кабинетов и для клиентов, и для партнёров решает одну и ту же задачу — просто с разным набором данных на выходе.
Зачем разработка личного кабинета сайта окупается быстрее, чем кажется
Экономику здесь удобнее считать не в «улучшении сервиса», а в количестве обращений, которые перестают доходить до менеджера. Если сегодня на одного клиента приходится, скажем, два-три обращения в месяц по статусу заказа или документам, а кабинет закрывает половину из них — это уже ощутимое высвобождение времени, особенно если клиентов десятки или сотни.
Второй эффект — скорость ответа для самого клиента. Ему не нужно ждать рабочего дня и ответа менеджера, чтобы узнать, отгружен ли товар. Это особенно заметно в B2B, где решения по повторным заказам часто принимаются быстро, а задержка в получении статуса или счёта тормозит весь цикл сделки.
Минимальный состав первой версии
Для старта личному кабинету клиента обычно достаточно закрыть три-четыре сценария, из-за которых чаще всего пишут менеджеру:
Вход и профиль. Логин по email или телефону, базовые данные контрагента, смена пароля.
Статусы заказов или заявок. Список, фильтр по периоду, карточка с текущим статусом.
Документы. Счета, акты, договоры — то, что сейчас пересылают вручную по почте.
История взаиморасчётов. Баланс, оплаты, задолженность — если это применимо к модели бизнеса.
Этого набора хватает, чтобы кабинет начал снимать реальную нагрузку с первого месяца работы. Всё, что не входит в этот список, можно и нужно отложить до второй итерации — когда станет видно, чем реально пользуются, а что осталось невостребованным разделом в меню.
Что почти всегда просят зря на старте
Список того, что заказчики регулярно закладывают в ТЗ первой версии, хотя оно не окупает свою сложность на старте:
личный чат с менеджером внутри кабинета вместо интеграции с уже работающей почтой или мессенджером;
конструктор отчётов с произвольными фильтрами вместо трёх-четырёх готовых срезов, которые реально нужны;
многоуровневая система ролей «на вырост» при одном типе пользователя на старте;
мобильное приложение параллельно с веб-кабинетом — вместо адаптивной вёрстки, которая закрывает мобильный сценарий без отдельной кодовой базы;
личный кабинет для сотрудников самой компании внутри того же контура, что кабинет для клиентов, — это разные продукты с разными требованиями к доступу.
Каждый из этих пунктов не вреден сам по себе. Вред в том, что он откладывает запуск на месяцы ради функциональности, которой в итоге может воспользоваться два человека из сотни.
Узлы, которые дороже всего переделывать потом
Есть часть архитектуры, где ошибка на старте не устраняется правкой одного экрана — она требует пересмотра модели данных и часто миграции уже накопленной информации. На эти пять узлов стоит закладывать время на старте, даже если для первой версии нужна только простая часть.
Модель прав доступа и роли. Если на старте всем пользователям одной компании доступны одни и те же данные, а через полгода нужно развести доступ по подразделениям или по уровню (сотрудник контрагента видит меньше, чем директор) — это переделка модели данных, а не добавление галочки в настройках. Роли закладываются в структуру БД с первого дня, даже если в MVP всего одна роль.
Привязка пользователя к контрагенту. Частый случай: у одной компании-клиента несколько сотрудников, и все должны видеть общие заказы и документы, но не документы других компаний. Если изначально пользователь жёстко привязан к одной учётной записи без понятия «организация», разведение потребует переноса всех существующих аккаунтов на новую схему.
Источник данных и интеграция с учётной системой. Личный кабинет почти никогда не хранит данные сам по себе — он показывает то, что уже есть в 1С, CRM или другой учётной системе. Решение, как часто и каким способом данные синхронизируются (в реальном времени через API или пакетно раз в час), закладывается в архитектуру заранее. Смена подхода с ручной выгрузки на регулярную синхронизацию — это отдельная и не самая быстрая доработка.
Журнал действий. Кто и когда посмотрел документ, изменил заявку, скачал акт — это нужно не только для разбора спорных ситуаций, но и часто требуется по внутренним регламентам компании-клиента. Если логирование не встроено в архитектуру с начала, добавить его задним числом по всем действиям пользователей затратнее, чем включить с первого релиза.
Уведомления. Письмо или пуш о смене статуса заказа кажется второстепенной функцией, но модель подписок (кто на что подписан, как отключить конкретный тип уведомлений, куда слать — email, смс, push) завязана на структуру пользователей и ролей. Дешевле продумать её на старте, чем перестраивать под уже работающую базу пользователей.
Безопасность и персональные данные
Личный кабинет клиента почти всегда работает с персональными данными и часто с финансовой информацией — суммами договоров, реквизитами, историей платежей. Это не повод откладывать проект, но повод заложить несколько практик с первой версии, а не добавлять их после инцидента:
разграничение доступа так, чтобы пользователь физически не мог получить чужие данные через прямой запрос (не только скрыть ссылку в интерфейсе);
шифрование соединения и хранение паролей в виде хэшей, а не в открытом виде;
ограничение по попыткам входа и разумный тайм-аут сессии;
отдельное согласие на обработку персональных данных при регистрации, если кабинет собирает данные физлиц.
По общему правилу, если через кабинет обрабатываются персональные данные российских граждан, оператор данных обязан соблюдать требования 152-ФЗ «О персональных данных» — это касается заказчика как оператора, а не только технической реализации. Для типового B2B-кабинета с контрагентами это не превращается в отдельный проект, но состав данных и место их хранения стоит обсудить с юристом заказчика на этапе проектирования, а не после запуска.
Сроки и бюджет
Личный кабинет — это веб-приложение, и здесь применимы те же ориентиры, что и для разработки веб-приложений и MVP: от 350 000 ₽ и 6–10 недель на первую версию с набором функций, описанным выше. Итоговая цифра зависит от того, сколько интеграций нужно на старте — один источник данных или несколько систем сразу — и от сложности модели ролей, если она нужна уже в MVP, а не в следующей итерации.
Если кабинет вырастает из существующего сайта или его приходится делать вместе с сайтом, считать бюджет удобнее одним проектом: разработка сайта под ключ начинается от 80 000 ₽, и кабинет в этом случае становится одним из разделов, а не отдельной системой сбоку.
Частые вопросы
Сколько стоит разработка личного кабинета для клиентов?
Как веб-приложение первая версия личного кабинета обычно укладывается в вилку от 350 000 ₽ при сроке 6–10 недель. Итоговая цена зависит от количества интеграций с учётными системами и от того, нужна ли многоуровневая модель ролей уже на старте.
Личный кабинет на сайте для клиентов — это отдельный сайт или раздел существующего?
Технически это чаще отдельное веб-приложение со своей авторизацией, которое подключается к основному сайту через ссылку в меню или поддомен. Это не требует переделки основного сайта, но требует единого визуального стиля, чтобы переход между разделами не выглядел как переход на чужой ресурс.
С чего начать разработку личного кабинета клиента, если данные сейчас хранятся в 1С?
С определения способа синхронизации: часть данных можно вытягивать через API в реальном времени, часть — синхронизировать пакетно, например раз в час, если система не рассчитана на постоянные запросы. Этот выбор закладывается в архитектуру на старте, потому что от него зависит скорость обновления информации в кабинете.
Нужна ли личному кабинету партнёра отдельная роль от личного кабинета клиента?
Если у партнёров и клиентов разные наборы данных и разные сценарии — да, это разные роли внутри одной модели прав доступа, а не два отдельных кабинета. Разделение на уровне ролей дешевле в реализации и поддержке, чем два независимых приложения с дублирующейся логикой.
Можно ли обойтись без личного кабинета и присылать статусы вручную?
На небольшом количестве клиентов — можно, и это может быть разумным решением, если поток обращений не создаёт нагрузки на менеджеров. Смысл разработки личного кабинета появляется, когда количество однотипных запросов о статусе заказа или документах становится ощутимой частью рабочего времени сотрудников.
Какие сценарии войдут в первую версию кабинета, а какие подождут до второй итерации — вопрос конкретной задачи, и его проще решить в разговоре, чем угадывать по чужому чек-листу.