Онлайн-бронирование на сайте застройщика

Profitbase — экосистема proptech-сервисов для девелоперов жилья: набор взаимосвязанных SaaS-модулей, покрывающих весь цикл продажи квартиры. Модуль «Смарт-каталог» — виджет для сайта застройщика с 3D-планировками, фильтрами и акциями.

Это основной источник трафика: около 60% заявок приходят со смарт-каталога, а конверсия в сделку здесь в три раза выше среднего. В конце 2023 — начале 2024 команда искала точки роста в воронке.

Разрыв был хорошо виден: пользователь выбирал квартиру, оставлял заявку — и дальше всё переходило к менеджеру, телефону и ручному бронированию. Часть клиентов в этой цепочке терялась: менеджер мог не успеть, а пользователь — остыть или уйти к конкуренту.

Онлайн-бронирование уже появлялось у крупных игроков рынка и постепенно становилось новой нормой. Но главная проблема была не в отсутствии фичи, а в провале между интересом пользователя и его действием.

Я отвечала за полный MVP-сценарий: покупательский flow, сценарий бронирования через менеджера и базовые настройки админки. На моей стороне были UX-логика, ключевые состояния, приоритизация, аргументация перед стейкхолдерами и контроль качества реализации.

Работала вместе с PM, аналитиком и разработкой. Отдельным требованием бизнеса был чистый, аккуратный интерфейс — он не должен усиливать тревожность в момент оплаты и ввода юридически значимых данных.

Нужно было спроектировать с нуля сценарий, который одновременно решает несколько задач: помогает пользователю зафиксировать решение без лишнего ожидания, проходит через юридические ограничения, не перегружает человека в чувствительном сценарии и при этом может быть быстро запущен как MVP у клиентов.

Гипотеза звучала так: если дать пользователю понятный и безопасный способ забронировать квартиру онлайн, можно сократить потери между выбором лота и следующей стадией сделки.

Эта гипотеза опиралась на CJM, JTBD, бенчмаркинг и desk research: было видно, что пользователь готов совершать значимые шаги онлайн, если продукт даёт ощущение контроля, прозрачности и надёжности.

Я собрала минимально достаточный MVP: только те шаги, без которых бронирование не работает ни для пользователя, ни для бизнеса, ни юридически. Всё вторичное — убрано или отложено в следующие итерации.

В первой версии сфокусировалась на трёх задачах: дать пользователю возможность зафиксировать решение без лишнего ожидания, пройти через юридические ограничения без критического роста трения и запустить рабочий MVP у клиентов как можно быстрее.

Часть настроек админки мы сознательно перенесли в следующие итерации: запуск был ценнее идеальной полноты, если команда понимала, что критично для первой версии.

Перед релизом сценарий прошёл юзабилити-тестирование с реальными пользователями на десктопе и адаптиве. По итогам доработали неоднозначные места в логике — прежде всего переходы между шагами и формулировки на юридически значимых экранах.

Визуально проработали три направления и выбрали наиболее чистый и минималистичный вариант: он лучше всего поддерживал сценарий оплаты и снижал ощущение тяжести на критичных шагах.