Личный кабинет клиента и B2B-каталог на сайте: архитектура, роли и приёмка по ПМИ

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

Ниже на примере пяти наших проектов — от строительного каталога на 57 домов до генеалогической платформы «4 в 1» с собственным мессенджером — разбираем, чем B2B-каталог отличается от розничной витрины, как проектируются роли и безопасность в личном кабинете и почему сложные веб-сервисы принимают по программе и методике испытаний (ПМИ)¹.

Когда бизнесу достаточно сайта-каталога, а когда нужен личный кабинет

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

Чтобы не переплачивать за лишнюю серверную разработку на старте, мы всегда делим задачи на три ступени сложности:

Как устроен продающий B2B- и инженерный каталог без «пустых» карточек

Главное отличие B2B- или строительного каталога от обычного магазина одежды — покупатель выбирает не глазами по фотографии, а по техническим допускам, комплектующим, удельному расходу и наличию разрешительной документации. Если в карточке товара лежит только картинка и кнопка «Узнать цену», снабженец или инженер закроет вкладку и уйдёт к конкуренту, у которого выложены таблицы характеристик и PDF-паспорта.

В проектах производственных и строительных компаний мы закладываем в архитектуру каталога четыре прикладных механизма:

1. Прикладной калькулятор нормы расхода прямо в карточке. Покупателю редко нужен просто «концентрат в канистре 10 литров» — ему нужно решение для своего объекта. В интернет-магазине производителя химии КЕНАЗ мы собрали калькулятор объёма бассейна для круглой, овальной и прямоугольной чаши с постоянной и переменной глубиной. В карточках дозировка указана на 10 м³, а калькулятор сразу пересчитывает, сколько литров препарата нужно на конкретный объём воды покупателя.
2. Реестр сертификатов и паспортов безопасности, привязанный к товарам. В B2B-закупках и поставках для учреждений товар не купят без свидетельства о госрегистрации (СГР), декларации соответствия и паспорта безопасности. В том же проекте КЕНАЗ мы перенесли и привязали к 42 товарам с фасовками 118 официальных документов и сделали отдельный раздел «Сертификаты» с мгновенным поиском по названию препарата.
3. Посадочные страницы срезов каталога под поисковый спрос. В каталоге строительной компании СИП Элемент 57 проектов домов разбиты на 6 категорий по этажности и площади, а отдельно вынесены страницы СИП-панелей и домокомплектов с дилерским прайсом по трём типам панелей. Каждая такая страница размечена микроразметкой Product, ItemList и BreadcrumbList и сама служит точкой входа из Яндекса и Директа.
4. Гео-структура внутри единого домена вместо сети поддоменов. Когда поставщик технических газов БаллонМирГаз выходил в поиск по Московской области, заказчик хотел скопировать схему конкурента с десятками городских поддоменов. Мы отговорили от дробления: собрали 37 гео-страниц городов внутри одного домена с собственными ценами доставки и микроразметкой LocalBusiness. В результате ссылочный и поведенческий вес копится на основном домене, а администрирование занимает минуты в одной панели.

Архитектура личного кабинета: клиентский контур и профи-кабинет сотрудников

Настоящий личный кабинет редко ограничивается одним экраном «Мои заказы». Как только компания переводит в цифру длительную услугу — проектирование, строительство, юридическое сопровождение, архивное исследование или оптовые поставки — система делится на два связанных контура: клиентский кабинет (для заказчика) и профи-кабинет (рабочее место менеджеров, исполнителей и руководителя).

Показательный пример такой архитектуры — разработанная нами в 2026 году платформа «Агрегатор Архивов» для генеалогического центра «Семейная реликвия». До запуска данные жили в четырёх разных местах: старый сайт на NetCat, таблицы учёта, переписка в сторонних мессенджерах и файлы в почте. Мы объединили их в единую систему на стеке React + Fastify + PostgreSQL:

• Беспарольный вход и управление согласиями. Клиент входит по одноразовому коду из письма, сессии хранятся на сервере, а в профиле в любой момент видны выданные согласия на обработку персональных данных по 152-ФЗ² с возможностью их отзыва.
• Дорожная карта проекта и поэтапная оплата. Исследование рода длится месяцами и состоит из 10 этапов. В кабинете клиент видит прогресс по каждому этапу, промежуточные находки, историю операций, может пополнить баланс через Robokassa (с автоматическим расчётом комиссии) или выставить счёт на юрлицо и оплачивать этапы по графику.
• Сложные интерактивные инструменты без внешних облаков. Внутри кабинета работает анкета исследования на 84 поля с автосохранением, построитель родословного древа до 3 000 персон в четырёх видах с импортом и экспортом стандарта GEDCOM и генерацией родословной книги по системе д’Абовиля в PDF, а также семейный медиаархив с загрузкой пачек файлов до 40 МБ и сканированием документов камерой телефона.
• Профи-кабинет для команды с ролевой моделью. У сотрудников четыре роли: менеджер, генеалог, руководитель производства и администратор. На дашборде видны активные проекты, просрочки по этапам, загрузка специалистов и финансы отдела, а оповещения клиенту отправляются по расписанию с предпросмотром.
• Идемпотентная миграция со старой системы. При запуске мы перенесли со старого сайта более 1 100 пользователей, 57 активных проектов со всей историей и 1 400 архивных файлов без остановки работы компании.

Встроенные коммуникации: когда бизнесу нужен свой мессенджер вместо Telegram-чатов

Когда сотрудники ведут десятки клиентских проектов в обычных мессенджерах, компания сталкивается с тремя рисками: рабочие файлы теряются в личных переписках при увольнении менеджера, пересылка паспортов и договоров через иностранные мессенджеры нарушает ч. 8 ст. 10.6 Закона № 149-ФЗ и правила трансграничной передачи по 152-ФЗ³, а звонки через зарубежные сервисы нестабильны.

Для «Семейной реликвии» мы разработали собственный защищённый мессенджер Relic Chat на базе Fastify, PostgreSQL, Redis, Socket.IO и WebRTC и связали его единым входом (SSO) с кабинетом «Агрегатора Архивов»:

• Связка с карточкой проекта: рабочий чат создаётся прямо из карточки проекта в профи-кабинете, а все присланные в переписку архивные документы и фотографии каждые 15 минут автоматически синхронизируются в клиентский медиаархив.
• Полноценный обмен файлами и звонки в браузере: поддерживается передача файлов до 80 МБ, предпросмотр PDF, Word, Excel и CSV прямо в окне чата без скачивания (с серверной очисткой документов от исполняемого кода), голосовые сообщения с волной и аудио/видеозвонки один на один и в группах через собственный TURN-сервер с демонстрацией экрана и нейросетевым шумоподавлением на устройстве.
• Мобильное приложение без цензуры сторов: мессенджер имеет две отдельные вёрстки (десктопную с контекстным меню по правому клику и мобильную со шторками и жестом «назад»), устанавливается на экран смартфона как PWA-приложение без App Store и Google Play и присылает Web Push-уведомления при закрытой вкладке.
• Бесшовное обновление под нагрузкой: при переводе более 260 активных пользователей на новый интерфейс в октябре 2026 года переключение заняло несколько минут в 6 утра — ни одного пользователя не разлогинило, а все 25 000 сообщений и 3 000 файлов остались на своих местах.

Четыре технические детали, на которых держится безопасность кабинета

Личный кабинет работает с деньгами, договорами и персональными данными, поэтому к его серверной части предъявляются более строгие требования, чем к публичному сайту:

// Пример проверки доступа на уровне объекта (защита от IDOR) в Fastify:
// проверяем не только факт входа, но и принадлежность проекта текущему пользователю или роли сотрудника
app.get('/api/projects/:projectId/documents', { preHandler: [ app.requireAuth ] }, async (req, reply) => {
  const { projectId } = req.params;
  const user = req.user; // из подписанной серверной сессии (HttpOnly, SameSite=Lax)

  const project = await db.findProjectAccess(projectId, user.id, user.role);
  if (!project) {
    return reply.code(404).send({ error: 'Проект не найден или доступ запрещён' });
  }
  return db.listProjectDocuments(projectId);
});

1. Проверка прав на сервере для каждого объекта (защита от IDOR). Скрыть кнопку «Удалить» или чужой счёт в React-интерфейсе недостаточно. Каждый API-запрос на скачивание документа, просмотр анкеты или смену статуса проверяет на сервере в базе данных, принадлежит ли этот проект текущему клиенту или назначенному специалисту.
2. Управляемые серверные сессии. Вместо долгоживущих токенов в localStorage, которые невозможно отозвать при краже ноутбука, мы используем короткие токены и защищённые HttpOnly-куки с хранением сессий в Redis или PostgreSQL: кнопка «Выйти на всех устройствах» или блокировка сотрудника администратором мгновенно гасит доступ на сервере.
3. Изоляция и очистка загружаемых файлов. Пользовательские файлы не складываются в публичную папку веб-сервера, откуда их можно подобрать перебором ссылок. Они отдаются через авторизованный роут с проверкой прав, а документы Office и PDF проходят фильтрацию, чтобы исключить XSS-атаки при предпросмотре в браузере.
4. Локализация БД в РФ и журнал действий (Audit Log). База данных PostgreSQL и файловое хранилище размещаются в российском дата-центре по ч. 5 ст. 18 Закона № 152-ФЗ⁴, а ключевые операции (вход, выдача и отзыв согласия, оплата этапа, просмотр карточки администратором) фиксируются в журнале аудита.

Как принимать разработку кабинета или каталога: ТЗ и ПМИ вместо устных договорённостей

Главная причина затянутых сроков и конфликтов при заказной разработке — отсутствие чётких критериев того, что именно считается готовой работой. Когда в договоре написано «Разработка личного кабинета клиента — 1 шт.», заказчик подразумевает внутри мини-CRM с рассылками и экспортом в 1С, а подрядчик — форму входа и таблицу из трёх колонок.

В студии ДАКОД мы закрываем этот риск на берегу двумя документами, которые становятся неотъемлемыми приложениями к договору:

• Техническое задание (ТЗ) с закрытым перечнем экранов и ролей. До начала вёрстки фиксируем каждую роль пользователя, поля карточек, формулы расчёта калькуляторов, внешние интеграции (оплата, СДЭК, обмен с 1С) и требования к скорости и браузерам. Смета после подписания ТЗ фиксируется и не растёт по ходу работ.
• Программа и методика испытаний (ПМИ). Это пошаговый чек-лист приёмки на простом русском языке: «Шаг 1: войти под ролью Клиент, заполнить поле X, нажать кнопку Y → Ожидаемый результат: создаётся черновик заявки, в профи-кабинете менеджера появляется уведомление». По ПМИ мы сначала прогоняем собственные автотесты (например, в проекте Relic Chat перед каждым релизом автоматически выполняется около 3 700 проверок в Chromium и WebKit на разрешениях десктопа и iPhone), а затем вместе с заказчиком подписываем акт сдачи-приёмки.

После запуска на все наши проекты действует гарантия 1 год по договору: любые технические ошибки в нашем коде устраняем бесплатно, а все исходники, структура базы данных и root-доступы к серверу передаются заказчику по акту. О том, как выбрать базовую платформу под ваш масштаб, читайте в статье «На чём сделать сайт в 2026 году: Tilda, WordPress, NetCat, 1С-Битрикс или чистый код», а если вы готовы обсудить каталог или личный кабинет — посмотрите условия на страницах корпоративных сайтов и интернет-магазинов или оставьте заявку на бесплатную оценку.