Obsidian для маркетолога на аутсорсе: клиенты, гипотезы и опыт по нишам в одном хранилище

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

Я собираю персональные системы в Obsidian на заказ. Перед работой с новым клиентом я раскладываю его работу на этапы и выписываю, где уходит время и пропадает информация. У маркетолога на аутсорсе я насчитал 34 таких места. Ниже - система, с которой я бы начал, и три её узла в деталях, с настройками, которые можно повторить у себя.

Это демо-кейс: типовой каркас профессии. Клиенты, гипотезы, конкуренты и цифры в примерах вымышлены.

Obsidian - программа для заметок, которая хранит всё в обычных текстовых файлах на вашем диске. Заметки связываются ссылками, а плагины добавляют таблицы, канбаны, кнопки и шаблоны.

Где маркетолог теряет информацию

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

Кроме этапов есть сквозные вещи. Заготовки и чек-листы разбросаны по файлам разных клиентов, насмотренность собирается в скриншотах и закладках, а деньги и загрузка нигде не сведены вместе.

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

Карта системы

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

Стартовую страницу открывает плагин Homepage: он показывает выбранный файл при каждом запуске Obsidian.

Наверху две колонки задач. Задачи записаны прямо в карточках клиентов и гипотезах, а собирает их плагин Tasks: он находит строки-задачи с датами по всему хранилищу и показывает выборку по условию. Слева «Сделать» - то, что пора делать сегодня, справа «Жду ответа» - задачи, по которым ждёшь клиента или подрядчика:

```tasks
not done
due before tomorrow
tags do not include #жду
sort by due
group by filename
hide backlink
hide toolbar
hide edit button
hide postpone button
hide task count
```

Запрос для правой колонки отличается двумя строками: в нём нет условия на срок, а вместо tags do not include #ждустоит tags include #жду. Попросил у клиента доступ к кабинету, пометил задачу тегом - и она появилась в правой колонке.

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

Узел 1. Карточка клиента

У каждого клиента своя заметка, и все карточки устроены одинаково: поля, бриф, факты аудита, доступы, задачи и гипотезы этого клиента.

Бриф, который не нужно вспоминать

В Obsidian у заметки есть свойства - поля в её шапке. Новая карточка заводится по шаблону, и поля появляются сами. Шаблон подставляет плагин Templater: он срабатывает, когда в папке Клиенты создаётся новая заметка. Первым делом шаблон предлагает выбрать нишу из списка заметок в папке Ниши:

<%*
const ns = app.vault.getMarkdownFiles().filter(f => f.path.startsWith("Ниши/"));
const n = await tp.system.suggester(ns.map(f => f.basename), ns);
-%>
---
ниша: "[[<% n.basename %>]]"
статус: Аудит
абонентская-плата: 0
старт: <% tp.date.now("YYYY-MM-DD") %>
tags:
  - клиент
---

Свойство ниша - ссылка на заметку ниши. На этой ссылке держится третий узел.

Ниже в шаблоне раздел «Бриф» с вопросами, которые маркетолог задаёт каждому новому клиенту.

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

Поля, которые правятся прямо на странице

Свойства в шапке редактировать неудобно, поэтому рабочие поля выведены в таблицу в начале карточки. Это делает плагин Meta Bind: он вставляет в текст заметки поля ввода, связанные со свойствами. Поменял статус в таблице - поменялось свойство.

| Статус | `INPUT[inlineSelect(option(Аудит), option(Работа), option(Пауза), option(Завершён)):статус]` |
| --- | --- |
| Абонентская плата | `INPUT[number:абонентская-плата]` ₽ в месяц |
| Работаем с | `INPUT[datePicker:старт]` |

Факты аудита и доступы

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

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

Когда проект передаётся другому специалисту или замораживается, список доступов уже собран.

Картотека клиентов

Все карточки сводит в картотеку Bases - встроенный плагин Obsidian. Она работает с заметками как с базой данных: свойства становятся колонками, набор заметок - таблицей. В картотеке Клиенты.base внизу колонки абонентской платы стоит сумма, то есть доход в месяц по всем клиентам:

views:
  - type: table
    name: Все
    order:
      - file.name
      - ниша
      - статус
      - абонентская-плата
      - старт
    summaries:
      абонентская-плата: Sum

Узел 2. Банк гипотез

Гипотезы обычно рождаются на созвоне, записываются в чат или в трекер клиента и там остаются. До проверки доходит меньшая часть, а итог проверенных через полгода никто не вспомнит. В системе каждая гипотеза - отдельная заметка.

Гипотеза как заметка

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

<%*
const cs = app.vault.getMarkdownFiles().filter(f => f.path.startsWith("Клиенты/"));
const c = await tp.system.suggester(cs.map(f => f.basename), cs);
const niche = app.metadataCache.getFileCache(c)?.frontmatter?.["ниша"] ?? "";
-%>
---
клиент: "[[<% c.basename %>]]"
ниша: "<% niche %>"
статус: Идея
метрика:
порог:
старт: <% tp.date.now("YYYY-MM-DD") %>
итог:
tags:
  - гипотеза
---

Так выглядит закрытая гипотеза в демо-хранилище.

Поле порог записывается до запуска. Без него итог подгоняется под результат: снизилась цена заявки на 5% - вроде успех, хотя рассчитывали на 20%.

Цифры раз в неделю

Пока гипотеза на проверке, в её заметке стоит повторяющаяся задача:

- [ ] Снять цифры по ретаргету 🔁 every week 📅 2026-11-03

Значок 🔁 понимает Tasks: в день срока задача появляется в колонке «Сделать», а когда её отмечаешь выполненной, Tasks сам создаёт следующую через неделю. Замер дописывается строкой в раздел «Замеры». Когда гипотеза закрыта, задачу удаляешь вместе с повтором.

Где смотреть гипотезы

Одна картотека Гипотезы.base показывает в трёх местах три разных среза.

На стартовой странице остаётся то, по чему нужно что-то сделать:

  - type: table
    name: Активные
    filters:
      or:
        - note["статус"] == "Идея"
        - note["статус"] == "На проверке"
    groupBy:
      property: клиент

В карточку клиента картотека встроена строкой ![[Гипотезы.base#Связанные]], а вид «Связанные» отбирает гипотезы, которые ссылаются на текущую заметку:

  - type: table
    name: Связанные
    filters:
      and:
        - file.hasLink(this.file)

this.file - заметка, в которую встроена картотека. Встроил вид в карточку «Белой линии» - видишь гипотезы «Белой линии». Встроил в карточку «Скетчбука» - видишь гипотезы «Скетчбука». Один вид работает на всех клиентов, и настраивать его под каждого не нужно.

Узел 3. Ниши и конкуренты

Этот узел хранит опыт по нишам.

Заметка ниши

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

Ниже три встроенные картотеки: клиенты этой ниши, закрытые гипотезы и конкуренты. Их ничего не связывает с нишей вручную. Клиент ссылается на нишу через свойство ниша, гипотеза получает ту же ссылку из шаблона, конкурент - из своего. Вид «Опыт ниши» берёт тот же фильтр по ссылке и добавляет условие на статус:

  - type: table
    name: Опыт ниши
    filters:
      and:
        - file.hasLink(this.file)
        - or:
            - note["статус"] == "Подтвердилась"
            - note["статус"] == "Не подтвердилась"
    order:
      - file.name
      - клиент
      - статус
      - итог

Новый клиент в знакомой нише

В демо-хранилище есть клиника «Белая линия», с которой маркетолог работает с марта, и новый клиент - «Улыбка на Садовой», тоже стоматология. При заведении карточки он выбирает нишу «Стоматология», открывает её заметку и видит в разделе «Что проверяли»:

У «Белой линии» квиз вместо формы записи снизил цену заявки с 2 400 до 1 650 ₽, а реклама в Яндекс Картах не окупилась при 34 отзывах. Первая гипотеза для нового клиента напрашивается сама - перенести квиз. Реклама в Картах откладывается, пока у клиники мало отзывов. Гипотеза «Перенос квиза из Белой линии» ссылается на исходную, так что через полгода видно, откуда пришла идея и сработала ли она во второй раз.

Картотека конкурентов

Конкурент - тоже заметка: цена, каналы, оффер, наблюдения с датами и свойство проверен.

Раз в квартал Tasks напоминает пересмотреть конкурента. Наблюдения между пересмотрами записывает команда плагина QuickAdd «Наблюдение по конкуренту»: выбираешь конкурента из списка, пишешь, что заметил, и строка с сегодняшней датой встаёт первой под заголовок «Наблюдения». Формат записи в настройках команды:

- {{DATE:YYYY-MM-DD}} {{VALUE:Что заметил}}

Картотека Конкуренты.base считает, сколько дней прошло с последней проверки, и отдельным видом показывает тех, кого не смотрели больше 90 дней. Этот вид стоит на стартовой странице красным блоком.

formulas:
  давность: (today() - date(note["проверен"])).days
views:
  - type: table
    name: Давно не проверяли
    filters:
      and:
        - date(note["проверен"]) < today() - "90d"
    sort:
      - property: проверен
        direction: ASC

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

Что ещё есть в системе

• Протоколы созвонов. Запись созвона расшифровывается локально, договорённости из расшифровки выписываются в протокол со ссылкой на карточку клиента, и через месяц есть на что сослаться.

• Заготовки. Структуры лендингов, чек-лист настройки аналитики, шаблоны ТЗ, рабочие формулировки офферов - короткие заметки с тегом по типу. Свежая версия одна, и она не лежит в папке прошлого клиента.

• Подрядчики. Карточка контакта: специализация, цена, с кем из клиентов работал, чем полезен. Вопрос «кто у меня хорошо делал баннеры» решается фильтром.

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

• Архив. Фильтр по статусу убирает завершённые проекты из рабочих видов. Карточки, гипотезы и заметки ниш остаются, и вернувшийся через год клиент начинает с того места, где остановились.

Что получается

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

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