В папке лежали файлы final, final_new и final_last. Макеты отличались одной строкой, а переписка содержала ещё несколько вложений. Координатор понимал историю проекта, но не решался отправить материал площадке: название не показывало ни назначение, ни подтверждённый статус.
Команда остановила поиск самого свежего файла и собрала короткий индекс имени. В нём появились кампания, формат, вариант и номер версии. Утверждение осталось отдельным статусом. После этого нужный макет находили по задаче, а не по памяти автора.
Почему слово final перестало помогать
Пометка final описывает намерение автора, но не сообщает назначение файла и место в истории версий.
Каждый новый круг согласования превращает финальный файл в очередной черновик. Автор добавляет уточнение к названию, потому что боится перезаписать прежний вариант. Через несколько дней порядок слов уже ничего не объясняет остальным участникам.
Дата изменения тоже не решает задачу. Файл могли открыть для просмотра, выгрузить повторно или получить из другого часового пояса. Самая новая запись не обязательно является принятой и не показывает, для какого размещения она подготовлена.
Проблема особенно заметна при нескольких форматах. Горизонтальный баннер, квадрат и короткое видео могут проходить разные круги правок. Общее слово final создаёт ложное ощущение, что все варианты согласованы одновременно.
Координатор начинает с инвентаризации. Он сопоставляет файлы с кампанией и площадкой, отмечает фактически использованные версии и переносит сомнительные материалы в отдельную область разбора. Рабочая папка после этого остаётся однозначной.
Имя как короткий индекс контекста
Устойчивое имя отвечает на четыре вопроса: для чего файл создан, какой у него формат, вариант и версия.
Первым элементом становится короткий идентификатор кампании или задачи. Он связывает креатив с медиапланом и брифом. Название продукта без кампании слишком широко, а свободное описание быстро начинает писаться разными способами.
Следом указывают технический формат понятным кодом. Код закрепляют в общей памятке и не меняют от проекта к проекту. Тогда поиск собирает все варианты одного размещения без ручного просмотра превью.
Вариант описывает содержательное различие: основной оффер, локальная версия или альтернативное изображение. Номер версии растёт только после изменения файла. Он не сообщает, принят ли материал, и поэтому не спорит со статусом согласования.
Имя должно оставаться коротким и читаться без расшифровки автора. В него не стоит помещать полный текст предложения, фамилии согласующих и эмоциональные пометки. Эти сведения живут в карточке работы, где их можно обновлять независимо.
- короткий идентификатор кампании
- единый код формата
- понятный содержательный вариант
- последовательный номер версии
Статус, который хранится отдельно
Принятие файла фиксируют в системе или реестре, а не дописывают в его название.
Статус меняется без изменения самого макета. Материал может ждать проверки, быть принят для одной площадки и требовать адаптации для другой. Если каждое решение переименовывает файл, ссылки и история передачи начинают расходиться.
В карточке указывают владельца решения, назначение и принятый номер версии. Площадка получает файл вместе с этой записью или выгрузкой. Координатор способен доказать, что отправил именно согласованный объект, а не соседний вариант из папки.
После изменения макета появляется новая версия и возвращается статус проверки. Старую запись не удаляют: она показывает, что использовалось раньше. Рабочая история остаётся прозрачной даже после смены сотрудника или повторного запуска кампании.
Доступ к принятию ограничивают ролью, которая отвечает за выпуск. Дизайнер может загрузить вариант, маркетолог добавить комментарий, но утверждённым файл становится только после явного решения. Это уменьшает число случайных финалов.
Спокойная передача вместо поиска по переписке
Перед отправкой координатор сверяет идентификатор, формат, версию и статус по одной карточке.
Проверка занимает меньше времени, потому что не требует восстанавливать очередность сообщений. Координатор открывает карточку размещения, видит принятую версию и сравнивает имя файла. Несовпадение останавливает отправку до выяснения причины.
Ссылку на папку не используют как самостоятельное подтверждение. Состав папки меняется, а получатель может открыть соседний файл. Передача называет конкретный объект и его назначение, поэтому вопрос решается без дополнительной догадки.
Старые проекты переименовывают постепенно. Сначала обрабатывают активные размещения, затем часто повторяемые материалы. Массовая смена всех архивных имён создаст больше риска, чем пользы, если история уже не участвует в работе.
Через несколько циклов слово final исчезает само. Команда перестаёт защищать файл громкой пометкой и полагается на понятную систему версий. Решение становится воспроизводимым, а передача не зависит от присутствия одного внимательного человека.
Нужно ли включать дату в имя креативного файла?
Только если дата является частью назначения, например периодом размещения. Для порядка версий лучше использовать устойчивый номер и отдельную историю изменений.
Что делать с уже накопленными файлами final?
Не переименовывать всё сразу. Сначала сопоставьте активные материалы с задачами, назначьте принятые версии и перенесите неопределённые копии в область разбора.
