Привет! Меня зовут Никита, я менеджер продуктов в Нмаркет.ПРО — цифровой платформе для риелторов.
Сегодня расскажу, как мы за полтора года создали Личный кабинет покупателя (ЛКП) и Корзину — инструменты, которых нет ни у одного агрегатора недвижимости.
Почему мы решили ломать привычное
Нмаркет.ПРО — это не просто база объектов. Это рабочий инструмент агента по недвижимости, где он может бронировать новостройки, работать со вторичкой (собственной базой и партнерскими объявлениями с «Авито» и «Циан»), подавать заявки на ипотеку, создавать подборки объектов для клиентов.
Для успешного проведения сделок этот инструмент должен быть удобным и универсальным. Поэтому важно заполнить пробелы в коммуникации агента и его клиента.
Какие проблемы мы выявили:
- Агент отправлял клиенту разрозненную информацию: ссылки, скриншоты, PDF‑презентации и т. п. Делал это в разных каналах: SMS, WhatsApp, e‑mail и т. д.
- Клиент не понимал статус работы в реальном времени и нервничал (так как не было понятно, забронирован ли объект, каково следующее действие и т. д.).
Разумеется, это негативно влияло на конверсию в сделку. Так мы пришли к тому, что нам нужен Личный кабинет покупателя (ЛКП) — связующее звено между агентом и клиентом, которое сделает коммуникацию удобной и прозрачной.
Объединить необъединимое
Когда начали проектировать ЛКП, быстро поняли: фронтенд и дизайн — не главная проблема. Самым сложным оказалось объединение разных типов объектов в единую модель данных. В системе одновременно живут разные типы объектов недвижимости:
- новостройки;
- вторичка;
- переуступки;
- объекты с внешних площадок («Авито», «Циан»);
- ипотечные продукты;
- коммерческая недвижимость;
- кладовки;
- паркинги.
У каждого источника:
- своя структура данных (поля, типы, вложенность);
- свои статусы (в продаже, забронировано, снято, в архиве);
- свои сценарии действий (бронь, запись на просмотр, фиксация).
При этом в ЛКП все это должно:
- отображаться единообразно;
- работать в рамках одной ссылки (объекты добавляются постепенно, ссылка не меняется);
- поддерживать лайки, просмотры и быстрые действия (агент может сразу забронировать лайкнутый объект или записаться на просмотр).
Дополнительно требовалась:
- работа с разными валютами и регионами;
- необходимость объединить несколько личных кабинетов (подбор объекта и подбор ипотеки) в один.
Фактически мы строили единый слой агрегации над разрозненными источниками данных. Это потребовало унификации API, создания общей модели объекта и мапперов для каждого типа.
«Клиент-клиент»
Вторая сложность, с которой пришлось столкнуться, — дублирование клиентов. Это не UI-проблема, а проблема уровня данных и процессов.
Клиенты дублировались, потому что:
- создавались в разных сценариях (в нашем расширении для браузера «Помощник», в избранном, в карточке объекта);
- пользователь не всегда вводил ФИО и телефон сразу (откладывал на потом);
- не было единого идентификатора клиента между модулями.
Решение было комплексным:
- процесс: перенесли создание клиента в финальный шаг (при отправке Корзины, о ней чуть ниже), сократили количество точек создания;
- бэкенд: унифицировали структуру клиента, подготовили базу к дедупликации, настроили работу с источниками данных;
- UX: минимизировали ручной ввод, упростили сценарии.
Это решалось не одним релизом, а серией итераций (которые, к слову, продолжаются до сих пор). Но об этом мы расскажем во второй серии! Не теряйтесь.