Мы разработали B2B SaaS-платформу, которая собирает базу объектов, базу покупателей и email-маркетинг в одном рабочем месте. Команда ведёт сделки, запускает рассылки по сегментам покупателей и в реальном времени видит, какие письма приносят отклик. Систему проектировали под ежедневную работу менеджера по сделкам, а не под разовые отчёты: выбор периода и ответственного пересобирает дашборд целиком, поэтому переключаться между отчётами не нужно. Проект выполнила команда полного цикла за 4 месяца.
02 — Контекст
Исходная ситуация, ограничения и проблемы, которые должна была решить новая система.
Рынок недвижимости живёт на скорости отклика: объект уходит не к тому, у кого лучше предложение, а к тому, кто первым донёс его до нужного покупателя. Выигрывает команда, которая за минуты понимает, кому из базы этот объект интересен, и отправляет предложение раньше конкурентов.
При этом данные у агентств традиционно раздроблены. Объекты живут в одной системе, база покупателей — в таблицах, рассылки — в стороннем почтовом сервисе. Связь «какое письмо привело к сделке» не прослеживается вовсе: почтовый сервис знает про открытия и клики, но ничего не знает про объекты и сделки, а CRM — наоборот.
Отсюда вырастает управленческая слепота. Руководитель видит, сколько писем ушло, но не видит, чья работа с базой конвертирует. Менеджер каждый день вручную сшивает три источника, а любая аналитика превращается в ручную выгрузку и сведение таблиц. Задача, которую мы решали, звучала так: собрать объекты, покупателей и коммуникации в один контур и посчитать эффективность рассылок в разрезе конкретного менеджера и периода.
Объекты, база покупателей и рассылки жили в разных сервисах. Чтобы отправить предложение по новому объекту, менеджер собирал список покупателей в одном окне, копировал контакты во второе и вручную сверял, кому уже писали.
Отчёты почтового сервиса отвечали на вопрос «сколько писем ушло», но не на вопрос «чья работа с базой приносит отклик». Сравнить менеджеров между собой или посмотреть динамику за период было невозможно без ручной выгрузки.
Обращения от собственников и запросы покупателей приходили с сайтов, из почты и мессенджеров и не попадали в общий контур. Часть обращений оседала в личных переписках менеджеров и не доходила до системы вообще.
История по объекту — заявки, отправленные предложения, реакции покупателей — была разбросана по нескольким инструментам. При передаче объекта другому менеджеру контекст восстанавливался по памяти и старой переписке.
03 — Возможности
Ключевые сценарии и рабочие модули, собранные в единую систему.
Стартовый экран со сводкой по трём срезам: активность команды, метрики покупателей и метрики email. Ключевое решение — выбор периода и ответственного менеджера пересобирает дашборд целиком: и карточки-показатели, и таблицу кампаний. Пользователь не переключается между отчётами, а «крутит» один срез данных.
Карточки-показатели по отправленным и доставленным письмам с динамикой к предыдущему периоду, сводный скоринг качества рассылок и таблица кампаний со статусами «запланировано» и «отправлено». Для каждой кампании — четыре процентные метрики отклика и построчные действия «повторить» и «удалить».
База покупателей и инвесторов с сегментацией: по бюджету, географии, типу объектов и истории взаимодействия. Сегмент — это не статичный список, а условие, по которому собирается аудитория рассылки, поэтому один и тот же объект уходит именно тем, кому он потенциально интересен.
Каталог объектов в работе и входящие обращения по каждому из них. Заявка привязана к объекту, поэтому история — кто спрашивал, что отвечали, какое предложение отправили — собирается в одном месте и переживает передачу объекта другому менеджеру.
Офферы, отправленные покупателям, и их статусы. Раздел закрывает разрыв между рассылкой и сделкой: видно не только то, что письмо доставлено, но и то, во что оно превратилось — в запрос, показ или отказ.
Работа с партнёрами по совместным сделкам (joint venture): отдельный контур переписки и договорённостей, который не смешивается с базой покупателей. Партнёрские сделки идут по своей логике, поэтому им выделен собственный раздел, а не общий список контактов.
Отчётность по воронке, объектам и каналам. Отвечает на управленческие вопросы: где сделки застревают, какие типы объектов дают отклик и какие каналы приводят покупателей — на данных самой платформы, без ручных выгрузок и сведения таблиц.
Менеджер по сделкам ведёт объекты и рассылки, руководитель отдела сравнивает эффективность через фильтр по ответственному, а собственник получает «Режим бога» — сквозной доступ ко всем данным и настройкам без ограничений ролей. Каждой роли — свой объём данных и свой набор действий.
Платформа генерирует и питает данными два публичных сайта, доступных прямо из шапки: «Сайт продавца» — страница захвата обращений от собственников, и «Сайт сделок» — публичный каталог для покупателей. Обращения с обеих витрин попадают сразу в общий контур, а не в почту менеджера.
Лента событий со счётчиком непрочитанного: новые заявки по объектам, реакции на предложения, завершённые кампании. Уведомления связаны с сущностями системы, поэтому из ленты можно сразу перейти к объекту или покупателю, а не искать их вручную.
04 — Архитектура
Технологии выбраны под нагрузку, интеграции и дальнейшее развитие продукта.
Интерфейс платформы — это плотные таблицы, фильтры и массовые операции с постоянным пересчётом состояния. Строгая типизация здесь окупается: при изменении структуры данных ошибки всплывают на сборке, а не в проде у менеджера в разгар рассылки.
Один язык на фронтенде и бэкенде ускоряет разработку и упрощает переиспользование моделей данных. Асинхронная модель хорошо ложится на основную нагрузку системы — постановку писем в очередь и обработку событий доставки.
Сегментация покупателей и метрики в разрезе менеджера и периода — это агрегирующие запросы по связанным сущностям. Реляционная модель с индексами даёт предсказуемое время ответа и на выборках, и на отчётах, а транзакции защищают целостность сделок.
Отправка идёт через провайдера с вебхуками доставки, открытий и кликов. Собственный SMTP на таком объёме означал бы борьбу за репутацию домена и попадание в спам вместо работы над продуктом.
Метрики считаются на стороне системы и кэшируются по срезам «период × ответственный». Это позволяет пересобирать дашборд целиком при смене фильтра, не заставляя пользователя ждать пересчёта на каждый клик.
05 — Процесс
Последовательность работ от исследования задачи до запуска и проверки результата.
Начали не с модулей, а со сценария: что менеджер по сделкам делает утром, что после появления нового объекта, что перед отчётом руководителю. Из этого разбора выросло ключевое требование — один экран, который пересобирается фильтрами, вместо набора отдельных отчётов.
06 — Итог
Что создано в рамках проекта: рабочий контур, реализованные возможности и подтверждённые факты.
Агентство получило одно рабочее место вместо трёх систем. Объекты, заявки, покупатели, предложения и рассылки живут в общем контуре, поэтому менеджеру больше не нужно вручную сшивать данные, чтобы отправить предложение по новому объекту нужному сегменту покупателей.
Главное изменение — управленческое. Метрики рассылок считаются в разрезе ответственного и периода, поэтому руководитель отвечает не на вопрос «сколько писем ушло», а на вопрос «чья работа с базой конвертирует». Сравнение менеджеров и динамика за период стали встроенной функцией, а не ручной выгрузкой в таблицу.
Обращения с двух внешних витрин попадают сразу в общий контур заявок, а не оседают в личной почте менеджера. За счёт этого история по объекту остаётся целой при передаче между сотрудниками, а новый менеджер входит в контекст сделки по данным системы, а не по чужой переписке.
4 месяца
от постановки задачи до запуска платформы
3 системы в 1
объекты, покупатели и email-маркетинг в одном контуре
9 разделов
рабочих модулей платформы плюс две внешние витрины
3 роли
менеджер, руководитель отдела и «Режим бога» собственника
Детали проекта
Название агентства и его коммерческие показатели закрыты соглашением о неразглашении, поэтому в кейсе нет ни имени клиента, ни его цифр по сделкам и выручке. Всё, что описано выше, — это наша работа: архитектура платформы, состав модулей, интерфейсные решения и сроки разработки.
Числа на скриншотах интерфейса — демонстрационные и не отражают реальные объёмы клиента. Рыночный контекст в разделе «Задача» описывает типовую ситуацию отрасли, с которой к нам приходят агентства недвижимости, а не внутреннюю кухню конкретной компании.
FAQ
Далее
Расскажите о задачах вашего бизнеса — предложим архитектуру и оценим сроки
Телеграмм
Делимся визуально привлекательными фрагментами наших последних веб-проектов.
ВКонтакте
Пишем о интересных технических решениях и вызовах в разработке.
MAX
Демонстрируем дизайнерские элементы наших веб-проектов.
TenChat
Деловые связи, кейсы и экспертные публикации.
Рассылка
© 2025-2026 МАЙПЛ. Все права защищены.
