Риелтор возит базу объектов в голове и в блокноте: своя CRM на сервере

MAATRIX

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

Что теряется, когда база — это голова и блокнот

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

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

Второе — история переговоров. Блокнот фиксирует факт («звонил, интересуется»), но не контекст: что именно обсуждали, на какую цену клиент готов, что его смутило при показе, о чём договорились на прошлой неделе. Через месяц активной работы с десятком параллельных сделок эти детали стираются, а клиент ожидает, что вы помните разговор полностью — иначе доверие к вам как к профессионалу падает.

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

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

Что должна уметь простая CRM — и что ей точно не нужно

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

Минимально нужны:

• карточка объекта: адрес, тип, площадь, цена, статус (в продаже, задаток, продан, снят с продажи), фото, ссылка на объявление;
• карточка клиента: контакты, тип запроса (покупка/аренда/продажа), бюджет, критерии поиска, статус;
• связь между объектом и клиентами, которые им интересовались, — чтобы по объекту сразу видеть, кому он мог бы подойти;
• журнал контактов по каждой карточке — звонок, показ, сообщение, с датой и коротким комментарием;
• фильтры и поиск: найти все объекты по району и бюджету за пару секунд, а не перелистыванием.

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

Почему не привычный облачный сервис с абонплатой

Готовые облачные CRM для агентств недвижимости решают задачу быстро — регистрация, готовые поля под объекты, мобильное приложение. Но у модели «подписка на пользователя в месяц» есть особенности, которые стоит учитывать заранее, а не после года использования.

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

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

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

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

Собираем CRM на сервере: NocoDB поверх PostgreSQL

Для одного риелтора или небольшой команды разумный вариант — не тяжёлая корпоративная CRM вроде SuiteCRM (это тоже self-hosted решение, но рассчитанное на отделы продаж с ролями, воронками и email-кампаниями), а лёгкая надстройка над обычной базой данных с готовым веб-интерфейсом. NocoDB решает именно эту задачу: берёт таблицы в PostgreSQL и строит вокруг них интерфейс с фильтрами, представлениями (таблица, канбан по статусу сделки, галерея с фото объектов) и формами — без единой строчки кода с вашей стороны. Подробный разбор установки есть в статье про установку NocoDB на VPS; здесь — минимальный рабочий стек под задачу риелтора.

Понадобится VPS с 2 vCPU и 4 ГБ RAM — для базы на несколько сотен объектов и тысяч контактов этого достаточно с запасом, диск лучше сразу взять от 40 ГБ, если планируете хранить фото объектов там же. На сервере с Ubuntu 24.04 ставим Docker и Docker Compose, дальше — файл docker-compose.yml:

version: "3.8"

services:
  crm-db:
    image: postgres:16-alpine
    container_name: crm-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: crm
      POSTGRES_USER: crm_user
      POSTGRES_PASSWORD: замените_на_свой_пароль
    volumes:
      - crm_db_data:/var/lib/postgresql/data

  nocodb:
    image: nocodb/nocodb:latest
    container_name: nocodb
    restart: unless-stopped
    depends_on:
      - crm-db
    environment:
      NC_DB: "pg://crm-db:5432?u=crm_user&p=замените_на_свой_пароль&d=crm"
      NC_PUBLIC_URL: "https://crm.вашдомен.ru"
    ports:
      - "127.0.0.1:8080:8080"
    volumes:
      - nocodb_data:/usr/app/data

volumes:
  crm_db_data:
  nocodb_data:

Порт NocoDB намеренно проброшен только на 127.0.0.1 — наружу его отдаёт обратный прокси с TLS, а не голый HTTP-порт. Для этого подойдёт Caddy — он сам получает и обновляет сертификат Let's Encrypt:

crm.вашдомен.ru {
    reverse_proxy 127.0.0.1:8080
}

После docker compose up -d и запуска Caddy (или его конфигурации на уже стоящем на сервере веб-сервере) CRM доступна по вашему домену с рабочим HTTPS. Отдельно закройте на файрволе всё лишнее — на UFW это ufw allow 22/tcp, ufw allow 443/tcp, ufw allow 80/tcp (нужен только для выпуска сертификата) и ufw enable; порт базы данных наружу открывать не нужно вовсе, он и так виден только внутри сети Docker.

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

Структура базы: объекты, клиенты, история переговоров

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

Объекты (properties): адрес, район, тип (квартира/дом/участок/коммерция), площадь, этаж, цена, статус (в продаже / задаток / продан / снят), дата добавления, ссылка на исходное объявление, поле для фото (NocoDB умеет представление вложений как галерею — это удобно, когда нужно быстро визуально пролистать варианты).

Клиенты (clients): имя, телефон, тип запроса (купить/снять/продать/сдать), бюджет от-до, критерии (район, комнатность, этаж), статус (активный / думает / отказался / сделка закрыта), источник (откуда пришёл — это со временем покажет, какие каналы вообще приносят клиентов).

Контакты (interactions): связь с клиентом и объектом, тип (звонок / показ / сообщение / встреча), дата, короткий комментарий своими словами — не для отчётности, а чтобы через месяц вспомнить, о чём именно был разговор.

Связка clients ↔ properties через таблицу interactions — это и есть механизм, который заменяет память: открываете карточку объекта и сразу видите, кто им интересовался и на какой стадии находится каждый из них, вместо того чтобы вспоминать по именам.

Пример строки в interactions в виде, как это выглядит в интерфейсе NocoDB:

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

Доступ с телефона на показе и бэкапы

Работа риелтора большую часть дня проходит не за компьютером, а на объектах и в дороге, поэтому доступ с телефона — не опция, а обязательное условие. NocoDB — обычное веб-приложение, поэтому открывается в браузере телефона по вашему домену без установки отдельного приложения; на iOS и Android можно добавить страницу на домашний экран через «Добавить на главный экран» в браузере — визуально это будет неотличимо от нативного приложения, с иконкой и без адресной строки.

Если хочется дополнительно закрыть доступ к серверу только для своих устройств — например, не выставлять форму входа NocoDB в открытый интернет вовсе, а пускать только через VPN, — на этом же сервере разумно поднять WireGuard и подключаться к CRM только через него. Это чуть усложняет доступ (нужно один раз настроить клиент на телефоне), но снимает саму возможность подбора пароля извне, потому что сервис снаружи просто не виден.

Отдельная тема — бэкапы. Вся ваша база объектов и клиентов, вся история переговоров живёт в одном PostgreSQL-контейнере на одном сервере, и без регулярных резервных копий это точно такая же единая точка отказа, какой раньше был ноутбук с блокнотом — просто с другой начинкой. Минимальный рабочий вариант — ежедневный дамп базы через cron:

#!/bin/bash
docker exec crm-db pg_dump -U crm_user crm | gzip > /backups/crm-$(date +%F).sql.gz
find /backups -name "crm-*.sql.gz" -mtime +14 -delete

Добавьте это в crontab -e на ежедневный запуск ночью и обязательно копируйте архив за пределы сервера — на отдельное хранилище или в другой регион, иначе бэкап на том же диске не спасает от отказа самого сервера. Если нужен более надёжный инструмент с шифрованием и дедупликацией вместо самописного скрипта — в статье про установку BorgBackup на VPS разобрана настройка именно для таких сценариев, когда бэкап должен работать без ручного контроля месяцами.

Практика, которая часто работает похожим образом, разобрана и для другой профессии — в статье про перенос баз 1С бухгалтера на аутсорсе на свой сервер те же принципы (единая точка отказа, регулярный бэкап, доступ с разных устройств) показаны на другом типе данных.

Частые вопросы