Рекламное агентство: передача макетов клиенту без чужих облаков и умирающих ссылок

MAATRIX

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

Как макеты обычно уходят клиенту — и что в этой схеме хрупкого

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

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

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

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

Почему ссылка «умирает» не по вине конкретного человека

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

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

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

Во что это обходится агентству на практике

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

Когда файла нет, сценарий обычно один из трёх, и все три стоят агентству денег или репутации:

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

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

Альтернатива: собственный сервер как постоянная точка выдачи

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

Практическая разница выглядит так: у клиента навсегда остаётся один и тот же адрес вида files.вашеагентство.ru/klient-name/proekt-2026/, и через год, и через три года по этому адресу лежит тот же файл — если только вы сами его не удалили. Никто со стороны не решает за вас, когда файл «устарел» и его пора почистить: удаление или архивация происходит только тогда, когда это решает сделать сама команда агентства, и обычно осознанно, а не автоматически по чужому таймеру.

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

Как это устроить технически: минимальная и расширенная схема

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

Простая схема — статический файловый сервер по структуре папок. На арендованном VPS разворачивается nginx, который просто отдаёт файлы из директорий по HTTPS. Структура — по клиенту и проекту, без лишней логики:

/srv/delivery/
  klient-a/
    2026-08-brendbuk/
    2026-08-banner-set/
  klient-b/
    2026-07-video-promo/

Минимальный конфиг nginx для раздачи с базовой авторизацией по клиенту (чтобы не открывать всё подряд для всех):

server {
    listen 443 ssl;
    server_name files.вашеагентство.ru;

    ssl_certificate     /etc/letsencrypt/live/files.вашеагентство.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/files.вашеагентство.ru/privkey.pem;

    location /klient-a/ {
        auth_basic "Klient A";
        auth_basic_user_file /etc/nginx/.htpasswd_klient_a;
        root /srv/delivery;
        autoindex on;
    }
}

Сертификат для HTTPS получается через Let's Encrypt — подробно про то, как это работает и что означает подтверждение владения доменом, разобрано в статье «Как Let's Encrypt доказывает, что домен ваш». Такая схема разворачивается за пару часов и не требует поддержки отдельного веб-приложения — она отдаёт файлы, и всё.

Расширенная схема — своё файловое хранилище с личным кабинетом. Если у агентства десятки активных клиентов и хочется, чтобы у каждого был личный «кабинет» с логином, а не общая директория с базовой авторизацией, разумно развернуть на том же сервере Nextcloud — там для каждого клиента заводится отдельная учётная запись или общая папка с гостевым доступом, а публичные ссылки на файлы можно выдавать без срока действия, который определяете именно вы, а не платформа. Пошаговая установка разобрана в статье «Как установить и настроить Nextcloud на VPS». Плюс такой схемы — понятный интерфейс для клиента, минус — чуть больше работы по обслуживанию самого приложения по сравнению с простым nginx.

Обе схемы решают одну и ту же задачу — файл не исчезает и не подчиняется чужой политике хранения — просто с разным уровнем удобства для клиента и разным объёмом работы на стороне агентства.

Организация процесса: чтобы постоянство не превратилось в свалку

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

Единая структура именования. Папка на клиента, внутри — папка на проект с датой сдачи в названии, внутри — только финальные файлы, а не весь рабочий архив с черновиками и слоями. klient-a/2026-08-brendbuk-final/ читается однозначно и через три года, в отличие от итог3_ОКОНЧАТЕЛЬНО_v2.zip, лежащего где-то в общей папке.

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

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

Резервное копирование самого сервера. Постоянство ссылки бессмысленно, если единственная копия файла лежит на одном диске без бэкапа. Регулярные зашифрованные снапшоты через инструмент вроде borgbackup — недорогая страховка от того, что «постоянное» хранилище агентства однажды окажется таким же уязвимым, как чужое облако, только уже без поддержки провайдера, к которой можно обратиться в случае сбоя. Как настроить такие бэкапы, разобрано в статье «Как установить и настроить BorgBackup на VPS».

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

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

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