УКН — цифровая платформа для управляющей компании сети индустриальных парков.
Задача была заметно шире разработки корпоративного сайта:
- нужно было связать в одной системе управление коммерческой недвижимостью;
- работу с собственниками и арендаторами;
- заявки на обслуживание;
- платежи;
- документы;
- пропуска;
- дополнительные услуги;
- внутренние процессы самой УК.
Поэтому продукт состоит из нескольких контуров.
- Есть публичный сайт управляющей компании.
- Есть личные кабинеты собственников и арендаторов.
- Есть административная система для сотрудников УК с разными ролями и правами доступа.
- Есть мобильная версия, Telegram-бот и интеграции с внешними системами — 1С, Bitrix24, системой пропусков и другими сервисами.
Результатом стала архитектура платформы, в которой пользовательские сценарии связаны с реальными бизнес-процессами управляющей компании, а не существуют отдельно красивыми экранами.
И именно здесь начинается главная сложность такого проекта.
[1] Сайт — только один слой системы
Снаружи проект можно принять за обычный корпоративный сайт управляющей компании: объекты, услуги, новости, контакты и кнопка входа в личный кабинет.
На деле сайт здесь — самая простая часть.
Например, собственник коммерческой недвижимости может владеть сразу несколькими помещениями в разных объектах. Одно помещение может принадлежать нескольким собственникам и одновременно сдаваться нескольким арендаторам. У помещения может быть несколько лицевых счетов и разные договоры, а доступ к финансовой информации зависит от роли конкретного пользователя.
Собственнику через портал нужно контролировать свои объекты: видеть арендаторов, документы, лицевые счета, задолженность, коммунальные показатели, заявки и услуги. Часть прав он может передавать арендаторам — например, разрешить заказывать пропуска или смотреть показания приборов учёта, но закрыть финансовые документы.
Арендатору нужен другой набор возможностей: передать показания, получить счёт, отправить его на оплату в бухгалтерию, отследить статус платежа, заказать пропуск, вызвать техническую службу, забронировать переговорную или заказать дополнительную услугу.
При этом данные не должны вручную дублироваться в портале. Финансовый контур связан с 1С ЖКХ и 1С Предприятие: оттуда должны приходить начисления, платежи, задолженности и документы. Заявки и коммуникации связаны с Bitrix24, а пропуска — с отдельной системой контроля доступа.
Есть ещё одна сторона системы, которую конечный резидент почти не видит, — сотрудники управляющей компании.
Заявка «не работает электричество» для резидента состоит из формы и статуса. Внутри УК она превращается в задачу: её нужно принять, маршрутизировать, назначить ответственному сотруднику, проконтролировать срок, получить результат и закрыть. Исполнителем может быть инженер, сотрудник эксплуатации, охрана или другой специалист. Руководитель и администратор при этом должны видеть загрузку, просроченные задачи, статусы и историю работы.
То есть здесь нет одной аудитории и одного личного кабинета. Есть единая система данных и процессов, поверх которой для каждой роли собирается свой интерфейс.
[2] Публичный сайт решает отдельную бизнес-задачу
На одном из обсуждений проекта команда управляющей компании задала вполне логичный вопрос: зачем рассказывать на сайте о преимуществах УК, если действующие резиденты и так уже работают с ней?
Если смотреть только на текущих арендаторов и собственников, вопрос справедливый.
Но публичный сайт в этом проекте нужен не им.
У него две другие задачи.
Первая — продавать сами индустриальные парки. Для потенциального инвестора уровень управления объектом — часть продукта. Автоматизированная работа с платежами, заявками, пропусками, документами и сервисами показывает, что после покупки квадратных метров собственник получает не только помещение, но и нормально организованную эксплуатацию.
Для коммерческой недвижимости это может быть отдельным аргументом в пользу объекта и влиять на воспринимаемую ценность квадратного метра.
Вторая задача — продавать уже саму управляющую компанию.
Сегодня она обслуживает собственные индустриальные парки. Но созданная цифровая инфраструктура позволяет рассматривать управление как самостоятельный бизнес: подключать новые объекты, резидентов и сотрудников, не строя каждый раз процессы с нуля.
Поэтому корпоративная часть должна объяснять компетенции УК, показывать объекты, сервис, услуги и модель работы.
А после авторизации начинается уже не продолжение сайта, а рабочий интерфейс конкретной роли.
[3] У каждой роли свой рабочий сценарий
Резидент приходит в портал не читать о преимуществах управляющей компании. Обычно у него уже есть конкретная задача.
Арендатору нужно заказать пропуск, передать показания, получить документы, отправить счёт на оплату в бухгалтерию и проверить, прошёл ли платёж.
Собственнику — посмотреть сразу несколько помещений, проверить задолженности и лицевые счета, увидеть арендаторов, контролировать документы и обращения по своим объектам.
Если что-то сломалось, пользователь оставляет заявку и дальше видит её статус: принята, назначен исполнитель, находится в работе, выполнена. Для него это одна цепочка.
Со стороны УК та же заявка должна попасть ответственному подразделению или конкретному исполнителю, получить приоритет и срок. Администратор или руководитель контролирует выполнение, а после закрытия система сохраняет историю и результат.
Поэтому внутри одного портала на самом деле существуют разные рабочие пространства:
- собственника;
- арендатора;
- сотрудников управляющей компании;
- администратора и руководителей;
- отдельных внутренних ролей — бухгалтерии, эксплуатации, охраны, юристов и других подразделений.
В исходной архитектуре отдельно прорабатывался и кабинет брокера, однако он не вошёл в текущий объём реализации.
Связывает эти интерфейсы не одинаковая навигация, а общая модель данных: объект, помещение, пользователь, договор, лицевой счёт, заявка, документ, платёж, услуга.
И именно эту модель нужно правильно собрать до начала полноценного дизайна.
[4] Коммерческая недвижимость плохо помещается в модель ЖКХ
Во время проектирования мы разбирали существующие сервисы управления недвижимостью и собирали обратную связь сотрудников УК.
Выяснилась довольно показательная проблема.
Большая часть готовых решений выросла из управления жилыми домами. В жилой недвижимости базовая сущность обычно понятна: дом, квартира, собственник, лицевой счёт.
В коммерческой всё сложнее.
Например, на одно помещение может приходиться несколько лицевых счетов.
Если система считает помещение и лицевой счёт почти одной сущностью, начинаются проблемы.
Отчёт по должникам формируется по помещению, хотя финансовому отделу нужен отчёт по конкретному лицевому счёту.
- Данные приходится вручную сравнивать с 1С.
- Типы помещений не соответствуют реальной структуре коммерческих объектов.
- Документы приходится собирать из нескольких мест.
То есть интерфейс вроде бы работает. Но сама модель данных не соответствует бизнесу.
И это важный момент.
Плохую архитектуру нельзя исправить красивым UI.
Можно аккуратно нарисовать таблицу задолженности. Но если система неправильно понимает связь между помещением, контрагентом и лицевым счётом, пользователю всё равно придётся открывать Excel.
Поэтому проектирование подобных сервисов нужно начинать не с экранов.
Сначала — сущности и связи между ними.
[5] Один экран может выглядеть одинаково, но работать по-разному
Хороший пример — карточка помещения.
Для собственника это не просто адрес и площадь.
Внутри могут быть:
- документы по помещению;
- коммунальные показатели;
- приборы учёта;
- платежи;
- другие собственники;
- арендаторы;
- данные управляющей компании.
Некоторые блоки появляются только при определённых условиях.
Если собственник один — блок совладельцев вообще не нужен.
Если помещение никому не сдано — не показываем арендаторов.
Если у пользователя нет прав на финансовые данные — не показываем соответствующие документы и начисления.
Так интерфейс постепенно перестаёт быть набором фиксированных страниц.
Он становится отражением структуры реального объекта.
И именно поэтому на сложных B2B-сервисах мы сначала проектируем сценарии и архитектуру, а уже потом начинаем обсуждать внешний вид карточек.
[6] Права доступа — это часть UX, а не настройка для разработчика
Есть распространённая ошибка: сначала нарисовать весь личный кабинет, а роли и доступы решить позже на backend.
На проекте управляющей компании такой подход быстро ломается.
Например, у собственника есть арендатор.
- Кто определяет, что арендатор может видеть?
- Только управляющая компания?
- Или собственник тоже может управлять частью его доступа?
- Кто получает счета?
- Кто видит задолженность?
- Кто может передавать показания?
- Кто заказывает постоянные пропуска?
Это уже не технические permissions.
Это отношения между компаниями, прописанные в договорах и внутренних процессах.
Поэтому в УКН появились не только роли собственника, арендатора и администратора, но и гибкая система ограничений.
А внутри административной части — отдельные роли сотрудников:
- бухгалтерия;
- эксплуатация;
- охрана;
- юристы;
- руководители;
- другие подразделения.
Каждому не нужен весь портал.
- Бухгалтеру не обязательно управлять пропусками.
- Охране — смотреть финансовую аналитику.
- Инженеру — редактировать юридические лица.
Чем больше сервис, тем опаснее роль «администратор, который видит всё».
[7] Административная часть сложнее клиентской
Клиентский кабинет обычно выглядит эффектнее в кейсе.
Красивый дашборд, карточки помещений, заявки, графики потребления.
Но с точки зрения архитектуры самая сложная часть находится с другой стороны.
Сотрудникам управляющей компании нужно управлять пользователями, сотрудниками, объектами, помещениями, лицевыми счетами, заявками, задачами, финансами, документами, услугами, подрядчиками, пропусками, уведомлениями, ролями, интеграциями и отчётностью.
И все эти модули связаны.
Поступила заявка на работу — нужно определить помещение и клиента, назначить исполнителя, создать задачу, при необходимости выставить счёт, получить оплату, выполнить работу, прикрепить фотоотчёт и уведомить резидента.
То, что для клиента выглядит как одна кнопка «Заказать услугу», внутри УК превращается в бизнес-процесс.
Поэтому хороший UX клиента часто начинается с нормально спроектированного back office.
Если внутри компании после каждой заявки менеджер вручную пишет инженеру в Telegram, потом ищет счёт в 1С, а статус заявки меняет в третьей системе, красивый личный кабинет просто маскирует старый процесс.
[8] Не нужно отправлять пользователя гулять по пяти сервисам
Отдельная проблема больших компаний — исторически сложившийся набор систем.
- CRM отдельно.
- 1С отдельно.
- Пропуска отдельно.
- Вакансии отдельно.
- Telegram-бот отдельно.
- Сайт отдельно.
Типичная идея при проектировании интерфейса звучит так: «Здесь поставим кнопку, а она перебросит пользователя в другой сервис».
Одна такая ссылка не страшна. Пять — уже проблема.
Например, в УКН обсуждался сценарий публикации вакансий через отдельную площадку. Текущее внешнее размещение было временным решением, но постоянно отправлять резидента на другой сайт мы не хотели.
Для пользователя логика должна выглядеть цельно:
открыл личный кабинет → создал вакансию → отправил на модерацию → увидел статус.
Что происходит между системами дальше — проблема архитектуры и интеграций, а не пользователя.
Тот же принцип работает с пропусками, финансовыми данными, CRM и партнёрскими услугами.
Интеграция нужна не для того, чтобы поставить ещё одну кнопку со стрелкой наружу.
Она нужна, чтобы пользователь вообще не думал, сколько систем работает за интерфейсом.
[9] Telegram-бот тоже не должен становиться вторым личным кабинетом
В проекте был Telegram-бот.
И здесь легко попасть в другую крайность: раз пользователям привычен Telegram, давайте перенесём туда половину функций.
Мы сознательно смотрели на бот как на дополнительный канал.
- Получить уведомление.
- Быстро перейти к нужному действию.
- Задать простой вопрос.
- Узнать статус.
Но основная логика и данные должны оставаться внутри продукта.
Иначе через год компания получает веб-сервис, мобильное приложение и Telegram-бот, в которых одни и те же процессы реализованы тремя разными способами.
Это уже не омниканальность.
Это три продукта, которые нужно отдельно поддерживать.
[10] Иногда вопрос «зачем нам этот блок?» полезнее новой функции
Во время проектирования большой системы комментарии быстро начинают исчисляться десятками.
- Добавить погоду.
- Показать свежую фотографию парка.
- Сделать чат.
- Добавить рекламу.
- Вывести акции конкретному собственнику.
- Сделать отдельную кнопку для техобслуживания.
- Добавить ещё один способ оплаты.
Каждая идея сама по себе может звучать нормально. Проблема начинается, когда все они попадают на первый экран. Поэтому полезный вопрос здесь не «можем ли мы это разработать?».
Почти всегда можем.
Вопрос другой: какую задачу пользователя это решает и насколько часто эта задача возникает?
Например, свежая фотография парка может хорошо работать на публичной странице объекта. Но занимает слишком ценное место на дашборде резидента, которому важнее увидеть неоплаченный счёт или статус аварийной заявки.
В этом и заключается большая часть UX-работы на корпоративных сервисах. Не придумать ещё одну функцию. А решить, чего в интерфейсе не должно быть.
[11] Сначала процессы, потом красивые экраны
На больших B2B-проектах есть соблазн как можно быстрее перейти к дизайну.
Большую схему сложно читать. В прототипах много таблиц. Заказчику гораздо приятнее обсуждать уже нарисованный экран.
Но если начать дизайн слишком рано, все нерешённые бизнес-вопросы просто переедут в макеты.
- Кто оплачивает счёт?
- Кто видит задолженность?
- Можно ли собственнику менять права арендатора?
- Что делать, если у помещения три лицевых счёта?
- Какая система является источником финансовых данных?
- Кто обрабатывает заявку?
- Можно ли подписать акт через SMS?
Эти вопросы невозможно решить цветом кнопки.
На УКН архитектура разрослась в большую систему именно потому, что мы старались сначала разобрать связи, роли и процессы.
И только потом собирать из них интерфейс.
Это дольше на старте.
Зато сильно дешевле, чем переделывать готовый дизайн или разработанную систему после разговора с бухгалтерией.
[12] Что важно предусмотреть при проектировании портала управляющей компании
Если собрать опыт проекта в несколько принципов, получится примерно так.
1. Разделяйте публичный сайт и рабочую систему. Корпоративная часть продаёт компанию и объекты. Авторизованная — решает ежедневные задачи пользователей.
2. Начинайте с модели данных. Объект, помещение, лицевой счёт, собственник, арендатор и договор — разные сущности. Особенно в коммерческой недвижимости.
3. Проектируйте права вместе с моделью данных. Мало разделить пользователей на собственника и арендатора. Нужно определить доступ к конкретным помещениям, лицевым счетам, документам, показаниям и действиям. Один пользователь может иметь разные права даже внутри разных объектов.
4. Поднимайте частые действия выше структуры. Если пропуск заказывают каждый день, пользователю неважно, к какому подразделению УК относится этот сервис.
5. Не переносите внутреннюю сложность на клиента. Пусть 1С, CRM, система контроля доступа и другие сервисы работают через интеграции.
6. Проектируйте административный интерфейс не менее внимательно, чем клиентский. Именно там находится большая часть реального бизнес-процесса.
7. Не пытайтесь запустить всё одновременно. Большая платформа должна развиваться итерациями: сначала основные сценарии, затем менее частые функции и автоматизация.
[13] Хороший сайт УК со временем перестаёт быть просто сайтом
Когда управляющая компания обслуживает несколько объектов, сотни помещений, разные типы резидентов и десятки сервисов, обычной корпоративной страницы становится мало.
Вокруг неё постепенно появляется цифровой слой бизнеса.
Платежи, документы, заявки, пропуска, показания приборов, сервисные услуги, бронирования, коммуникация, отчётность.
И в какой-то момент задача уже звучит не как «сделать сайт управляющей компании».
Нужно спроектировать систему, в которой потенциальный клиент понимает ценность УК, собственник контролирует свои активы, арендатор решает ежедневные вопросы, сотрудники получают и выполняют задачи, а руководители видят, что происходит с объектами, заявками и финансами.
При этом пользователю не должно быть важно, сколько систем работает за интерфейсом: 1С, CRM, пропускная система, Telegram или внутренние сервисы.
Поэтому начинать такой проект стоит не с главной страницы.
Начинать стоит с архитектуры.
Если вы проектируете цифровой сервис для управляющей компании и пытаетесь собрать в одну систему сайт, личные кабинеты, внутренние процессы и интеграции — можем разобрать архитектуру проекта и определить, с чего лучше начинать.
