Портал для будівельної компанії: шахматка, особистий кабінет пайовика, іпотека

Розробка порталу будівельної компанії: шахматка та особистий кабінет пайовика

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

Облік бронювання квартир у порталі — це блокування лота на строк схвалення з автоматичним зняттям після завершення строку. Будь-яка дія потрапляє до журналу: хто, коли й на якій підставі змінив статус, а шахматка збирається з однієї бази, а не з розбіжних копій таблиці. Лот, що звільнився, повертається в продаж сам, без ручних звірок.

Особистий кабінет пайовика знімає частину навантаження з відділу продажів: статуси іпотеки, графік платежів, документи та хід будівництва видно без дзвінка. Людина бачить, на якій стадії її заявка в банку, і не смикає менеджера на кожному етапі угоди.

Розробка порталу будівельної компанії починається з моделі даних: корпуси, секції, поверхи, лоти, частки та обтяження — плюс ролі, де менеджер, банк і пайовик бачать різне.

Далі інтеграції: банківські статуси іпотеки, підписання документів, вивантаження в облікову систему забудовника.

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

Єдиний портал замість таблиць: що змінюється для відділу продажів

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

У єдиному контурі бронювання ставиться прямо з картки об'єкта за хвилини: вільний лот блокується одразу й стає недоступним іншим менеджерам.

Ручні звірки між відділами закриваються, бо джерело даних одне. Статус квартири змінюється в момент угоди й одночасно видимий продажам, юридичному відділу та бухгалтерії — вивантажувати й порівнювати таблиці більше не потрібно, розбіжності не накопичуються до закриття місяця.

Частка помилок у статусах падає завдяки тому, що переходи обмежені правилами: не можна позначити «продано» заброньований лот, не можна зняти бронювання без підстави, не можна залишити суперечливий стан. Система не пропускає конфлікт, тому статус у порталі завжди збігається з фактичним.

Швидкість відповіді пайовику перестає залежати від завантаження менеджера. Особистий кабінет показує етап робіт, стан документів і платежів, а типові питання — іпотека, строки передачі, приймання — закриваються без дзвінка до відділу продажів.

У сумі це і є єдиний контур продажів: одна картка об'єкта, один статус, одна історія дій по кожній квартирі. Керівник бачить залишки й завантаження в реальному часі, а менеджер витрачає час на клієнта, а не на узгодження даних між відділами.

Варіанти реалізації: платформа, доопрацювання, власна збірка

Вибір між готовою платформою продажів, доопрацюванням поточної системи та індивідуальною розробкою визначає не набір екранів, а межі зростання порталу.

Ключовий фактор — стикування з обліком продажів і CRM забудовника: обмін статусами бронювання, ескроу та графіком платежів дає більшу частину трудовитрат. Тому варіанти реалізації порталу порівнюють за строками впровадження, свободою в нестандартних сценаріях і обсягом підтримки.

Типові процеси — беремо готову платформу продажів: шахматка та особистий кабінет пайовика з'являються в короткий строк. Доопрацювання виправдане, коли система вже веде каталог і угоди.

Власна збірка потрібна, якщо нестандартна схема оплати або розмежування доступу стають ядром порталу, а не деталлю.

Впровадження за етапами: від аудиту процесів до передачі

Порядок робіт вибудовано так, щоб ризики спливали на проєктуванні, а не в день запуску. Кожен етап закінчується артефактом, який можна перевірити, — до наступного переходимо після його приймання.

1. Аудит процесів продажів. Розбираємо, як бронювання, договір та іпотечна заявка живуть зараз: хто змінює статус приміщення, звідки беруться дані, де розходяться цифри у звітах. На виході — карта процесу, вузькі місця та перелік джерел.

2. Схема даних і ролі. Проєктуємо єдину модель: об'єкт → корпус → секція → поверх → приміщення, довідник статусів і правила переходу між ними. Ролі описуємо матрицею доступу — окремо для менеджера, іпотечного спеціаліста та пайовика; кожна зміна статусу потрапляє до журналу.

3. Перенесення історії бронювання. Звіряємо вивантаження з поточними реєстрами, зводимо дублі, зіставляємо старі статуси з новими. Контроль — за кількістю приміщень у кожному корпусі: розбіжності розбираються до завантаження.

4. Налаштування порталу та інтеграцій. Підключаємо прийом іпотечних заявок, статуси оплат, повідомлення пайовику в особистому кабінеті та вивантаження для звітності.

5. Приймальні перевірки. Проганяємо сценарії на копії реальних даних: одночасне бронювання одного приміщення двома менеджерами, скасування, шлях іпотечної угоди від заявки до реєстрації, перерахунок шахматки. Окремо дивимося поведінку інтерфейсу на повному обсязі корпусів.

6. Передача та навчання. Віддаємо документацію, регламенти й доступи, навчаємо за ролями, фіксуємо порядок підтримки та доопрацювань.

Політики доступу, схеми даних і регламенти передачі

Портал живе довше, ніж будь-яка команда розробки. Щоб зміна підрядника не перетворювалася на відновлення логіки за кодом, правила фіксуємо в документах і передаємо їх разом із доступами.

• Матриця ролей. Хто бачить шахматку цілком, хто — лише свій корпус, хто працює з договорами, а хто із заявками на іпотеку; для кожної ролі — набір дозволених дій.
• Політики доступу. Правила видимості за об'єктами: відділ продажів не вивантажує базу пайовиків, підрядник бачить статус приміщення без персональних даних.
• Опис схеми даних. Сутності — об'єкт, корпус, приміщення, договір, пайовик, платіж — їхні зв'язки та історія зміни статусів. За ним структура піднімається без розбору коду.
• Регламент обміну з банками-партнерами. Який склад даних іде на узгодження іпотеки, які поля обов'язкові, хто з боку забудовника підтверджує вивантаження і як обробляється відмова банку.
• Регламенти супроводу. Вікно оновлень, порядок відкату релізу, точки резервного копіювання, реакція на інцидент і відповідальні з обох сторін.
• Пам'ятки для співробітників за типовими операціями: бронювання, зміна статусу, продовження, вивантаження звіту для відділу продажів.

Перед передачею проходимо за списком разом із вашою командою: показуємо, де лежать документи, як ними користуватися і що оновлюється за кожної зміни системи. Опис розділів — не формальність, а страховка від залежності від одного виконавця.

Кейс: шахматка забудовника — метрики до та після запуску

Початковий стан: шахматка у файлах і ручні звірки

Продажі велися в кількох таблицях: шахматка за корпусами, окремий реєстр бронювань і листування з іпотечними менеджерами. Статус лота змінювали в одному файлі, і він не завжди доїжджав до інших — менеджери зідзвонювалися, щоб зрозуміти, чи вільна квартира. На звірку статусів ішло 5–6 годин на день, а розбіжності спливали вже після підписання договору.

Пайовик дізнавався статус лише дзвінком до офісу: чи готовий ДДУ до реєстрації, чи схвалена іпотека, які документи донести. Кожен дзвінок займав менеджера і не залишав сліду в системі — при зміні відповідального контекст за угодою губився.

Що переробили

Єдина шахматка стала джерелом правди: статус лота змінюється однією транзакцією, бронювання ставить блокування, а звільнення повертає квартиру в продаж без ручної правки.

У кабінеті пайовика з'явилися етапи угоди, статус реєстрації ДДУ та хід іпотечної заявки — замість дзвінків до офісу. Дані за об'єктами синхронізували з наш.дом.рф: проєктні декларації та фотозвіти підтягуються автоматично, ручний ввід за ними прибрали.

Метрики до та після

Зведення статусів скоротилося з 5–6 годин до 15–20 хвилин на день, частка ручних операцій за угодою впала приблизно втричі.

Подвійні бронювання зникли як клас: блокування на лоті не дає двом менеджерам продати одну квартиру одночасно, а історія змін показує, хто і коли зняв бронювання.

Близько 70% звернень пайовиків перейшли до кабінету, навантаження на офіс знизилося, а строк угоди скоротився завдяки тому, що статус іпотеки видно обом сторонам без проміжних дзвінків.

Чим відрізняється власна шахматка від інтеграції із системою продажів?

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

Якщо істина живе в зовнішній системі продажів, запуск швидший і власного коду менше, але будь-яка логіка бронювання впирається в можливості чужого кабінету.

Подвійний ввід з'являється там, де статус змінюють у двох місцях. Менеджер оформлює бронювання в обліковому контурі, портал веде свій журнал — на піку попиту це дає розбіжності: два пайовики бачать один лот вільним, оплата надходить на зняте бронювання. Лікується не ручною звіркою, а правилом одного письменника: запис робить один контур, другий читає.

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

Обмін будуємо на подіях, із захистом від повторів і нічною звіркою залишків — короткий збій зв'язку тоді не перетворюється на лот, проданий двічі.

Вибір диктують кількість одночасних бронювань, кількість каналів продажів і потрібна швидкість відгуку шахматки. Розбираємо, як це визначає архітектуру порталу.

Часті питання щодо шахматки, бронювання та особистого кабінету пайовика

Шахматка, бронювання та особистий кабінет пайовика — одна транзакційна система, а не три екрани: статус квартири змінюється атомарно, кожна зміна зберігає джерело й час.

Інженерні сумніви перед стартом стосуються не інтерфейсів, а стиків — обміну з банками, вивантажень, прав і поведінки під навантаженням.

Нижче — те, що ми перевіряємо і показуємо замовнику до початку робіт.

Як влаштовані вивантаження в зовнішні системи?

Обмін іде окремим шаром читання: звітні завдання не блокують продажі в момент бронювання. Повторний запуск вивантаження не створює дублів, а розбіжності із зовнішньою системою видно у звірці.

Що відбувається з даними при зміні підрядника?

Передаємо базу зі структурою та історією, файли, налаштування середовищ і опис форматів обміну. Приймання — за контрольними сумами та тестовим прогоном: нова команда звіряє шахматку до перемикання.

Як розмежовуються права співробітників?

Ролі будуються за зоною відповідальності, а не за посадами: менеджер бачить лише бронювання своїх корпусів, відділ іпотеки — етапи угод без персональних даних. Усі дії пишуться в незмінний журнал.

Чи витримає система день старту продажів?

Шахматка читається з проміжного шару, блокування ставиться на рівні рядка — два бронювання на одну квартиру неможливі. Перед стартом проганяємо профіль навантаження із запасом за часом відгуку.

Обговоримо задачу: оцінка строків і план робіт за вашим проєктом

Щоб оцінка строків розробки була робочою цифрою, а не здогадом, потрібні вхідні дані: ролі в порталі (пайовик, менеджер продажів, юрист), обов'язкові блоки першої черги — шахматка та особистий кабінет пайовика, і зовнішні системи для обміну.

У відповідь ви отримуєте не одну цифру, а розбір за етапами з припущеннями та ризиками. Що увійде до плану робіт за проєктом:

• схема етапів: від прототипу шахматки до промислової експлуатації, з тривалістю кожного та точками приймання;
• склад робіт: аналітика даних за об'єктами, проєктування інтерфейсів, розробка, інтеграції, навантажувальні перевірки, передача в підтримку;
• оцінка строків розробки в календарних днях — окремо за нашою частиною та за зовнішніми підрядниками (банк, відділ продажів);
• варіанти черговості: спочатку особистий кабінет і шахматка, іпотечні сценарії — другим релізом;
• склад команди та режим роботи: показ робочих збірок раз на два тижні, спільний список завдань, тестовий стенд для ваших спеціалістів;
• перелік вхідних даних, яких не вистачає для точної оцінки, і на що впливає кожна;
• порядок приймання: які перевірки вважаємо обов'язковими перед запуском в експлуатацію.

Надішліть опис задачі — повернемося з оцінкою строків і планом робіт за проєктом, потім дзвінок і фіксація схеми етапів.