Коворкинг: биллинг резидентов и счета на своём сервере вместо процента с оборота

MAATRIX

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

Почему процент с оборота — плохая сделка для растущего коворкинга

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

Стоимость обработки одного счёта — техническая операция: сформировать документ, отправить уведомление, зафиксировать статус оплаты — не растёт линейно вместе с суммой в нём. Выставить счёт на 15 000 ₽ и счёт на 45 000 ₽ вычислительно одинаково просто: те же строки в базе, тот же PDF, то же письмо. А вот сумма, которую платформа удерживает себе за эту операцию, при модели «процент от оборота» вырастет втрое вместе с суммой счёта. Получается, что стоимость сервиса для вас растёт быстрее, чем растёт реальная нагрузка на сервис.

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

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

Что реально нужно от биллинга резидентов

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

• Реестр резидентов и тарифов — кто арендует что: hot desk, закреплённое место, отдельный кабинет, виртуальный офис (юрадрес). У каждого — свой тариф и дата следующего платежа.
• Регулярные счета — ежемесячная аренда должна выставляться автоматически, без ручного клика 1-го числа по каждому резиденту.
• Разовые позиции — почасовая аренда переговорной, печать, кофе, доступ гостя. Эти суммы добавляются к следующему регулярному счёту или выставляются отдельным документом.
• Отслеживание статуса оплаты — кто оплатил, у кого просрочка, кому напомнить.
• Депозиты и предоплаченные пакеты — часть резидентов вносит депозит при заезде или покупает пакет часов переговорной вперёд, это отдельный баланс, а не просто «счёт оплачен/не оплачен».
• Документы для бухгалтерии — не всем резидентам нужен формальный счёт-договор, но части — особенно юрлицам и ИП — нужен именно он, с реквизитами.

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

Готовые open-source решения — не изобретайте выставление счетов заново

Строить движок выставления счетов с нуля не нужно: это решённая задача, и решена она открытым кодом не хуже, чем платными SaaS. Мы разбирали два таких инструмента подробно:

• Invoice Ninja в Docker Compose — self-hosted система выставления счетов с поддержкой повторяющихся инвойсов, клиентского портала (у каждого резидента — свой личный кабинет со списком счетов и историей оплат), кастомных PDF-шаблонов и приёма онлайн-платежей через подключаемые платёжные шлюзы.
• Invoice Ninja или Crater: что выгоднее и когда — сравнение с более лёгкой альтернативой, если вам не нужен весь набор функций Invoice Ninja и хочется более простого инструмента.

Для коворкинга ключевая функция именно Invoice Ninja — recurring invoices: вы один раз настраиваете шаблон «резидент X, тариф hot desk, 1-е число каждого месяца», и дальше система сама формирует и отправляет счёт по расписанию, без вашего участия. Разовые позиции (переговорка, печать) добавляются вручную или через API как дополнительные строки к следующему счёту резидента.

Если учёт резидентов уже ведётся в другой системе (CRM, таблица, контроль доступа) — Invoice Ninja принимает клиентов через API, так что реестр можно оставить на месте, а счета генерировать отдельно, синхронизируя данные скриптом.

Архитектура: биллинг и учёт резидентов на своём сервере

Рабочая схема для коворкинга среднего размера (условно 30-150 резидентов) — это не одно приложение, а связка из нескольких простых блоков на одном сервере:

1. Invoice Ninja — ядро: счета, шаблоны, клиентский портал, статусы оплат.
2. База резидентов с расширенными полями — если стандартных полей клиента в Invoice Ninja не хватает (номер места, дата окончания текущего договора, привязка к пропуску системы доступа), их можно вести в лёгкой open-source табличной СУБД типа NocoDB или Baserow, синхронизируя ключевые данные (ФИО, тариф, статус) с Invoice Ninja через API раз в сутки по cron.
3. Cron-задачи — сама генерация повторяющихся счетов уже встроена в Invoice Ninja (внутренний планировщик), но проверку неоплаченных счетов и отправку напоминаний обычно удобно продублировать отдельным скриптом с более гибкой логикой (например, напоминание за 3 дня, за 1 день и в день просрочки — тремя разными письмами).
4. Резервное копирование — база данных с историей платежей резидентов бэкапится ежедневно на отдельное хранилище, не на тот же диск.

Минимальные требования к серверу под такую связку для коворкинга среднего размера:

Пример каркаса docker-compose.yml для связки Invoice Ninja + MySQL + Redis + NocoDB (детали конкретных образов и переменных окружения — в разборе Invoice Ninja выше, здесь только структура):

services:
  app:
    image: invoiceninja/invoiceninja:5
    restart: unless-stopped
    env_file: .env
    depends_on: [db, redis]
    ports: ["8080:80"]
    volumes: ["./data:/var/www/app/storage"]

  db:
    image: mysql:8
    restart: unless-stopped
    env_file: .env
    volumes: ["./mysql:/var/lib/mysql"]

  redis:
    image: redis:7-alpine
    restart: unless-stopped

  residents:
    image: nocodb/nocodb:latest
    restart: unless-stopped
    ports: ["8090:8080"]
    volumes: ["./nocodb:/usr/app/data"]

Дальше — cron-задача на сервере (не внутри контейнера) для ежедневной сверки статусов и отправки напоминаний:

# /etc/cron.d/coworking-billing
0 9 * * * root /opt/scripts/check-overdue-invoices.sh >> /var/log/billing-reminders.log 2>&1

Сам скрипт — обычно десяток строк на Python или bash с вызовом Invoice Ninja API (GET /api/v1/invoices?status=overdue), который проходит по просроченным счетам и дёргает эндпоинт отправки письма-напоминания. Логику «за сколько дней напоминать» вы контролируете полностью — в SaaS-платформе с процентной моделью такая тонкая настройка часто спрятана за более дорогим тарифом.

Приём платежей: эквайринг остаётся отдельной историей

Здесь важна честность: self-hosted биллинг решает задачу выставления счетов и учёта их статуса, но сам по себе не заменяет приём платежей. Это две разные вещи, и их легко перепутать.

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

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

Для многих небольших и средних коворкингов рабочая комбинация — принимать карты через шлюз для тех, кому так удобнее, и параллельно держать безналичный путь для юрлиц и тех, кто предпочитает перевод. Обе ветки заканчиваются одним и тем же: статус счёта в Invoice Ninja меняется на «оплачен», и резидент получает доступ / бронирование / услугу.

Экономика: как считать точку окупаемости своего сервера

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

Возьмём гипотетический коворкинг, где годовой оборот платежей резидентов сейчас условно X ₽ в месяц, и предположим, что платформа биллинга берёт с этого оборота некоторый процент — конкретную цифру для вашего договора нужно смотреть в вашем тарифе, здесь она условно называется «p %». Тогда:

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

При переходе стоит закладывать в расчёт не только аренду сервера, но и разовые затраты на настройку (разворачивание Invoice Ninja, перенос резидентов, шаблоны счетов под ваши тарифы) и небольшую регулярную нагрузку на администрирование. Для коворкинга это обычно не полная ставка, а несколько часов в месяц, особенно если рутинные операции — бэкапы, обновления безопасности — настроены автоматически с самого начала.

Миграция без пропущенного платежа

Резиденты не должны заметить смену системы биллинга — счета обязаны приходить вовремя, а история оплат не должна потеряться. Разумная последовательность:

1. Разверните новую систему параллельно со старой, не отключая текущую платформу. Один расчётный цикл (месяц) обе системы работают бок о бок.
2. Выгрузите реестр резидентов и тарифов из текущей платформы в CSV — обычно эта функция есть в любой системе управления коворкингом, даже если экспорт неудобный и приходится чистить данные руками.
3. Настройте шаблоны повторяющихся счетов в новой системе так, чтобы суммы и даты точно совпадали с текущими договорённостями — ошибка здесь бьёт по доверию резидентов быстрее всего.
4. Протестируйте на 2-3 резидентах первый расчётный цикл: пусть счета уходят из обеих систем параллельно, сверьте суммы и даты, прежде чем переводить остальных.
5. Перенесите остальных резидентов и явно сообщите об изменении реквизитов или способа оплаты, если он меняется — заранее, а не в день выставления первого счёта из новой системы.
6. Сохраните доступ к старой платформе в режиме только для чтения ещё на несколько месяцев — для сверки истории при спорах и для бухгалтерской отчётности за прошлые периоды.
7. Настройте автоматическое резервное копирование новой базы данных сразу, до того как в ней накопится история платежей — восстанавливать нечего терять всегда проще, чем разбираться с последствиями пропавшей базы задним числом.

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