Мобильное приложение для управляющей компании и жителей ЖК

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

Приложение собирает все обращения в один канал. У каждой заявки есть номер, категория, фото, исполнитель и статус — житель видит его сам и не звонит, чтобы спросить «когда придут». Управляющий видит, сколько заявок открыто, какие просрочены и по каким домам их больше всего. История обращений остаётся в системе и помогает при проверках и спорах с жителями.

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

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

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

• Заявка за минуту. Выбрать категорию, сфотографировать проблему, отправить. Если нужно, указать удобное время визита.
• Прозрачный статус. Принято, назначен мастер, в работе, выполнено — с уведомлением на каждом шаге и возможностью оценить результат.
• Пропуск гостю. Разовый пропуск для такси или курьера создаётся заранее и уходит охране или на шлагбаум — по возможностям оборудования.
• Счётчики и оплата. Показания передаются в пару касаний, начисления и история платежей видны в одном месте.
• Новости своего дома. Уведомления об отключениях, плановых работах и собраниях приходят только тем, кого они касаются.
• Голос в опросах. Жители участвуют в опросах о благоустройстве и работе УК, не приходя на встречи.

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

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

Собственное приложение оправдано в других случаях:

• у УК нестандартные процессы — собственная служба эксплуатации, свои подрядчики, особые правила доступа на территорию;
• нужен ваш бренд, а не бренд платформы — особенно если УК входит в группу девелопера и приложение продолжает его сервис для покупателей;
• важны интеграции, которых нет у коробки: с биллингом, СКУД, системами девелопера, собственным маркетплейсом услуг;
• данные жителей должны храниться в вашем контуре, а развитие продукта — зависеть от ваших приоритетов.

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

Приложение УК почти никогда не живёт отдельно. Начисления и лицевые счета хранятся в биллинге — часто это 1С или отраслевая система для ЖКХ. Приложение не дублирует эти данные, а получает их по API или регулярной выгрузке: так у жителя и у бухгалтерии одни и те же цифры.

Оплата проходит через банк-эквайер или СБП. Чеки по 54-ФЗ формирует ваша онлайн-касса или платёжный партнёр — схему выбираем вместе с бухгалтерией на этапе проектирования, чтобы не переделывать её после запуска.

Данные, которые УК обязана раскрывать в ГИС ЖКХ, обычно уже выгружает биллинг. Приложение берёт информацию из того же источника и не создаёт параллельный учёт.

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

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

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

1. Пилот на одном доме. Запускаем на ограниченной аудитории, собираем обратную связь, правим сценарии до тиражирования.
2. Точки входа. QR-коды в подъездах и лифтах, приглашение в квитанции, ссылка от диспетчера после звонка.
3. Дисциплина диспетчерской. Если на заявку из приложения отвечают дольше, чем на звонок, жители вернутся к телефону. Регламент и обучение сотрудников — часть запуска.
4. Метрики с первого дня. Доля заявок через приложение, время реакции, число активных жителей — по ним видно, работает ли продукт и что улучшать.

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

• Житель подаёт заявки, передаёт показания, оплачивает услуги, заказывает пропуска и участвует в опросах. Собственник и арендатор видят разный набор функций.
• Диспетчер работает в веб-панели: принимает обращения, уточняет категорию, назначает исполнителя и следит за сроками.
• Мастер получает наряды в телефоне, отмечает выезд и выполнение, прикладывает фото — подробно об этом на странице автоматизации УК.
• Управляющий видит сводку по домам: открытые и просроченные заявки, оценки жителей, результаты опросов.

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