Рекламное агентство: 40 клиентских проектов и подписки, которые съедают маржу

MAATRIX

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

Экономика агентства: почему подписки растут быстрее, чем маржа

У агентства выручка растёт ступенями: взяли нового клиента — прибавили доход. А вот стоимость SaaS-стека растёт почти линейно, причём часто по двум осям сразу.

Первая ось — количество мест (seats). Наняли ещё двух менеджеров проектов под новых клиентов — заплатили за два дополнительных места в таск-трекере, в чате, в менеджере паролей. Это ожидаемо, к этому все готовы.

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

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

Стандартный SaaS-стек агентства и куда утекают деньги

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

• Таск-менеджмент и трекинг задач — доски по каждому клиенту, часто с гостевыми доступами для согласования правок.
• Файлообмен и хранилище — передача макетов, роликов, чистовых исходников; растёт линейно с объёмом креатива.
• Аналитика и дашборды для заказчика — отдельная витрина метрик по каждому клиентскому кабинету, чтобы показывать эффективность кампаний.
• Командный и клиентский чат — обсуждение правок, срочные согласования, часто с внешними участниками на стороне клиента.
• Менеджер паролей — доступы к рекламным кабинетам, аналитике, CMS клиентов; критично важен из-за смены сотрудников и подрядчиков.
• Библиотека брендбуков и креативов — хранение гайдлайнов, шаблонов, готовых макетов по каждому клиенту отдельно.

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

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

Что даёт консолидация на своём сервере

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

Ключевое отличие не в том, что «свой сервер дешевле подписки» в моменте — на старте с одним-двумя клиентами SaaS почти всегда выгоднее, потому что не требует ни настройки, ни поддержки. Ключевое отличие — в том, как стоимость ведёт себя при росте. Стоимость аренды сервера не зависит от числа клиентских рабочих пространств, числа отслеживаемых доменов в аналитике или числа гостевых доступов в трекере. Она зависит от ресурсов — CPU, RAM, диска, — и эти ресурсы растут гораздо медленнее, чем число клиентов, потому что 40 клиентских проектов в таск-трекере или 40 сайтов в аналитике создают нагрузку, которую современный сервер средней конфигурации спокойно переваривает.

Иными словами: агентство меняет переменные расходы, которые растут вместе с успехом бизнеса, на фиксированные расходы, которые не растут вместе с успехом бизнеса. Это именно то, что нужно, чтобы маржа с каждого нового клиента действительно доставалась агентству, а не поставщикам SaaS.

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

Что переносить в первую очередь

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

1. Файлообмен и хранилище передачи макетов. Это, как правило, самая понятная и самая дорогая по объёму статья — и при этом наименее критичная к простоям: если хранилище недоступно час ночью, это неприятно, но не остановит рекламную кампанию клиента. Хорошая точка входа — развернуть Nextcloud на своём VPS: готовые инструкции по установке, синхронизации и раздаче ссылок на файлы клиентам закрывают львиную долю задач файлообменника.
2. Внутренний таск-трекер команды (без клиентских гостевых доступов на первом этапе). Здесь ниже риск — если что-то пойдёт не так, это касается только сотрудников, которые могут временно свериться в чате. Для агентства с проектной структурой хорошо ложится Plane — по интерфейсу он ближе к привычным современным трекерам, чем более тяжёлые корпоративные системы.
3. Аналитика и клиентские дашборды. Самая чувствительная часть, потому что дашборды часто напрямую видит заказчик — сюда стоит заходить, когда уже есть уверенность в стабильности сервера и настроены бэкапы. Подробный разбор именно этого сценария — в статье про аналитический дашборд для заказчика на своём сервере.
4. Менеджер паролей и доступов — переносить в последнюю очередь и очень аккуратно, с параллельным периодом, пока команда не убедится, что доступ гарантированно не теряется.

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

Минимальный стек: как это выглядит технически

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

Практическая схема — Docker Compose с отдельным контейнером на каждый сервис, общим reverse-proxy и Let's Encrypt для TLS:

version: "3.8"
services:
  proxy:
    image: nginx:stable
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/letsencrypt
    restart: unless-stopped

  nextcloud:
    image: nextcloud:latest
    volumes:
      - nextcloud_data:/var/www/html
    environment:
      - MYSQL_HOST=db
    restart: unless-stopped

  plane:
    image: makeplane/plane-app:latest
    restart: unless-stopped

  matomo:
    image: matomo:latest
    volumes:
      - matomo_data:/var/www/html
    restart: unless-stopped

  vaultwarden:
    image: vaultwarden/server:latest
    volumes:
      - vault_data:/data
    restart: unless-stopped

  db:
    image: mariadb:11
    volumes:
      - db_data:/var/lib/mysql
    restart: unless-stopped

volumes:
  nextcloud_data:
  matomo_data:
  vault_data:
  db_data:

Это упрощённая схема без учёта отдельных баз под каждый сервис (в проде разумнее развести Nextcloud, Plane и Matomo по отдельным базам данных или хотя бы отдельным схемам), но она честно показывает суть: пять сервисов, которые в SaaS-мире были бы пятью отдельными счетами, здесь живут на одной машине под одним docker compose up -d.

По ресурсам ориентируйтесь не на абстрактные «рекомендуемые системные требования» из документации каждого сервиса по отдельности (если их сложить, получится избыточно), а на суммарную нагрузку: команда из 10–15 человек плюс клиентские гостевые доступы плюс аналитика на 40 сайтов с умеренным трафиком — это диапазон задач, для которого достаточно сервера среднего уровня с запасом по диску под файлы клиентов и SSD под базы данных. Точные цифры по каждому сервису в отдельности (Nextcloud, Plane, Matomo) стоит смотреть в профильных материалах по расчёту ресурсов — нагрузка от разных агентств отличается прежде всего объёмом хранимых файлов, а не числом активных пользователей.

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

Что не стоит недооценивать: администрирование и ограничения

Честно: перенос стека на свой сервер — это не бесплатный обед, и об этом стоит сказать прямо, а не только про экономию.

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

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

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

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

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