Привет! Продолжу рассказ о том, как мы работаем над цифровой платформе для риелторов. Сегодня расскажу, как мы за полтора года создали Личный кабинет покупателя (ЛКП) и Корзину — инструменты, которых нет ни у одного агрегатора недвижимости.

Почему мы решили ломать привычное

Нмаркет.ПРО — это не просто база объектов. Это рабочий инструмент агента по недвижимости, где он может бронировать новостройки, работать со вторичкой (собственной базой и партнерскими объявлениями с «Авито» и «Циан»), подавать заявки на ипотеку, создавать подборки объектов для клиентов.

Для успешного проведения сделок этот инструмент должен быть удобным и универсальным. Поэтому важно заполнить пробелы в коммуникации агента и его клиента. 

Какие проблемы мы выявили:

• Агент отправлял клиенту разрозненную информацию: ссылки, скриншоты, PDF‑презентации и тому подобное. Делал это в разных каналах: SMS, WhatsApp, e‑mail и так далее

• Клиент не понимал статус работы в реальном времени и нервничал (так как не было понятно, забронирован ли объект, каково следующее действие и так далее).

Разумеется, это негативно влияло на конверсию в сделку. Так мы пришли к тому, что нам нужен Личный кабинет покупателя (ЛКП) — связующее звено между агентом и клиентом, которое сделает коммуникацию удобной и прозрачной.

Объединить необъединимое

Когда начали проектировать ЛКП, быстро поняли: фронтенд и дизайн — не главная проблема. Самым сложным оказалось объединение разных типов объектов в единую модель данных.В системе одновременно живут разные типы объектов недвижимости:

• новостройки;

• вторичка;

• переуступки;

• объекты с внешних площадок («Авито», «Циан»);

• ипотечные продукты;

• коммерческая недвижимость;

• кладовки;

• паркинги.

У каждого источника:

• своя структура данных (поля, типы, вложенность);

• свои статусы (в продаже, забронировано, снято, в архиве);

• свои сценарии действий (бронь, запись на просмотр, фиксация).

При этом в ЛКП все это должно:

• отображаться единообразно;

• работать в рамках одной ссылки (объекты добавляются постепенно, ссылка не меняется);

• поддерживать лайки, просмотры и быстрые действия (агент может сразу забронировать лайкнутый объект или записаться на просмотр).

Дополнительно требовалась:

• работа с разными валютами и регионами;

• необходимость объединить несколько личных кабинетов (подбор объекта и подбор ипотеки) в один.

Фактически мы строили единый слой агрегации над разрозненными источниками данных. Это потребовало унификации API, создания общей модели объекта и мапперов для каждого типа.

«Клиент‑клиент»

Вторая сложность, с которой пришлось столкнуться, — дублирование клиентов. Это не UI‑проблема, а проблема уровня данных и процессов. 

Клиенты дублировались, потому что:

• создавались в разных сценариях (в нашем расширении для браузера «Помощник», в избранном, в карточке объекта);

• пользователь не всегда вводил ФИО и телефон сразу (откладывал на потом);

• не было единого идентификатора клиента между модулями.

Решение было комплексным:

• процесс: перенесли создание клиента в финальный шаг (при отправке Корзины, о ней чуть ниже), сократили количество точек создания;

• бэкенд: унифицировали структуру клиента, подготовили базу к дедупликации, настроили работу с источниками данных;

• UX: минимизировали ручной ввод, упростили сценарии.

Это решалось не одним релизом, а серией итераций (которые, к слову, продолжаются до сих пор). Но об этом мы расскажем во второй серии! Не теряйтесь.