«Квартал» — SaaS-платформа для агентств и инвесторов в недвижимость
Мы разработали B2B SaaS-платформу, которая собирает базу объектов, базу покупателей и email-маркетинг в одном рабочем месте. Команда ведёт сделки, запускает рассылки по сегментам покупателей и в реальном времени видит, какие письма приносят отклик. Систему проектировали под ежедневную работу менеджера по сделкам, а не под разовые отчёты: выбор периода и ответственного пересобирает дашборд целиком, поэтому переключаться между отчётами не нужно. Проект выполнила команда полного цикла за 4 месяца.
- срок проекта
- 4 месяца
- функциональных модулей
- 10
- этапов разработки
- 5
- ключевых технологий
- 5
02 — Контекст
Задача проекта
Исходная ситуация, ограничения и проблемы, которые должна была решить новая система.
Рынок недвижимости живёт на скорости отклика: объект уходит не к тому, у кого лучше предложение, а к тому, кто первым донёс его до нужного покупателя. Выигрывает команда, которая за минуты понимает, кому из базы этот объект интересен, и отправляет предложение раньше конкурентов.
При этом данные у агентств традиционно раздроблены. Объекты живут в одной системе, база покупателей — в таблицах, рассылки — в стороннем почтовом сервисе. Связь «какое письмо привело к сделке» не прослеживается вовсе: почтовый сервис знает про открытия и клики, но ничего не знает про объекты и сделки, а CRM — наоборот.
Отсюда вырастает управленческая слепота. Руководитель видит, сколько писем ушло, но не видит, чья работа с базой конвертирует. Менеджер каждый день вручную сшивает три источника, а любая аналитика превращается в ручную выгрузку и сведение таблиц. Задача, которую мы решали, звучала так: собрать объекты, покупателей и коммуникации в один контур и посчитать эффективность рассылок в разрезе конкретного менеджера и периода.
Три системы вместо одного рабочего места
Объекты, база покупателей и рассылки жили в разных сервисах. Чтобы отправить предложение по новому объекту, менеджер собирал список покупателей в одном окне, копировал контакты во второе и вручную сверял, кому уже писали.
Непрозрачная эффективность рассылок
Отчёты почтового сервиса отвечали на вопрос «сколько писем ушло», но не на вопрос «чья работа с базой приносит отклик». Сравнить менеджеров между собой или посмотреть динамику за период было невозможно без ручной выгрузки.
Заявки теряются между каналами
Обращения от собственников и запросы покупателей приходили с сайтов, из почты и мессенджеров и не попадали в общий контур. Часть обращений оседала в личных переписках менеджеров и не доходила до системы вообще.
Нет единой картины по сделке
История по объекту — заявки, отправленные предложения, реакции покупателей — была разбросана по нескольким инструментам. При передаче объекта другому менеджеру контекст восстанавливался по памяти и старой переписке.
03 — Возможности
Что делает система
Ключевые сценарии и рабочие модули, собранные в единую систему.
Дашборд
Стартовый экран со сводкой по трём срезам: активность команды, метрики покупателей и метрики email. Ключевое решение — выбор периода и ответственного менеджера пересобирает дашборд целиком: и карточки-показатели, и таблицу кампаний. Пользователь не переключается между отчётами, а «крутит» один срез данных.
Метрики email и кампании
Карточки-показатели по отправленным и доставленным письмам с динамикой к предыдущему периоду, сводный скоринг качества рассылок и таблица кампаний со статусами «запланировано» и «отправлено». Для каждой кампании — четыре процентные метрики отклика и построчные действия «повторить» и «удалить».
Покупатели
База покупателей и инвесторов с сегментацией: по бюджету, географии, типу объектов и истории взаимодействия. Сегмент — это не статичный список, а условие, по которому собирается аудитория рассылки, поэтому один и тот же объект уходит именно тем, кому он потенциально интересен.
Объекты и заявки
Каталог объектов в работе и входящие обращения по каждому из них. Заявка привязана к объекту, поэтому история — кто спрашивал, что отвечали, какое предложение отправили — собирается в одном месте и переживает передачу объекта другому менеджеру.
Предложения
Офферы, отправленные покупателям, и их статусы. Раздел закрывает разрыв между рассылкой и сделкой: видно не только то, что письмо доставлено, но и то, во что оно превратилось — в запрос, показ или отказ.
JV-аутрич
Работа с партнёрами по совместным сделкам (joint venture): отдельный контур переписки и договорённостей, который не смешивается с базой покупателей. Партнёрские сделки идут по своей логике, поэтому им выделен собственный раздел, а не общий список контактов.
Аналитика
Отчётность по воронке, объектам и каналам. Отвечает на управленческие вопросы: где сделки застревают, какие типы объектов дают отклик и какие каналы приводят покупателей — на данных самой платформы, без ручных выгрузок и сведения таблиц.
Роли и «Режим бога»
Менеджер по сделкам ведёт объекты и рассылки, руководитель отдела сравнивает эффективность через фильтр по ответственному, а собственник получает «Режим бога» — сквозной доступ ко всем данным и настройкам без ограничений ролей. Каждой роли — свой объём данных и свой набор действий.
Внешние витрины
Платформа генерирует и питает данными два публичных сайта, доступных прямо из шапки: «Сайт продавца» — страница захвата обращений от собственников, и «Сайт сделок» — публичный каталог для покупателей. Обращения с обеих витрин попадают сразу в общий контур, а не в почту менеджера.
Уведомления
Лента событий со счётчиком непрочитанного: новые заявки по объектам, реакции на предложения, завершённые кампании. Уведомления связаны с сущностями системы, поэтому из ленты можно сразу перейти к объекту или покупателю, а не искать их вручную.
04 — Архитектура
Технологический стек
Технологии выбраны под нагрузку, интеграции и дальнейшее развитие продукта.
Зачем в проекте · 01 / 05
React + TypeScript
Интерфейс платформы — это плотные таблицы, фильтры и массовые операции с постоянным пересчётом состояния. Строгая типизация здесь окупается: при изменении структуры данных ошибки всплывают на сборке, а не в проде у менеджера в разгар рассылки.
- Analytics
05 — Процесс
Как шла разработка
Последовательность работ от исследования задачи до запуска и проверки результата.
Разбор рабочего дня менеджера
Начали не с модулей, а со сценария: что менеджер по сделкам делает утром, что после появления нового объекта, что перед отчётом руководителю. Из этого разбора выросло ключевое требование — один экран, который пересобирается фильтрами, вместо набора отдельных отчётов.
Модель данных и роли
Спроектировали связи между объектами, заявками, покупателями, предложениями и кампаниями так, чтобы метрику рассылки можно было связать с конкретным менеджером и объектом. Параллельно описали роли: менеджер, руководитель отдела и «Режим бога» для собственника.
Дизайн-система интерфейса
Собрали визуальный язык под работу с большим объёмом цифр: три независимые скруглённые панели на светлой подложке, двухуровневая иерархия поверхностей и один акцентный цвет. Глубина строится оттенками, а не тенями и рамками — так плотные таблицы читаются без визуального шума.
Email-контур и метрики
Подключили провайдера рассылок, настроили приём вебхуков и связали события доставки с кампаниями, покупателями и ответственными. После этого метрики перестали быть отдельным отчётом почтового сервиса и стали частью общей картины по сделке.
Внешние витрины и запуск
Подняли сайт продавца и сайт сделок, замкнули обращения с них на общий контур заявок и вывели команду на платформу. Дальше — сопровождение: наблюдали за реальными сценариями и дорабатывали фильтры и массовые операции по обратной связи менеджеров.
06 — Итог
Результаты
Что создано в рамках проекта: рабочий контур, реализованные возможности и подтверждённые факты.
- от постановки задачи до запуска платформы
- 4 месяца
- объекты, покупатели и email-маркетинг в одном контуре
- 3 системы в 1
- рабочих модулей платформы плюс две внешние витрины
- 9 разделов
- менеджер, руководитель отдела и «Режим бога» собственника
- 3 роли
Агентство получило одно рабочее место вместо трёх систем. Объекты, заявки, покупатели, предложения и рассылки живут в общем контуре, поэтому менеджеру больше не нужно вручную сшивать данные, чтобы отправить предложение по новому объекту нужному сегменту покупателей.
Главное изменение — управленческое. Метрики рассылок считаются в разрезе ответственного и периода, поэтому руководитель отвечает не на вопрос «сколько писем ушло», а на вопрос «чья работа с базой конвертирует». Сравнение менеджеров и динамика за период стали встроенной функцией, а не ручной выгрузкой в таблицу.
Обращения с двух внешних витрин попадают сразу в общий контур заявок, а не оседают в личной почте менеджера. За счёт этого история по объекту остаётся целой при передаче между сотрудниками, а новый менеджер входит в контекст сделки по данным системы, а не по чужой переписке.
Детали проекта
Почему кейс без имени клиента
Название агентства и его коммерческие показатели закрыты соглашением о неразглашении, поэтому в кейсе нет ни имени клиента, ни его цифр по сделкам и выручке. Всё, что описано выше, — это наша работа: архитектура платформы, состав модулей, интерфейсные решения и сроки разработки.
Числа на скриншотах интерфейса — демонстрационные и не отражают реальные объёмы клиента. Рыночный контекст в разделе «Задача» описывает типовую ситуацию отрасли, с которой к нам приходят агентства недвижимости, а не внутреннюю кухню конкретной компании.
FAQ
Вопросы о проекте
Далее
Похожие проекты
Обсудим похожий проект?
Расскажите о задачах вашего бизнеса — предложим архитектуру и оценим сроки
