Контент-план как база данных: первый слой собственной CMS для производства контента

Большинство контент-планов, которые я видел, построены на таблицах: тема, дата, площадка, статус, иногда ответственный и ссылка на публикацию.

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

Проблема в том, что контент — это не только публикация.

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

Поэтому я начал собирать для себя контент-план, как первый слой будущей системы управления контентом. Пока это одна база данных в Buildin.ai, но даже на этом уровне она уже решает проблему, которую обычная таблица не закрывает.

Почему не обычная таблица

Обычная таблица хорошо показывает список строк.

Например:

На первый взгляд всё нормально. Но в реальной работе очень быстро появляются вопросы:

• где обложка;

• где сценарий;

• какая версия текста последняя;

• была ли транскрибация;

• что уже опубликовано;

• какие материалы связаны с этой темой;

• можно ли из этого сделать статью, пост или шаблон;

• какой результат дала публикация;

• что можно развить дальше.

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

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

Материал как объект

В моей текущей модели каждая запись в базе — это отдельная тема или материал по теме.

У неё есть свойства:

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

Почему я делаю это в Buildin.ai, а не в Notion

Раньше я активно использовал Notion и до сих пор считаю его сильным инструментом для личных баз, рабочих пространств и контент-систем.

Но сейчас для меня есть практический момент: Buildin.ai открывается и работает без VPN. Для ежедневного инструмента это критично.

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

Поэтому сейчас я переношу часть своих рабочих подходов в Buildin.ai и смотрю, насколько удобно на этой платформе строить полноценные системы: базы, связи, представления, шаблоны, рабочие процессы.

Для меня это не вопрос «Buildin против Notion». Скорее вопрос: какой инструмент сейчас можно использовать как ежедневную рабочую среду без технических барьеров.

Представления вместо одной большой таблицы

Ещё одно отличие базы от обычной таблицы — представления.

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

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

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

Статус лучше вычислять, а не заполнять руками

Одна из частых проблем в любых рабочих системах — ручные статусы.

Человек опубликовал материал, но забыл поменять статус. Или поменял статус, но не добавил дату публикации. Или поставил «готово», хотя ссылка ещё не внесена.

Поэтому там, где это возможно, статус лучше выводить из более надёжных данных.

Например, если в карточке есть дата публикации, система может показывать, что материал опубликован. Если даты нет — значит материал ещё в процессе. Сам процесс тоже можно вычислять по вполне конкретным признакам.

Логика может быть простой:

если дата публикации заполнена → опубликованоиначе → в работе / ожидает публикации

Это не сложная автоматизация, но она убирает лишнее ручное действие и снижает количество ошибок.

Для меня это важный принцип: не заставлять себя обслуживать систему там, где система может сама сделать простой вывод.

Self-relation: связь материала с материалом

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

Из неё могут появиться:

• видео;

• короткий пост;

• статья;

• инструкция;

• шаблон самой системы;

• отдельная заметка по автоматизации;

• разбор ошибок;

• продолжение темы через месяц.

Если все эти материалы лежат отдельными строками без связи, через какое-то время становится сложно понять, что откуда выросло.

Self-relation позволяет связать материалы между собой.

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

Это особенно полезно, когда контент создаётся не как разовая активность, а как накопление экспертизы. Одна идея может жить долго, развиваться в разные форматы и возвращаться в работу несколько раз.

Версионность как часть процесса

В обычном контент-плане версии почти не видны.

Была идея.
Потом она изменилась.
Потом из неё получился другой материал.
Потом текст переписали.
Потом видео стало основой для статьи.
Потом статья превратилась в шаблон.

В линейной таблице всё это выглядит как хаос или вообще не фиксируется.

Но в реальном процессе версионность важна.

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

Например:

Исходная тема ├── Видео │    ├── Транскрибация │    ├── Короткий пост │    └── Обложка ├── Статья драфт ├── Статья для публикации └── Пост в паблике

Видя весь массив материалов, можно оценить объём фактической работы, посвящённой той или иной теме.

Охват сейчас просто свойство, но потом должен стать отдельной базой данных

В первой версии базы у меня есть простое поле «Охват».

Это удобно для MVP: можно быстро зафиксировать результат публикации и не усложнять структуру.

Но развивая систему дальше, охват лучше выносить в отдельную базу статистики.

Почему?

Потому что охват — это не статичное свойство материала. Это изменяющийся показатель.

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

Более правильная модель может выглядеть так:

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

Почему база — это первый слой будущей CMS

Сейчас это выглядит как контент-план. Но по сути это уже первый слой небольшой CMS. Потому что в базе появляются ключевые сущности:

• тема;

• материал;

• тип материала;

• статус;

• даты;

• связь с другими материалами;

• обложка;

• опубликованные ссылки;

• первичные метрики;

• текстовые данные;

• история развития темы.

Дальше эту систему можно расширять.

Например, вынести в отдельные базы:

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

Что это даёт уже сейчас

Даже в текущем виде база решает несколько практических задач.

Во-первых, весь контекст материала находится под рукой. Не нужно вспоминать, где лежит ссылка, где обложка, где текст, где транскрибация.

Во-вторых, видны связи между материалами. Можно понять, из какой темы выросла публикация и что из неё можно сделать дальше.

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

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

Но всё это имеет смысл только после того, как описана базовая структура.

Автоматизировать хаос бесполезно. Сначала нужно понять, где живёт идея, как она превращается в материал и что происходит после публикации.

Вывод

Для меня контент-план в виде базы данных — это не способ красиво разложить публикации по датам и видам.

Это способ описать производство контента как систему. Обычная таблица отвечает на вопрос: «Что и когда нужно опубликовать?»

База данных отвечает на вопрос: «Что это за материал, из чего он состоит, с чем связан, где опубликован, какой результат дал и какие дальнейшие шаги возможны?»

Именно поэтому я начал строить контент-систему с одной базы. Пока это не полноценная CMS.
Но это уже рабочее ядро, где идеи и материалы оживают и продолжают жить, развиваться и превращаться в новые материалы.