Маркетплейс с 3 ролями пользователей: разбор архитектуры на примере Vsedomatut

В апреле 2026 запустили маркетплейс недвижимости Vsedomatut за 3 недели. Внутри — три типа кабинетов и интеграция с 1С-Битрикс, которая помогла сохранить рабочие процессы клиента. Ниже — разбор архитектуры без лишней теории.

Что такое маркетплейс с 3 ролями

Маркетплейс с 3 ролями — это веб-продукт, где у каждого типа пользователя свой кабинет, свои действия и свой уровень доступа. В такой архитектуре важна не только витрина, но и правила: кто создаёт контент, кто его проверяет, кто видит заявки и кто отвечает за публикацию.

В случае Vsedomatut роли распределились так:

• Покупатель — ищет квартиру, оставляет заявку, сохраняет интересные объекты.
• Агент / собственник — публикует объявления напрямую и отвечает на заявки.
• Партнёр — внешняя компания, которая подаёт объявления через отдельный кабинет с обязательной модерацией.

Третья роль оказалась самой нестандартной. Без неё проект был бы обычным каталогом, а не маркетплейсом с контролем качества входящего контента.

Зачем понадобился партнёрский кабинет

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

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

Архитектура — как это устроено технически

Три кабинета — это не три отдельных сайта. Это одна система авторизации, разные dashboard-роуты и разные права на API. Во Vsedomatut авторизация сделана через custom JWT: решение без сторонних сервисов, подходящее под российскую инфраструктуру клиента.

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

• Frontend: Next.js + TypeScript + Tailwind.
• Backend: Node.js + PostgreSQL.
• Auth: custom JWT без внешней авторизационной платформы.
• Интеграция: 1С-Битрикс API для синхронизации каталога.
• Админка: 50+ функций: модерация, аналитика, пользователи, роли, уведомления.

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

Как разделили права между ролями

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

Для Vsedomatut мы разделили действия на несколько групп: просмотр каталога, создание объекта, отправка на модерацию, публикация, изменение статуса, работа с заявкой и административные действия. У покупателя права минимальные: поиск, избранное, заявка. У партнёра больше возможностей, но только внутри своего контента. У менеджера и администратора — права на модерацию, статусы и управление каталогом.

Такой подход полезен для бизнеса: если завтра появится новая роль, её можно добавить не переписывая весь продукт. Например, можно выделить роль «модератор» отдельно от менеджера или добавить «застройщика» с доступом только к своим объектам. Это уже не хаотичный набор условий в коде, а управляемая модель доступа.

Как работает модерация объявлений

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

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

Важно, что комментарий модератора возвращается в кабинет партнёра, а не теряется в чате. Это снижает количество ручных сообщений и создаёт понятную историю по каждому объекту. Для следующего этапа такую логику можно расширить: добавить шаблоны причин отклонения, SLA по проверке, уведомления и аналитику по качеству входящего контента.

Что дала интеграция с 1С-Битрикс

У Марата уже была учётная система на 1С-Битрикс с базой объектов. Делать вторую базу означало бы разломать привычный процесс работы менеджеров. Поэтому маркетплейс читает данные через API Битрикса и отдаёт обратно статусы заявок.

Конкретно это решило три задачи:

• Не пришлось мигрировать данные в отдельную систему на старте.
• Менеджеры продолжили работать в привычном интерфейсе Битрикса.
• Каталог на сайте обновляется автоматически, а не вручную через таблицы.

Подробный разбор headless-подхода есть в статье «Когда уходить с 1С-Битрикс на Next.js».

Сроки и цена

Vsedomatut запустили за 3 недели от подписания до публичного запуска. Цена была фиксированной: без почасовых смет, которые растут после каждого уточнения. В первый этап вошли три кабинета, админка с модерацией, интеграция с Bitrix API, базовое SEO и адаптивная верстка.

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

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

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

Второй вопрос — источник правды. В Vsedomatut таким источником осталась система клиента на Битриксе. Это позволило не ломать привычные процессы. В другом проекте источником может быть CRM, 1С, PostgreSQL или внешняя партнёрская API. Главное — не создавать две равноправные базы, которые начинают расходиться через неделю после запуска.

Третий вопрос — рост. Первая версия не обязана содержать всё, но она должна быть расширяемой. Если вы понимаете, что через 2–3 месяца появятся новые партнёры, новые статусы и отдельные отчёты, это нужно заложить в структуру ролей и API заранее. Так первый запуск остаётся быстрым, а второй этап не превращается в переделку с нуля.

Почему это не просто «личный кабинет»

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

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

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

Какие метрики нужно смотреть владельцу

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

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

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

Почему админка важнее, чем кажется

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

Во Vsedomatut в админку вошло 50+ функций: управление объявлениями, пользователями, ролями, модерацией, заявками, уведомлениями и аналитикой. Это не «внутренняя мелочь», а рабочее место команды. Именно там решается, как быстро объект пройдёт путь от партнёрской заявки до публикации в каталоге.

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

Когда такая архитектура подходит вашему бизнесу

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

• [ ] У вас есть пул внешних поставщиков контента: партнёры, агенты, мерчанты.
• [ ] Контент нужно модерировать перед публикацией.
• [ ] Покупатели должны взаимодействовать с поставщиками напрямую.
• [ ] Уже есть 1С, CRM или другая учётная система, которую не хочется ломать.
• [ ] Нужна аналитика по каждой роли отдельно.

Если совпало хотя бы три пункта, архитектура с ролями обычно окупается: меньше ручной работы, меньше ошибок и понятнее ответственность внутри продукта.

FAQ

Сколько стоит маркетплейс с 3 ролями пользователей?

Зависит от количества интеграций и сложности логики. Базовая версия с тремя кабинетами и админкой — от 250 000 ₽, фиксированная цена, 3–4 недели работы. Полная стоимость считается после короткого брифа.

Можно ли начать с двух ролей и добавить третью позже?

Да. Архитектура изначально закладывается с учётом расширения ролей. Добавление новой роли позже — отдельная задача, обычно 5–10 дней.

Обязательна ли интеграция с 1С-Битрикс?

Нет. Битрикс был у Марата, поэтому интегрировались с ним. Если у вас CRM, МойСклад или ничего — архитектура остаётся той же, меняется источник данных.

Кто модерирует объявления партнёров?

Любой пользователь с правом модератора в админке. У Марата это команда из 2 человек: они видят входящие объявления и проверяют заявки в течение дня.

Можно ли запустить маркетплейс без своих программистов?

Да. После запуска передаём полный доступ к коду и инфраструктуре. Дальше вы можете работать с любым подрядчиком или развивать продукт своей командой.

Хотите такой же маркетплейс?

Если хотите сравнить с более простым форматом, посмотрите статью «Сколько стоит лендинг и за что вы платите». А если изучаете стек, полезна статья «Когда уходить с 1С-Битрикс на Next.js». Остальные материалы — в разделе «другие статьи блога».