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