Ремонтная бригада: сметы, акты и переписка — свой портал вместо чата, где всё теряется

MAATRIX

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

Чат — это поток, а не архив

Мессенджер прекрасно справляется с одной задачей — донести сообщение здесь и сейчас. Он плохо справляется с задачей «найти документ месяц спустя», потому что не был для этого спроектирован: сообщения идут одной лентой, без структуры, без версий, без прав доступа. Всё, что у вас есть для поиска — полнотекстовый поиск по слову «смета», который в чате на триста-пятьсот сообщений выдаёт пятнадцать совпадений: черновик, три правки, обсуждение черновика, ссылку на чужую смету, которую скинули для сравнения цен.

Проблема усугубляется, когда бригада ведёт параллельно несколько объектов. У прораба или руководителя открыто пять-восемь чатов с заказчиками плюс общий чат бригады — и это нормальная нагрузка для сезона, когда одновременно закрываются два объекта и открываются ещё три. В каждом чате своя терминология («смета», «расчёт», «список работ»), свои файлы с одинаковыми именами вроде смета.pdf, которые каждый раз перезаписывают предыдущую версию в галерее телефона. Когда заказчик через два месяца после сдачи объекта пишет «а где акт, который мы подписывали», ответ «сейчас найду» означает реальные поиски, а не фигуру речи.

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

Что конкретно теряется по ходу ремонта

Если разложить типичный проект ремонта квартиры или помещения на этапы, видно, где именно рвётся цепочка документов:

• Черновая смета и её правки. Обычно 2-4 версии, пока заказчик не согласует финальную: убрали позицию, добавили другую, поменяли материал на более дешёвый аналог. Каждая версия — новый файл в чате, без явной пометки, какая из них действующая.
• Согласования по ходу работ. Заказчик присылает фото плитки, которая ему понравилась, бригада присылает в ответ два-три варианта с ценами — это тоже часть сметы, но по факту растворяется в переписке и не попадает ни в один документ.
• Чеки и подтверждения закупок. Особенно когда договорённость «материалы по чекам» — сфотографированный чек лежит в чате между обсуждением графика работ и мемом, который прислал заказчик не по адресу.
• Акты выполненных работ. По этапам или один финальный — их нужно не просто отправить, а получить подписанным. В переписке акт на подпись легко потерять среди «ок», «спасибо», «когда придёте завтра».
• Претензии и гарантийные случаи. Через полгода-год после сдачи заказчик пишет о протечке или трещине — и первым делом нужно поднять, что именно и когда было сделано на этом участке. Если чат за это время уже другой (сменился телефон, почистилась история) — доказательной базы просто нет.

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

Что такое «свой портал» в этом контексте

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

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

Из чего это складывается:

1. Файловое хранилище с папками по объектам — Nextcloud как база: структура папок, версии файлов, возможность выдать заказчику ссылку только на его объект без регистрации аккаунта.
2. Формирование смет и счетов — Invoice Ninja: сметы и счета как настоящие документы с позициями, а не текст «плитка 40 кв.м — 35000», написанный в чат.
3. Подпись актов удалённо — Documenso: заказчик подписывает акт с телефона по ссылке, подписанный PDF автоматически ложится в папку объекта.

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

Стек: что реально ставить и в каком порядке

Для бригады из 3-10 человек, ведущей одновременно 3-8 объектов, хватает одного VPS среднего размера. Сервисы разворачиваются через docker compose, каждый в своём контейнере, за одним обратным прокси с общим доменом (например, portal.ваша-бригада.ru, а сервисы — на поддоменах files., smety., podpis.).

Порядок разворачивания:

# 1. Базовая подготовка сервера — Docker, docker compose, firewall
apt update && apt install -y docker.io docker-compose-plugin ufw
ufw allow 22,80,443/tcp
ufw enable

# 2. Обратный прокси с автоматическим SSL — заводит поддомены под сервисы
mkdir -p ~/portal && cd ~/portal

Дальше — три сервиса в одном docker-compose.yml, каждый на своём порту за прокси. Минимальный скелет:

services:
  proxy:
    image: caddy:2
    ports: ["80:80", "443:443"]
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - caddy_data:/data

  nextcloud:
    image: nextcloud:29
    restart: unless-stopped
    volumes:
      - nc_data:/var/www/html
    environment:
      - NEXTCLOUD_ADMIN_USER=admin
      - NEXTCLOUD_ADMIN_PASSWORD=сгенерируйте-надёжный

  invoiceninja:
    image: invoiceninja/invoiceninja:5
    restart: unless-stopped
    volumes:
      - inv_data:/var/www/app/storage

  documenso:
    image: documenso/documenso:latest
    restart: unless-stopped

volumes:
  caddy_data:
  nc_data:
  inv_data:

Подробная установка и первичная настройка каждого сервиса, включая переменные окружения, базы данных и типовые ошибки — в отдельных статьях: Nextcloud на VPS, Invoice Ninja на VPS, Documenso на VPS. Здесь важнее логика: три отдельных, не связанных друг с другом по коду сервиса означают, что если один из них подведёт (обновление сломает Nextcloud, например), остальные два продолжат работать — это не монолитная CRM, где падение одного модуля кладёт всё.

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

Внутри Nextcloud заводится одна корневая папка Объекты, а внутри неё — по одной папке на каждый проект с понятным именем, включающим дату начала и краткое описание:

Объекты/
├── 2026-08_ivanova-kvartira-45m2/
│   ├── 01_smeta/
│   │   ├── smeta_v1_2026-08-03.pdf
│   │   ├── smeta_v2_dobavlena_elektrika.pdf
│   │   └── smeta_final_2026-08-12.pdf   ← действующая
│   ├── 02_akty/
│   │   ├── akt_etap1_chernovaya_otdelka.pdf
│   │   └── akt_final_podpisan.pdf
│   ├── 03_perepiska_i_resheniya/
│   │   └── soglasovanie_plitki_2026-08-15.pdf
│   ├── 04_foto/
│   │   ├── do/
│   │   ├── v_processe/
│   │   └── posle/
│   └── 05_chekki_i_zakupki/
└── 2026-08_ofis-petrova-120m2/
    └── ...

Ключевой приём — суффикс _final или дата в конце имени для однозначного обозначения действующей версии, и отдельная папка 03_perepiska_i_resheniya, куда вручную сохраняются только важные решения из чата (согласовал материал, разрешил доп. работы), а не вся переписка целиком. Это занимает у прораба буквально минуту после ключевого сообщения — сохранить скриншот или переслать файл в нужную папку — и снимает девяносто процентов споров «а мы разве это обсуждали».

Папку 04_foto стоит сразу делить на «до / в процессе / после» — это не только для порядка, а конкретно для гарантийных случаев: когда через год заказчик пишет про трещину, вы за минуту поднимаете фото стены до работ и понимаете, ваш это дефект или конструктивная особенность здания.

Доступ: кто что видит — бригада, заказчик, бухгалтер

Отдельное хранилище оправдывает себя, только если у разных людей разные права, а не общий пароль на всё. В Nextcloud это настраивается через группы и общие ссылки:

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

docker exec -u www-data nextcloud php occ files_sharing:create \
  --path="/Объекты/2026-08_ivanova-kvartira-45m2" \
  --permissions=1 \
  --password="сгенерированный-пароль"

Право --permissions=1 — это доступ только на чтение: заказчик видит документы, но не может случайно (или намеренно, в конфликтной ситуации) удалить акт, который уже подписал.

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