Интерактивную карту генплана я делаю для застройщиков и агентств недвижимости не первый год: заказчику нужно, чтобы покупатель на сайте сразу видел свободные участки и их статус, а менеджер не сверял вручную таблицу в Excel с тем, что происходит в CRM. В статье разбираю техническую реализацию: полигоны на SVG, логику статусов продаж, синхронизацию с amoCRM и Bitrix24 через вебхуки и n8n, и на каких платформах карту вообще имеет смысл размещать.
Зачем застройщику интерактивная карта участков
На одном из проектов, ЖК на 240 квартир и 18 таунхаусов, до карты отдел продаж тратил по 15-20 звонков в день только на вопрос «а какие участки ещё свободны». После того как на сайте появилась карта с актуальными статусами, звонков с этим вопросом стало примерно в 3 раза меньше, а заявки с сайта начали приходить уже с конкретным номером участка - менеджеру не нужно было ничего уточнять по телефону.
Для покупателя карта закрывает базовый вопрос ориентации на местности: где именно находится участок, какая у него площадь, ориентация окон, соседство с зелёной зоной или парковкой. Для отдела продаж это живой срез воронки - видно, что горит, что зависло в брони дольше трёх дней, и можно звонить клиенту самому, а не ждать, пока тот решится.
Отдельный эффект - снижение нагрузки на колл-центр в первые недели старта продаж, когда трафик на сайт максимальный. Клиент сам фильтрует варианты по цене и статусу, а к менеджеру попадают уже тёплые заявки с конкретным участком, а не общий вопрос «что у вас есть».
Как устроена карта участков технически: SVG и полигоны
Технически карта генплана - это SVG-файл, где каждый участок или квартира описаны отдельным элементом <path> с уникальным data-id. Исходник обычно приходит от архитектора в DWG или из QGIS, я конвертирую его в SVG через Illustrator или скриптом на Python с библиотекой svgwrite, сохраняя привязку координат к реальному плану застройки.
Дальше на фронте вешаю обработчики кликов на каждый path, подключаю библиотеку вроде svg-pan-zoom для приближения и панорамирования - без неё на телефоне мелкие участки просто не разглядеть. Тултип при наведении показывает площадь, цену за квадратный метр и статус, клик открывает карточку с деталями и кнопкой «забронировать».
Если проект крупный, от 500 участков и больше, чистый SVG в DOM начинает тормозить: браузер держит сотни элементов с обработчиками событий, и на слабых Android-телефонах карта подвисает при зуме. В таких случаях перехожу на canvas с собственным рендерингом полигонов и попаданием клика по координатам - на одном проекте это снизило время отклика при зуме с 800 мс до 60-80 мс.
Отдельно слежу за весом самого файла. Экспорт из Illustrator без чистки часто даёт SVG на 5-8 МБ с кучей лишних метаданных - после прогона через SVGO вес обычно падает в 5-8 раз, и карта на мобильном грузится за секунду-полторы вместо десяти.
Статусы продаж на карте: свободно, бронь, продано
Стандартная логика такая: свободно - зелёный, бронь - жёлтый, обычно с таймером на 24-72 часа, продано - серый, и отдельно «недоступно к продаже» для участков под инфраструктуру или общую территорию. Ниже таблица, как я обычно развожу цвета и поведение карты по статусам.
| Статус | Цвет на карте | Доступно для клика | Что фиксируется в CRM |
|---|---|---|---|
| Свободно | Зелёный | Да, открывает форму брони | Ничего, до момента заявки |
| Бронь | Жёлтый | Нет, показывает срок брони | Сделка в статусе «бронь», таймер снятия |
| Продано | Серый | Нет, только карточка просмотра | Сделка закрыта, участок исключён из выборки |
| Недоступно | Красный / штрих | Нет | Не синхронизируется с CRM вообще |
Таймер брони - отдельная головная боль. Если бронь снимается по истечении срока, а фронт узнаёт об этом только при следующей загрузке страницы, покупатель видит на карте занятый участок, хотя он уже освободился. Решаю это либо периодическим опросом статусов раз в 30-60 секунд, либо WebSocket-каналом, если проект крупный и трафик оправдывает такую нагрузку на сервер.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Связь карты с CRM: синхронизация статусов в реальном времени
Тут два потока данных, и оба должны работать без ручного вмешательства. Первый: клиент кликает участок на карте, оставляет заявку - на бэкенде создаётся лид в amoCRM или Bitrix24 через API, участок сразу помечается как «бронь», а менеджеру в Telegram прилетает уведомление через бота на aiogram с номером участка и контактом клиента. Второй поток обратный: менеджер в CRM меняет статус сделки на «оплачено» или снимает бронь - вебхук из CRM должен долететь до карты и обновить цвет участка без переразвёртывания сайта.
Для склейки этих потоков обычно ставлю n8n: он принимает вебхуки от CRM, проверяет права и валидность данных, пишет статус в базу карты, и по расписанию или по событию гоняет обратную синхронизацию, если менеджер поменял что-то руками в самой CRM, а не через сайт. Это удобнее, чем городить прямые интеграции точка в точку - когда система из CRM, карты и бота на aiogram растёт, каждая новая связка руками превращается в отдельный источник багов.
Если на карте есть онлайн-бронирование с депозитом, для приёма платежа подключаю T‑Bank (бывший Тинькофф Эквайринг): клиент вносит 5 000-20 000 ₽ депозита прямо с карточки участка, статус меняется на «бронь» автоматически по вебхуку об оплате, а не по слову менеджера по телефону.
Контакты и платёжные данные покупателей в такой связке храню только на серверах в России - это требование 152-ФЗ по локализации персональных данных, и Google Sheets или Airtable здесь не вариант даже для черновой выгрузки. Когда синхронизация усложняется до очереди из сотен броней в сезон, ручными скриптами и одиночными вебхуками это уже не поддержать - тут нужна разработка интеграции карты с CRM с очередями и обработкой конфликтов одновременной брони одного участка двумя клиентами.
Где размещать карту: Tilda, WordPress или отдельный сервис
Платформа задаёт потолок возможностей. Для небольшого проекта на 20-70 участков кастомный скрипт на Tilda закрывает задачу полностью: карта - это блок с SVG и JS внутри существующего Zero Block, статусы подтягиваются через API из отдельной базы. Для 500+ участков и нескольких очередей строительства статику на Tilda уже не вытянуть - там нужен отдельный сервис с бэкендом и админкой для менеджеров.
| Платформа | Когда подходит | Срок | Цена |
|---|---|---|---|
| Tilda + кастомный скрипт | До 50-70 участков, один ЖК или одна очередь | 1-2 недели | от 40 000 ₽ |
| WordPress с модулем карты | Есть готовый сайт на WP, карта нужна как раздел | 2-3 недели | от 60 000 ₽ |
| Отдельный веб-сервис (SPA) | Несколько проектов, 500+ участков, своя админка | от 8 недель | от 300 000 ₽ |
На рынке за карту такого класса под ключ студии обычно просят 150 000-400 000 ₽ в зависимости от числа участков и глубины интеграции с CRM - это ориентир по рынку, не мой прайс, у меня цена считается от объёма конкретной задачи и списка интеграций.
Частые ошибки при внедрении карты генплана
Вот что чаще всего вижу, когда зовут доработать уже готовую карту на чужом проекте.
- SVG весом 5-10 МБ без оптимизации - карта грузится 10-15 секунд на мобильном интернете, и часть посетителей закрывает вкладку раньше. Сжатие через SVGO и удаление лишних метаданных обычно снижает вес в 5-8 раз.
- Статусы обновляются раз в сутки батч-выгрузкой из CRM - клиент видит участок свободным, бронирует, а он продан ещё вчера вечером. Отсюда конфликтные звонки и подорванное доверие к сайту.
- Нет блокировки одновременного бронирования: два клиента кликают один участок с разницей в пять секунд, и оба видят подтверждение. Без транзакционной проверки на бэкенде такое регулярно всплывает в сезон высокого спроса.
- Карту тестируют только на своём ноутбуке с быстрым интернетом, а половина трафика застройщика - это мобильные пользователи на 4G где-нибудь в дороге. Проверка на реальном устройстве и throttling в devtools экономит потом недели переделок.
Частые вопросы
Сколько стоит интерактивная карта генплана под ключ?
Зависит от числа участков и глубины интеграции с CRM. Простая карта на Tilda для одного ЖК - от 40 000 ₽, отдельный сервис с админкой для менеджеров и синхронизацией с amoCRM или Bitrix24 - от 300 000 ₽. Точная цифра считается после того, как я вижу исходный план и список нужных интеграций.
Можно ли сделать карту на Tilda без разработки отдельного сервиса?
Да, для проекта до 50-70 участков этого достаточно: карта живёт кастомным скриптом внутри существующего сайта на Tilda, а статусы подтягиваются через API из внешней базы. Когда участков становится больше или подключается несколько очередей строительства, статика на Tilda упирается в лимиты по весу страницы и скорости загрузки.
Как быстро обновляется статус участка после сделки в CRM?
На практике ставлю опрос статусов раз в 30-60 секунд - этого достаточно для большинства проектов и не создаёт лишней нагрузки на сервер. Для крупных объектов с высоким трафиком в сезон продаж подключаю WebSocket-канал, и обновление приходит почти мгновенно, без задержки на опрос.
Что делать, если участков очень много, 500 и больше?
Переходить с чистого SVG в DOM на рендеринг через canvas - иначе браузер на слабых телефонах начинает подвисать при зуме и панорамировании. Плюс дробить карту на очереди строительства или кластеры, чтобы не грузить весь план целиком при первом заходе на страницу.