---
name: "cp-client"
description: "Ведёт коммерческий контур работы с чужим брендом: бриф на сотрудничество из 20 вопросов (цели, приёмка, согласование, запреты, правовой контур, доступы, объём, форс-мажор), регламент согласования, разделение ответственности по рекламе между исполнителем и клиентом, разделение контуров разных проектов и структура ежемесячной отчётности, где обязателен «раздел «чего мы не знаем» в отчёте заказчику». Профиль клиента при этом собирает cp-brand-setup, голос снимает cp-voice, числа для отчёта готовит cp-analytics-cross — здесь собирается документ и формулировки. Главное правило: метод пака применяется как есть, а профиль, голос, аватары и офферы берутся у клиента. Use when the user takes a client brand on retainer, needs a cooperation brief, an approval workflow, or a monthly client report document. Триггеры — «взять клиента на ведение», «бриф на сотрудничество», «что спросить у заказчика», «регламент согласования», «клиент говорит не своим голосом», «собери отчёт заказчику», «что писать в договоре на SMM», «сколько правок входит»."
---

Перед применением прочитай [правила интеграции «Блог с нуля»](../../context/10-blog-runtime.md). Они задают единый запуск, текущий проект и производственные ограничения; не начинай второй независимый бриф.

# cp-client · Работа с клиентским брендом

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

Главный брак этой ветки — **клиент заговорил голосом исполнителя**. Читается сразу: одинаковые хуки у трёх аккаунтов из разных ниш, одинаковые конструкции, одинаковый ритм. Аудитория клиента перестаёт узнавать своего автора, а исполнитель не может объяснить, почему упало.

## Когда не этот скилл

- **Собрать профиль клиента** — семь файлов `brands/<slug>/` → `cp-brand-setup`, режим клиентского бренда. Сюда — коммерческий контур поверх профиля.
- **Посчитать числа для отчёта**, свести площадки, объяснить расхождения метрик → `cp-analytics-cross`. Здесь собирается документ и формулировки, числа приходят оттуда.
- **Разобрать правовой вопрос по существу** — реклама или нет, кто подаёт в ЕРИР, персональные данные → `cp-compliance`. Здесь фиксируется, **кто из сторон** что делает.
- Продать своё размещение или закупить интеграцию у блогера → `cp-collab`. Позиционирование эксперта → `cp-personal-brand`.

## Контекст

Читай из `context/`: `08-brand-profile.md` (§ «Работа с клиентским брендом»), `07-evidence.md` (как формулировать выводы и чего не утверждать), `03-legal-ru.md` (§2 маркировка и цепочка, §6 реестр блогеров, §7 персональные данные), `02-metrics.md` (что площадки вообще отдают — от этого зависит, что можно обещать показывать в отчёте). Профиль клиента — `brands/<slug>/`. Не нашлось — скажи одной строкой и работай по врезке ниже, факты спрашивай, не выдумывай.

## Врезка констант

**Порядок захода на клиента:** бриф сотрудничества → профиль клиента (`cp-brand-setup`) → голос клиента с его сырья (`cp-voice`) → аудит текущего состояния (`cp-audit`) → план (`cp-content-plan`, `cp-calendar`) → производство обычным конвейером → ежемесячная отчётность.

**Правовое разделение (уровень A, по состоянию на 04.08.2026, перед применением сверяется; детали — `context/03-legal-ru.md`).** Цепочка рекламы: рекламодатель → посредники → рекламораспространитель → ОРД → ЕРИР. Erid получается **до публикации**, отчётность — в течение 30 календарных дней после окончания месяца размещения. Сбор 3% платит рекламораспространитель; по агентским договорам база — вознаграждение агента. Канал свыше 10 000 подписчиков подлежит регистрации в реестре РКН. Сбор контактов требует уведомления РКН, политики, раздельных согласий и базы на территории РФ. **Договор распределяет между сторонами убытки, но не снимает обязанность с того, на ком она по закону.** Это информация, не консультация.

**Что нельзя обещать клиенту никогда:** охваты, подписчиков, заявки, продажи, выручку, «выход в топ», сроки достижения результата. Обещать можно объём работ, состав, сроки сдачи, регулярность, соблюдение комплаенса и прозрачность цифр.

**Контуры не смешиваются.** Базы, боты, триггер-слова, домены, кабинеты ОРД, счётчики аналитики и папки `brands/<slug>/` разных клиентов — раздельные.

## Вход

Спроси одним блоком, до брифа:

1. Кто клиент, ниша, `slug` латиницей.
2. Стадия: берём в работу, уже ведём, или нужен отчёт за период.
3. Есть ли договор и что в нём написано про результат, правовой контур и объём.
4. Есть ли уже профиль в `brands/` и чей он — клиента или ваш.

Не начинай бриф, пока это не выяснено.

## Процесс

### 1. Бриф сотрудничества — 20 вопросов

Это **не бриф бренда**: про бренд, аудиторию и продукт спрашивает `cp-brand-setup`. Здесь — про то, как мы работаем вместе. Веди блоками, по 4–5 вопросов, с коротким подтверждением после каждого. Ответ «не решили» записывается как `[ПРОБЕЛ]` и выносится в список открытых вопросов к договору.

**A. Цели и приёмка**
1. Какая цель на период, своими словами клиента, без «увеличить продажи».
2. Что мы оба считаем результатом через три месяца — в проверяемых формулировках.
3. Какая метрика решающая и **откуда берётся число**: чей кабинет, кто выгружает, с какой периодичностью.
4. Что будет считаться провалом и что тогда происходит.

**B. Решения и согласование**
5. Кто согласовывает публикации и кто принимает решение при разногласии внутри команды клиента.
6. В какой срок даётся согласование и что происходит, если ответа нет к дедлайну.
7. Что публикуется без согласования вообще — сторис, комментарии, реакции на инфоповод.
8. Сколько кругов правок входит в объём и что считается новой задачей, а не правкой.

**C. Границы контента**
9. Темы под полным запретом.
10. Чувствительные темы: о чём говорим осторожно и по какому правилу.
11. Кого и что можно показывать в кадре: лицо, сотрудники, помещение, продукт, клиенты; чьи согласия на съёмку есть.

**D. Правовой контур**
12. Кто по договору **рекламодатель**, кто **рекламораспространитель**, есть ли посредник.
13. Кто получает erid, в каком ОРД, и кто подаёт акты и статистику в ЕРИР — по каждой стороне отдельно.
14. Есть ли регистрация в реестре блогеров и по каким каналам; кто её поддерживает.
15. Кто оператор персональных данных, где физически лежит база, кто хранит согласия и кто отвечает за дедлайны при утечке.

**E. Ресурсы и доступы**
16. Какие доступы даются, кем и как передаются — не паролем в переписке; что происходит с доступами при расторжении.
17. Кто снимает, на что, с какой периодичностью; кто в кадре; кто монтирует.
18. Объём в месяц по форматам: сколько роликов, постов, сторис, каруселей, писем.

**F. Деньги и форс-мажор**
19. Что входит в стоимость, что оплачивается сверху, срок и порядок оплаты, что происходит при просрочке.
20. Что делаем при форс-мажоре: блокировка или ограничение площадки, смена регулирования, отпуск клиента и недоступность съёмки, срыв сроков согласования, волна негатива, кризис в компании. Условия расторжения и что остаётся клиенту — материалы, исходники, доступы, профиль.

### 2. Профиль клиента

→ `cp-brand-setup` в режиме клиентского бренда. Опоры — только те, что клиент готов подтвердить. Цифры со слов клиента идут в `facts.md` со статусом «со слов клиента, не проверено» и в контент не выпускаются до проверки.

### 3. Голос клиента

→ `cp-voice` **с сырья клиента**: расшифровка его живого монолога, его собственные тексты. Нет сырья — не подставляй ничей голос: скилл выдаёт сценарий записи, и до записи тексты идут в нейтральной подаче, помеченной как временная.

### 4. Аудит текущего состояния

→ `cp-audit` по девяти слоям, включая правовой. Отдаётся клиенту как отдельный документ до начала производства: он же фиксирует точку отсчёта, от которой потом считается динамика.

### 5. План

→ `cp-content-plan` (банк тем под аватары клиента) → `cp-calendar` под **реальные** ресурсы клиента из пункта 17–18, а не под желаемые. План, который не выдерживает съёмочный график клиента, — источник всех дальнейших срывов.

### 6. Производство

Обычный конвейер: комплаенс → профильный скилл → `cp-voice` → `cp-humanizer` → скоринг. Дополнительно на каждой единице: сверка с `rules.md` клиента и прохождение регламента согласования из блока B.

### 7. Отчётность

Раздел ниже, ежемесячно, в одном формате все месяцы подряд — иначе динамика нечитаема.

---

## Ежемесячный отчёт клиенту

Числа готовит `cp-analytics-cross`. Здесь — структура документа и формулировки.

```
ОТЧЁТ · <бренд> · <месяц, год> · подготовлено <дата>

ВЕРДИКТ           одна строка: что произошло за месяц

1. ЧТО СДЕЛАНО    план против факта по форматам, числом.
                  Что не сделано и почему — без смягчений.
2. ЧТО ВЫРОСЛО    нормированные метрики, динамика внутри площадки,
                  сравнение с собственной медианой за 20–30 единиц.
3. ЧТО УПАЛО      столько же внимания, сколько разделу 2.
4. АРТЕФАКТЫ      что изменилось у платформы, а не у нас:
   ПЛАТФОРМЫ      смена методики, чистка подписчиков, переименование метрики.
                  Календарь разрывов — context/07-evidence.md §7.
5. ЧТО МЫ ПОНЯЛИ  гипотезы, помеченные гипотезами, с назначенной проверкой.
6. ЧЕГО МЫ        обязательный раздел, см. ниже.
   НЕ ЗНАЕМ
7. ЧТО ПРЕДЛАГАЕМ не больше трёх пунктов, каждый с ценой в часах
   ДАЛЬШЕ         и признаком, по которому поймём, что не сработало.
8. ПРАВОВОЙ       что маркировали, какие erid получены, что подано в ЕРИР
   ХВОСТ          и до какой даты, что требует действия клиента.
```

**Раздел «чего мы не знаем» — обязательный.** Без него отчёт становится презентацией. Что туда идёт:
- метрики, которых площадка не отдаёт вообще (у Telegram нет уникальных, у TikTok нет публичного определения просмотра — `context/02-metrics.md`);
- места, где числа между площадками несопоставимы, и почему;
- периоды, где объём наблюдений мал и разница статистически неразличима;
- связи, которые мы не проверяли: совпадение по времени не является причиной;
- данные, которые не дал клиент.

**Формулировки. Слева — как нельзя, справа — как честно.**

| Нельзя | Как пишем |
|---|---|
| «Охваты выросли на 40%» | «Медиана охвата на публикацию выросла с X до Y за 28 дней, N публикаций» |
| «Алгоритм срезал охваты» | «Падение совпало с <дата> — сменой методики платформы. Причинно-следственная связь не проверена» |
| «Мы вывели канал в топ» | не пишем никак |
| «Рост благодаря новой рубрике» | «Рубрика выше медианы канала на N единицах. Наблюдений мало, вывод предварительный» |
| «Средний ER по рынку — 3%» | «Бенчмарк ER не универсален: знаменатели у источников разные. Ориентир — своя медиана» |
| «В следующем месяце выйдем на N заявок» | «Предлагаем гипотезу, проверим за месяц по признаку <какому>» |

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

---

## Правовое разделение ответственности

Фиксируется **в договоре**, а не на словах и не в переписке. Минимальный перечень пунктов:

| Что распределяем | Что зафиксировать |
|---|---|
| Роли в цепочке | кто рекламодатель, кто рекламораспространитель, есть ли посредник |
| erid | кто получает, в каком ОРД, за чей счёт, к какому сроку до публикации |
| Отчётность в ЕРИР | кто подаёт акты и статистику в своей части и в какой срок |
| Сбор 3% | кто плательщик, как считается база при агентской схеме |
| Реестр блогеров | кто отвечает за регистрацию каналов и её поддержание, как подтверждается |
| Персональные данные | кто оператор, где база, кто собирает и хранит согласия, кто реагирует на утечку в дедлайны 24 и 72 часа |
| Согласия на съёмку | кто получает у людей в кадре и где хранит |
| Контент и права | кому принадлежат исходники и макеты, чьи шрифты и музыка по лицензии |
| Доступы | кто выдаёт, кто отзывает, что происходит при расторжении |

Два правила поверх таблицы:
1. **Договор перераспределяет убытки, а не обязанности.** Если по закону обязанность на стороне, она остаётся там, даже если по договору платит другой.
2. **Спорное не решается внутри проекта.** Квалификация конкретного размещения — → `cp-compliance`, дальше юрист клиента. Строка «по состоянию на <дата>, перед применением сверяется; информация, не юридическая консультация» ставится в начале любого правового абзаца документа.

## Разделение контуров

Разные клиенты — разные контуры целиком, без исключений.

- **Базы контактов** не объединяются и не переносятся: контакт, собранный для клиента А, в рассылке клиента Б — самостоятельное нарушение по 152-ФЗ, а не «оптимизация».
- **Боты и триггер-слова** раздельные. Одинаковое триггер-слово в двух ботах — чужие лиды в чужой воронке и невозможность атрибуции.
- **Кабинеты ОРД, счётчики аналитики, домены, почтовые отправители** — на стороне того, кто по договору отвечает; общий кабинет на всех клиентов ломает и отчётность, и разграничение ответственности.
- **Папки профилей** `brands/<slug>/` не пересекаются. Свой профиль исполнителя — отдельный slug.
- **Материалы клиента** не переиспользуются на другом проекте: ни кейс, ни цифра, ни съёмка, ни формулировка оффера.

## Выход

```
brands/<slug>/                  профиль клиента, собирает cp-brand-setup
brands/<slug>/client-brief.md   заполненный бриф сотрудничества, 20 пунктов,
                                плюс список [ПРОБЕЛ] как повестка к договору
brands/<slug>/rules.md          дополняется регламентом согласования
                                и правовым разделением ответственности
brands/<slug>/reports/<ГГГГ-ММ>.md   ежемесячный отчёт по структуре выше
```

Рабочие документы лежат рядом с профилем и семь файлов профиля не заменяют. В конце каждого — строка `Обновлено: <дата>`.

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

## Чек-лист перед выдачей

- Проверено, что профиль, голос, аватары и офферы взяты у клиента, а не унаследованы.
- В брифе закрыты все четыре правовых вопроса блока D или они помечены `[ПРОБЕЛ]` и вынесены в повестку договора.
- Регламент согласования содержит срок и правило на случай молчания клиента.
- Объём и число кругов правок названы числом.
- В отчёте есть раздел «чего мы не знаем» и он не формальный.
- В отчёте разделу «что упало» уделено не меньше места, чем «что выросло».
- Артефакты платформ отделены от результатов работы.
- Ни одного обещания результата продвижения — ни в презентации, ни в брифе, ни в отчёте.
- Каждая цифра в отчёте имеет источник, период и дату выгрузки.
- Правовые абзацы с датой актуальности и отсылкой к `cp-compliance`.
- Контуры клиентов не пересекаются: базы, боты, триггер-слова, кабинеты, папки.

## Красные линии

1. **Не обещать клиенту результат продвижения** — ни в презентации, ни в договоре, ни в отчёте, ни устно. Обещаем объём, состав, сроки, регулярность, комплаенс, прозрачность.
2. **Не переносить клиенту ничего своего**: ни голос, ни кейсы, ни аудиторию, ни офферы.
3. **Не выдумывать факты о клиенте.** Цифры со слов — со статусом «не проверено», до проверки в контент не идут.
4. **Не смешивать контуры разных клиентов** — базы, боты, триггер-слова, доступы, кабинеты.
5. **Не публиковать в обход регламента согласования**, даже когда сроки горят и «всё же понятно».
6. **Не давать правовых консультаций от своего имени.** Роли фиксируются, квалификация — за `cp-compliance` и юристом.
7. **Не прятать провал.** Упавшая метрика в отчёте называется прямо, вместе с тем, что мы про неё не знаем.
8. **Не комментировать малые числа как результат** и не строить на них предложений на следующий месяц.