Как мы создавали личный кабинет брокера Ида.Лайт

Мы позвали человека из девелопмента создавать Кабинет брокера. А он предложил писать меньше кода

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

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

У нас все было прозаичнее. Мы решили создать кабинет брокера для девелоперов и пригласили руководить продуктом человека, который уже внедрял подобные системы. Причем не в качестве разработчика или консультанта, а на стороне заказчика – там, где приходится согласовывать бюджеты, защищать инвестиции в автоматизацию, разбираться в интеграциях и отвечать за результат, когда подрядчик торжественно сообщает, что все работает, а сотрудники почему-то продолжают вести Excel.

Этот опыт оказался важнее, чем мы предполагали. Человек, который несколько раз проходил через внедрение программного обеспечения в девелопменте, приобретает специфическое отношение к технологиям. Он перестает восхищаться наличием функций и начинает интересоваться тем, какую конкретно работу эти функции устраняют. А еще у него появляется профессиональная аллергия на фразу «так предусмотрено техническим заданием».

Сразу оговоримся: подробного разбора архитектуры и внутренней логики продукта не будет. Часть этих решений относится к нашему ноу-хау, часть защищена NDA. Гораздо интереснее другое: почему мы решили пересмотреть сам подход к разработке отраслевого программного обеспечения и как обнаружили, что наиболее полезная функция будущего продукта – способность избавить заказчика от функций, которые он сам попросил разработать.

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

Реальность, как обычно, несколько сложнее. Возьмем партнерские продажи. В отдельных проектах на брокеров приходится до 90% сделок. Это огромный канал реализации недвижимости, от эффективности которого напрямую зависят коммерческие результаты девелопера. При этом сама механика взаимодействия с агентствами нередко выглядит так, словно цифровая трансформация остановилась где-то на этапе появления ватсапа или электронной почты.

Брокер нашел клиента и хочет закрепить его за собой. Отправляет номер телефона. Менеджер проверяет CRM, выясняет историю обращений, уточняет сроки предыдущих фиксаций. Иногда подключается руководитель, иногда начинается переписка с агентством. Если все прошло успешно, брокеру сообщают результат, после чего история продолжается: встреча, продление фиксации, бронирование, изменение статусов, расчет комиссии.

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

Раньше брокер писал менеджеру в мессенджер, теперь нажимает кнопку «Проверить уникальность». Запрос красиво появляется в системе, менеджер получает уведомление и отправляется выполнять примерно ту же последовательность действий, что и раньше. Разница заключается в том, что теперь компания платит за программное обеспечение, в котором этот процесс происходит.

Это, конечно, тоже прогресс. Но довольно своеобразный.

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

Любой, кто хотя бы раз участвовал во внедрении крупного IT-решения, знает, как рождается техническое задание. Сначала появляется разумная бизнес-потребность. Например, сократить время обработки запросов от брокеров. Затем к обсуждению подключаются заинтересованные подразделения, каждое из которых добавляет свои требования.

Коммерческий директор хочет контролировать партнерские продажи. Руководитель отдела продаж – видеть все обращения. Юристы требуют определенный порядок подписания агентских договоров. Финансовая служба предлагает отдельный механизм согласования комиссий. IT-отдел формулирует требования к интеграциям. В какой-то момент первоначальная задача обрастает таким количеством условий, что становится трудно вспомнить, ради чего все начиналось.

Получается подробное техническое задание. Подрядчик его оценивает, стороны согласовывают сроки, начинается разработка. Через несколько месяцев заказчик получает систему, которая соответствует документу. Формально все хорошо. Только ожидаемого сокращения операционных затрат почему-то не происходит.

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

Если встреча состоялась и информация об этом уже находится в CRM, если правила продления фиксации заранее определены, а условия сотрудничества с агентством известны системе, то что именно должен согласовывать сотрудник?

Иногда выясняется, что ничего. Просто несколько лет назад компания установила такой регламент, а потом все привыкли считать его обязательным. Сегодня он продолжает существовать исключительно благодаря собственной инерции.

В такой ситуации можно добросовестно разработать механизм согласования. А можно предложить убрать согласование как класс, передав проверку условий системе.

Второй вариант предполагает, что разработчик должен не просто принимать требования, а разбираться в бизнесе клиента настолько глубоко, чтобы иногда с этими требованиями спорить.

Следующее открытие оказалось менее философским, зато гораздо более практическим. Мы начали изучать, как разные застройщики организуют работу с брокерами, и довольно быстро убедились: универсальность в девелопменте – понятие относительное.

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

У одного девелопера фиксация действует 30 дней, у другого – 45. Третий продлевает ее после встречи, четвертый допускает альтернативную фиксацию, если брокер действительно привел клиента в офис продаж. Где-то платное бронирование автоматически меняет условия закрепления клиента за агентством, а где-то для этого предусмотрен отдельный регламент.

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

Добавим к этому CRM. Даже две компании с одинаковой системой могут иметь совершенно разные воронки, статусы, правила обработки обращений и внутренние автоматизации. Для IT-компании все это выглядит как бесконечное множество исключений. Для девелопера – как обычная повседневная работа.

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

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

Мы решили найти третий путь.

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

Так появилась концепция Кабинета брокера Ида.Лайт: общая платформа, индивидуальная бизнес-логика и единый пользовательский опыт.

Для брокера система должна оставаться простой и понятной. Для девелопера – учитывать его регламенты, коммерческие условия и особенности CRM. Для нас – сохранять возможность централизованно развивать продукт, не превращая каждое внедрение в самостоятельную IT-историю.

Есть еще одна проблема с самим понятием «кабинет брокера». Оно довольно точно описывает интерфейс, но плохо передает смысл того, что происходит за ним.

Кабинет ассоциируется с местом, куда пользователь заходит, чтобы посмотреть квартиры, проверить цены, зафиксировать клиента, забронировать объект или уточнить комиссию. Все это необходимо, но само по себе не является конечной целью девелопера.

Девелоперу нужны продажи.

А продажи – это последовательность связанных событий. После фиксации клиент приезжает на встречу, выбирает квартиру, бронирует объект и заключает договор. Каждое событие влияет на сроки фиксации, статусы сделки, условия сотрудничества с агентством и будущую комиссию.

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

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

Для нас главным критерием успешной интеграции стало не количество передаваемых данных и не число подключенных систем.

В какой-то момент мы задали себе еще один вопрос, который для разработчика кабинета брокера звучит почти кощунственно: а действительно ли брокер хочет пользоваться еще одним кабинетом?

Представим агентство, которое одновременно работает с несколькими десятками девелоперов. У каждого собственная система, правила и интерфейс. При этом у брокеров уже есть привычная рабочая среда – агрегаторы недвижимости.

Зачем заставлять их покидать эту среду ради выполнения операции, которую можно организовать внутри нее?

Так появилось направление нативных интеграций с TrendAgent, NMarket и Авито. Брокер отправляет запрос на проверку уникальности непосредственно из агрегатора, а наша платформа взаимодействует с CRM девелопера, применяет его правила и выполняет необходимые действия.

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

Но противоречия здесь нет. Наша цель – не количество посещений кабинета, а эффективность партнерских продаж.

Индивидуальная настройка традиционно ассоциируется с индивидуальной стоимостью. Чем сложнее процессы заказчика, тем выше бюджет проекта. Но мы не хотели создавать продукт исключительно для крупнейших девелоперов с собственными IT-подразделениями.

Поэтому выбрали подписочную модель.

Кабинет брокера Ида.Лайт для ранних последователей стоит всего 40 000 рублей в месяц. Настройка бизнес-правил и интеграция с CRM входят в процесс внедрения без отдельной платы, а списание средств начинается после запуска.

Для девелопера это принципиально другая экономика. Вместо финансирования собственной разработки он получает готовую технологическую инфраструктуру с понятными регулярными затратами. Ему не нужно самостоятельно организовывать поддержку, заниматься обновлениями или оплачивать развитие базовой функциональности.

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

Каждое внедрение знакомит нас с новыми бизнес-сценариями. Мы изучаем, какие процессы повторяются у разных девелоперов, какие требуют индивидуальной настройки, а какие стоит превратить в универсальные возможности продукта.

То, что сегодня кажется уникальной задачей конкретного заказчика, завтра может стать стандартным сценарием, доступным другим девелоперам. Так отраслевая экспертиза постепенно накапливается внутри платформы, а результатами ее развития пользуются все клиенты.

В марте 2026 года мы приступили к созданию продукта, а уже летом получили первые результаты коммерческого внедрения. Одним из первых клиентов стала компания G3, для которой кабинет был интегрирован и запущен в работу.

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

На презентации все работает идеально. Брокер нажимает кнопку, система проверяет условия, CRM возвращает ответ, пользователь получает результат. Красивый сценарий, в котором все участники ведут себя предсказуемо.

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

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

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

Мы решили воспринимать такие ситуации не как отклонения от технического задания, а как источник новых знаний.

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

Есть интересная закономерность: чем глубже IT-компания понимает бизнес заказчика, тем меньше ей хочется рассказывать о собственных функциях.

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

Коммерческому директору не нужна автоматическая проверка уникальности сама по себе. Ему необходимо, чтобы партнерский канал работал эффективно, брокеры быстрее доводили клиентов до сделки, а сотрудники не тратили время на повторяющиеся операции.

Руководителю партнерского направления не нужен аналитический модуль как таковой. Ему важно понимать, какие агентства действительно продают и где компания теряет потенциальные сделки.

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

Когда начинаешь смотреть на продукт таким образом, меняется и сама логика разработки. Вместо вопроса «Как добавить еще одну функцию?» появляется вопрос «Какую бизнес-проблему мы можем устранить?».

Создание программного обеспечения постепенно становится проще и доступнее. Искусственный интеллект ускоряет написание кода, инструменты разработки совершенствуются, а создание интерфейсов занимает все меньше времени.

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

Тогда что останется?

Мы считаем, что все большую роль будет играть отраслевая экспертиза.

Написать код для проверки уникальности клиента – техническая задача. Понять, как именно должна работать проверка в конкретной девелоперской компании, – задача совершенно другого порядка. Для этого необходимо разбираться в коммерческих регламентах, юридических моделях сотрудничества, логике CRM, экономике партнерских продаж и поведении брокеров.

Именно поэтому мы изначально сделали ставку на продуктовую экспертизу со стороны девелопмента.

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

Сегодня кабинет брокера стал частью экосистемы Ида.Лайт – цифровых решений, которые сопровождают девелопера на разных этапах жизненного цикла недвижимости.

И если попытаться сформулировать главный вывод всей этой истории, он будет довольно простым.

Ида.Лайт – превращаем опыт девелопмента в технологии для девелопмента.