Электронную почту регулярно называют устаревшим каналом. При этом компании продолжают через неё искать клиентов, предлагать партнёрства, приглашать спикеров, договариваться о публикациях и связываться с руководителями нужных направлений.
Отправить тысячу одинаковых писем технически несложно. Намного труднее выбрать подходящие компании, найти нужных людей, проверить информацию, придумать убедительный повод для обращения и не потерять результаты работы.
Именно эту подготовительную часть можно передать Codex.
Codex в таком процессе работает как цифровой ассистент. Он изучает сайты, проверяет контакты, заполняет таблицу, готовит разные письма, создаёт черновики в Gmail и следит за статусами. Человек по-прежнему принимает решения и отдельно разрешает отправку.
В этой статье разберём весь процесс с нуля. Вы получите универсальную структуру CRM, порядок работы с компаниями, инструкцию для Gmail, правила доставляемости, чек-листы, проектный скилл и девять ручных промптов.
Email-аутрич представляет собой личное деловое обращение к человеку или компании, с которыми у вас пока нет активной переписки.
Простыми словами, вы сами находите подходящего адресата и пишете ему первым.
Цели могут быть разными:
Аутрич часто путают с массовой рассылкой. Внешне оба процесса связаны с почтой, но устроены они по-разному.
| Массовая рассылка | Email-аутрич |
|---|---|
| Одна большая база | Небольшой отобранный список |
| Один текст для всех | Отдельный повод для каждого адресата |
| Подстановка имени и названия | Анализ компании и ситуации |
| Сотни или тысячи писем | Маленькие контролируемые партии |
| Главная цель: охват | Главная цель: содержательный ответ |
| Отправка почти полностью автоматизирована | Финальное решение принимает человек |
| Результаты хранятся в сервисе рассылок | Причины решений и история хранятся в CRM |
Главный признак хорошего аутрича прост: получатель видит, что письмо подготовлено именно для него.
Если достаточно заменить название компании, чтобы отправить тот же текст другому адресату, перед вами шаблонная рассылка.
Codex является AI-агентом OpenAI и частью экосистемы ChatGPT. AI-агент представляет собой систему, которая не только отвечает на вопрос, но и может самостоятельно выполнить последовательность действий с доступными инструментами.
Обычный чат в основном отвечает на вопросы и создаёт контент. Codex может работать с файлами, таблицами, браузером, Gmail и другими подключёнными инструментами. Например, агент способен открыть таблицу, взять следующую компанию, проверить её сайт, сохранить выводы в CRM и создать черновик письма.
Для работы по этому руководству программировать не требуется. Вы задаёте желаемый результат, правила и ограничения. Codex самостоятельно проходит цепочку действий и показывает результат для проверки.
В аутриче Codex используется как исследователь, редактор и операционный ассистент.
Codex доступен на нескольких поверхностях:
Для этого руководства удобнее приложение ChatGPT или браузерная версия. Программирование для описанного процесса не требуется.
Официальные ссылки:
Доступ и лимиты зависят от текущего тарифа ChatGPT. Для обработки больших баз может потребоваться тариф с более высокими лимитами.
Доступность ChatGPT и Codex зависит от страны. Перед началом работы проверьте актуальный список поддерживаемых регионов OpenAI.
Список поддерживаемых регионов: https://help.openai.com/articles/7947663-chatgpt-supported-countries
Codex может самостоятельно выполнить весь операционный цикл, но в первых партиях решения лучше проверять в контрольных точках.
| Этап | Что делает Codex |
|---|---|
| Очистка базы | Ищет дубли, пустые строки и подозрительные контакты |
| Исследование | Изучает сайт, продукты и аудиторию компании |
| Поиск получателя | Находит человека или официальный адрес отдела |
| Проверка контакта | Сохраняет источник и оценивает надёжность |
| Сегментация | Определяет, какое предложение подходит компании |
| Персонализация | Находит конкретную причину для обращения |
| Подготовка письма | Пишет тему и основной текст |
| Редактура | Ищет шаблонность, ошибки и неподтверждённые факты |
| Работа с Gmail | Создаёт черновик или ставит письмо в расписание |
| Обновление CRM | Записывает статус, текст, дату и результат |
| Улучшение процесса | Добавляет найденные ошибки в инструкции |
Самая ценная часть этого процесса находится до отправки.
Codex экономит время на поиске, проверке, заполнении таблиц и подготовке черновиков. Решение о реальной отправке остаётся за человеком.
Это ограничение лучше записать прямо в инструкции:
Создание черновика не является разрешением на отправку.
Ничего не отправляй без отдельной явной команды.
Иногда можно встретить обещание, что AI удвоит количество ответов на холодные письма. Такое утверждение нельзя использовать без реального эксперимента.
AI не гарантирует, что адресаты станут отвечать в два раза чаще.
Зато он способен заметно увеличить количество компаний, которые вы успеваете качественно проверить и подготовить за одно и то же время.
Например:
| Метрика | Без AI | С Codex |
|---|---|---|
| Проверенных компаний за рабочий блок | 5 | 10 |
| Найденных подходящих контактов | 3 | 6 |
| Готовых писем для ручной проверки | 4 | 8 |
| Время на заполнение CRM | 60 минут | 25 минут |
| Проверка писем по правилам | Вручную и по памяти | Автоматически по чек-листу |
Эти цифры служат примером расчёта, а не обещанием результата.
Смысл в другом: вы можете подготовить вдвое больше качественных обращений, не увеличивая количество отправляемых писем.
Это полезнее, чем просто ускорить рассылку. Быстрая отправка плохих писем лишь быстрее создаст проблемы с репутацией домена.
Для базового процесса достаточно четырёх компонентов.
| Компонент | Для чего нужен |
|---|---|
| Исходная база | Хранит компании, сайты и найденные контакты |
| Рабочая CRM | Хранит причины решений, тексты, статусы и результаты |
| Codex | Исследует, пишет, проверяет и выполняет операции |
| Gmail | Хранит черновики, расписание и финальные письма |
CRM представляет собой таблицу для управления контактами и историей общения.
Новичку необязательно сразу покупать отдельную CRM-систему. Для первой версии подойдёт Google Sheets.
Первая таблица служит широким списком компаний, которым потенциально можно написать.
Источниками могут быть:
Рекомендуемая структура:
| Колонка | Что хранить |
|---|---|
Категория | Отрасль или тип компании |
Компания | Название организации |
Описание | Краткая исходная информация |
Сайт | Основной домен |
Найденные email | Все обнаруженные адреса |
Телефоны | Найденные номера |
Социальные сети | LinkedIn, Telegram, MAX и другие каналы |
Источник | Откуда компания попала в базу |
Дата проверки | Когда данные проверяли |
Эту таблицу нельзя сразу использовать для отправки.
В колонке Найденные email могут оказаться: 8. Тестовые адреса. 9. Примеры из документации. 10. Старые контакты. 11. Технические ящики. 12. Адрес бухгалтерии. 13. Контакт подрядчика. 14. Email из юридического документа. 15. Имя файла. 16. Ошибочно распознанный фрагмент кода. 17. Адрес, который не связан с вашей задачей.
Поэтому Codex не должен брать первый попавшийся email.
Для каждого адреса нужно понять, кому он принадлежит и почему подходит для конкретного обращения.
Вторая таблица хранит только компании, по которым уже ведётся работа.
Здесь находятся не сырые данные, а принятые решения.
| Колонка | Что записывать |
|---|---|
ID | Внутренний номер строки |
Компания | Название адресата |
Сайт | Основной источник проверки |
Сегмент | Категория компании |
Цель обращения | Продажа, партнёрство, приглашение или PR |
Предложение | Что именно вы предлагаете |
Выбранный email | Финальный адрес получателя |
Почему выбран этот email | Причина выбора |
Контактное лицо | Имя человека, если подтверждено |
Должность | Роль человека |
Надёжность контакта | Высокая, средняя или низкая |
Источник контакта | Где найден контакт |
Продукты или направления | Чем занимается компания |
Персональный повод | Почему вы пишете именно сейчас |
Гипотеза пользы | Чем предложение может быть полезно |
Тема письма | Тема для Gmail |
Текст письма: черновик | Первая версия |
Текст письма: финал | Проверенная версия |
Статус | Текущий этап работы |
Дата отправки | Плановое или фактическое время |
Ответ или результат | Что произошло |
Следующее действие | Что нужно сделать дальше |
Не писать | Запрет новых обращений |
Примечание | Рабочая информация |
Отправитель | Кто пишет |
Email отправителя | С какого адреса идёт письмо |
Источники анализа | Какие страницы проверены |
Решение по аутричу | Писать, не писать, кому и с чем |
Почему таблица такая подробная?
Потому что через месяц вы можете не вспомнить, почему выбрали конкретного человека или откуда взялся аргумент в письме.
Хорошая CRM хранит не только результат, но и причины.
Письмо часто редактируется уже после создания Gmail-черновика.
Из-за этого текст в таблице и текст в Gmail могут разойтись.
Удобно использовать следующее правило:
| Система | Что считается актуальным |
|---|---|
| CRM | Исследование, контакты, причины решений, статусы |
| Gmail | Финальный текст конкретного письма |
После каждой партии нужно синхронизировать Gmail и таблицу.
Промпт:
Сверь Gmail с рабочей CRM.
Для каждого письма обнови:
1. Финальный текст.
2. Статус.
3. Плановую или фактическую дату отправки.
4. Полученный ответ.
5. Следующее действие.
6. Флаг «Не писать», если адресат отказался.
Это человек, который запускает аутрич.
Он:
Codex выполняет повторяемую работу:
Письмо должно идти от реального человека с понятной ролью.
Универсальная подпись:
С уважением,
{Имя и фамилия}
{Должность или роль}
{Компания или проект}
{Телефон}
{Корпоративный email}
В первое письмо не стоит добавлять все социальные сети, мессенджеры, презентации и ссылки на каналы.
Обычно достаточно корпоративного email, телефона при необходимости и одной основной ссылки в тексте.
Несколько ссылок отвлекают получателя от главного действия. Большое количество внешних элементов также может повышать подозрительность письма для почтовых фильтров. Изображения, вложения, сокращатели ссылок и пиксели отслеживания создают дополнительные риски для первого холодного контакта. Одна ссылка помогает сделать CTA понятным. CTA представляет собой действие, которое вы предлагаете получателю.
Вторая ссылка сама по себе не отправляет письмо в спам. Риск возникает из сочетания факторов: новый домен, слабая аутентификация, одинаковые письма, большое количество ссылок, изображения, вложения, отслеживание, высокая скорость отправки и жалобы.
Ниже описаны этапы, которые при обычном аутриче пришлось бы выполнять вручную. В этой схеме их выполняет Codex.
Агент сам берёт следующую партию из таблицы, открывает сайты, изучает компании, ищет контакты, заполняет CRM, пишет письма, сравнивает серию и создаёт Gmail-черновики.
Человеку не нужно проходить каждый этап руками. Он один раз задаёт правила, подключает таблицу и нужные приложения, затем проверяет контрольные точки.
Подробное описание этапов нужно, чтобы вы понимали, что именно делает Codex, какие данные он использует и где могут появиться ошибки.
Codex может самостоятельно выполнить весь операционный цикл, но в первых партиях решения лучше проверять в контрольных точках.
Codex не начинает со всей базы. Для первого теста он выбирает пять компаний. После проверки процесса объём можно увеличить до десяти.
На этапе отладки не рекомендуется превышать двадцать холодных писем в день с одного отправителя. Двадцать писем не являются техническим лимитом Gmail. Это осторожная операционная граница для нового процесса или домена, который раньше не использовался для аутрича.
Небольшая партия нужна по четырём причинам:
После нескольких стабильных партий объём увеличивают постепенно. Ориентируйтесь на возвраты писем, жалобы, попадание в спам, ответы, качество базы и способность команды обработать результат.
Если письма ставятся в расписание, между ними можно оставлять около двадцати минут.
| Письмо | Время |
|---|---|
| 1 | 11:30 |
| 2 | 11:50 |
| 3 | 12:10 |
| 4 | 12:30 |
| 5 | 12:50 |
| 6 | 13:10 |
| 7 | 13:30 |
| 8 | 13:50 |
| 9 | 14:10 |
| 10 | 14:30 |
Конкретное время зависит от вашей аудитории. Интервал не служит способом обхода фильтров. Он помогает сохранить контролируемый темп и не создавать резкий всплеск активности.
Codex открывает сайт каждой компании, изучает продукты, аудиторию и нужное направление. Агент проверяет, работает ли это направление сейчас, находит подтверждённый факт для письма, сохраняет источники и отмечает причины отказаться от контакта.
Сначала Codex возвращает структурированный анализ и заполняет CRM. После исследования человек проверяет спорные контакты и неподтверждённые выводы. Только затем процесс переходит к текстам.
Codex использует следующий приоритет:
Если доступен только адрес поддержки, Codex готовит короткое письмо с просьбой передать обращение нужному сотруднику.
Codex не обращается по имени через общий ящик без подтверждения, не придумывает должность, не использует тестовые адреса, не берёт контакт из случайного документа и не считает любой email на сайте подходящим.
Codex не ограничивается фразой «мы изучили вашу компанию». Он находит конкретный факт, который объясняет причину обращения.
| Что проверяет Codex | Пример результата |
|---|---|
| Основной продукт | Платформа аналитики продаж |
| Дополнительные модули | Отчёты, прогнозирование, контроль менеджеров |
| Целевая аудитория | Руководители отделов продаж |
| Бизнес-сценарий | Сокращение ручной отчётности |
| Недавнее изменение | Запуск нового модуля |
| Возможная проблема | Сложно показать ценность без пилота |
| Причина обращения | Предложение связано с новым модулем |
Чем точнее анализ, тем сложнее заменить название компании и отправить письмо другому адресату.
До написания письма Codex заполняет три поля:
Почему мы пишем именно этой компании:
{Конкретный подтверждённый факт}
Что мы предлагаем:
{Одно понятное действие или формат сотрудничества}
Почему это может быть полезно:
{Гипотеза пользы без выдуманных цифр и обещаний}
Если одно из полей остаётся пустым, Codex не создаёт письмо и сообщает, каких данных не хватает.
Codex делает понятными шесть элементов:
Рабочая логика:
{Имя, если подтверждено}, добрый день!
Меня зовут {имя}, я отвечаю за {направление} в {компания}.
Пишу по поводу {цель обращения}.
Обратил внимание на {подтверждённый факт}. Поэтому решил предложить {конкретное предложение}.
{Короткое объяснение пользы или формата}.
Подробности: {одна основная ссылка}.
Если предложение актуально, {простое следующее действие}. Если удобнее, ответьте на это письмо.
Если тема неактуальна, просто проигнорируйте письмо. Больше беспокоить не буду.
С уважением,
{подпись}
Это схема, а не шаблон для копирования. Codex меняет тему, начало, аргумент, длину и следующее действие под конкретного адресата.
Codex раскладывает рядом пять или десять текстов и ищет повторяющиеся темы, первые фразы, композицию, аргументы, длину и CTA.
Общими могут оставаться факты предложения, основная ссылка, обязательные условия, подпись и способ отказаться.
После подготовки текстов человек просматривает несколько писем и спорные формулировки. Codex создаёт только черновики. Реальная отправка начинается после отдельной команды.
One-shot представляет собой одну большую команду, после которой Codex самостоятельно проходит всю цепочку действий.
Технически весь процесс можно запустить одним промптом. Codex может взять компании из таблицы, исследовать их, найти контакты, заполнить CRM, написать письма и создать Gmail-черновики.
Для первого запуска такой режим рискован. Ошибка при выборе контакта может пройти через всю цепочку и превратиться в готовый черновик.
Сначала лучше использовать две контрольные точки:
После нескольких стабильных партий процесс можно запускать one-shot-командой. Запрет на самостоятельную отправку должен сохраниться.
Используй скилл Outreach.
Возьми следующие пять компаний из CRM.
Самостоятельно исследуй их, проверь контакты, заполни недостающие поля, подготовь разные персональные письма, проверь серию и создай Gmail-черновики.
Ничего не отправляй.
Остановись и покажи отчёт после создания черновиков.
Скилл представляет собой сохранённую инструкцию для повторяемой работы. В нём один раз записываются правила, структура таблицы, последовательность действий, ограничения и критерии качества.
Когда Codex получает подходящую задачу, он использует этот скилл и не требует каждый раз вставлять длинный промпт.
Скилл может содержать основной файл с инструкцией, дополнительные справочные материалы и служебные скрипты.
Codex умеет создавать и размещать скиллы. Вы можете описать результат обычным языком, попросить агента создать структуру файлов, проверить её и показать итог.
Создай для себя локальный скилл Outreach.
Запиши в нём правила исследования компаний, структуру CRM, требования к письмам, контроль серии, правила Gmail и запрет на отправку без моего подтверждения.
Размести скилл в правильной папке проекта.
После создания покажи структуру файлов и кратко объясни, что записал.
Официальная документация OpenAI: https://developers.openai.com/codex/build-skills
Сторонний русскоязычный материал: https://vc.ru/ai/2872689-codex-skills-sozdavat-ii-navyki-i-ispolzovat-opyt-drugikh
Пример структуры:
.codex/skills/outreach/SKILL.md
.codex/skills/outreach/references/checklist.md
В основном файле можно хранить:
Не добавляйте в скилл один идеальный текст письма. Codex начнёт воспроизводить его снова и снова. Скилл должен описывать критерии хорошего результата, а не готовый ответ.
Внутри скилла уже записаны:
Используй скилл Outreach.
Возьми следующие пять компаний из CRM.
Исследуй их, заполни недостающие поля, подготовь разные письма и создай Gmail-черновики.
Ничего не отправляй.
При наличии скилла вам не нужно каждый раз копировать девять длинных промптов. Они остаются полезными для ручного режима и тестирования отдельных этапов.
Даже если вы не дали готовый шаблон, Codex может создать серию похожих текстов.
Причина часто находится в самой задаче.
Предположим, вы каждый раз просите:
Через несколько писем модель начнёт повторять одну композицию:
Изучил вашу компанию...
Ваш продукт хорошо подходит...
Мы можем помочь...
Подскажите, интересно ли вам предложение?
Так появляется нейрослоп.
Под нейрослопом здесь понимается текст, который формально написан правильно, но звучит одинаково, абстрактно и безжизненно.
Основные признаки:
Если письмо продолжает работать, его нужно переписать.
Инструкция для Codex:
Не используй один шаблон с заменой имени, компании и продукта.
Пиши каждое письмо заново под конкретного адресата.
После подготовки убери из текста название компании, продукта и имя получателя.
Если оставшийся текст подходит другой компании без смысловых изменений, перепиши письмо.
Меняй композицию, длину, начало, аргумент и CTA.
Замена синонимов не считается новым письмом.
Доставляемость показывает, доходит ли письмо до почтового ящика и в какую папку оно попадает.
На неё влияют:
Риск попадания в спам формируется сочетанием факторов. К ним относятся новый домен, слабая аутентификация, одинаковые письма, большое количество ссылок, изображения, вложения, отслеживание, высокая скорость отправки и жалобы. Одна дополнительная ссылка сама по себе не является автоматической причиной блокировки.
Перед аутричем нужно проверить SPF, DKIM и DMARC.
Эти сокращения звучат сложно, но их смысл можно объяснить простыми словами.
SPF сообщает почтовой системе, какие серверы имеют право отправлять письма от имени вашего домена.
Если домен использует только Google Workspace, типовая запись может выглядеть так:
v=spf1 include:_spf.google.com ~all
Не копируйте её без проверки.
Сначала выясните, какие системы отправляют письма от вашего домена:
Если забыть одну легальную систему, её письма могут перестать проходить проверку.
DKIM добавляет к письму цифровую подпись.
Почтовая система получателя проверяет, что письмо действительно отправлено вашим доменом и не было изменено по дороге.
Для Google Workspace последовательность выглядит так:
Пример структуры записи:
Host: google._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=...
Полное значение будет уникальным для вашего домена.
DMARC задаёт правила для писем, которые не прошли проверки SPF или DKIM.
Через него также можно получать отчёты об использовании домена.
Безопасная последовательность:
p=none.Не включайте жёсткую политику вслепую. Сначала убедитесь, что все легальные системы настроены правильно.
Для первого письма полезно установить ограничения:
Re: и Fwd: в теме.Каждая дополнительная ссылка отвлекает получателя.
Если в первом письме есть сайт, презентация, календарь, Telegram, кейс и форма заявки, человеку приходится выбирать между шестью действиями.
Оставьте один основной переход. Остальные материалы можно отправить после ответа.
Для первого холодного письма безопаснее использовать обычный текст и одну ссылку на главное действие. Остальные материалы можно отправить после ответа.
Подготовьте несколько новых контрольных адресов:
Отправьте одинаковое тестовое письмо и проверьте: 5. Пришло ли оно. 6. Попало ли во входящие. 7. Появилось ли предупреждение. 8. Работает ли ссылка. 9. Правильно ли отображается отправитель. 10. Понятен ли Reply-To. 11. Не продублирован ли текст. 12. Изменился ли результат после настройки DNS.
Контрольный адрес должен оставаться чистым.
Если пользователь вручную достал письмо из спама, почтовая система запомнит это действие. Следующий тест на том же адресе нельзя считать независимым.
Для чистой проверки используйте новый ящик.
Codex не должен получать:
Правильная схема: 5. Пользователь самостоятельно входит в Gmail. 6. Открывает нужный аккаунт. 7. Проверяет настроенные адреса отправителя. 8. Открывает нужную вкладку. 9. Сообщает Codex, какое действие разрешено. 10. После выполнения проверяет результат.
Если в Gmail настроено несколько отправителей, поле From нужно проверять в каждом письме.
Открытый аккаунт и фактический адрес отправителя могут различаться.
Операционный чек-лист:
Codex не должен нажимать «Отправить», если задача ограничена созданием черновика.
Если письма должны уйти завтра с интервалом двадцать минут:
Отчёт можно оформить так:
| Компания | Получатель | Время |
|---|---|---|
| Компания А | contact@company-a.ru | 11:30 |
| Компания Б | partnerships@company-b.ru | 11:50 |
| Компания В | hello@company-c.ru | 12:10 |
Редактирование запланированного письма требует узкой и точной команды.
Сначала зафиксируйте:
Команда:
Открыл вкладку Gmail «Запланированные».
Исправь текст указанных писем.
Ограничения:
1. НЕ ОТПРАВЛЯЙ.
2. Время отправки не меняй.
3. Дату не меняй.
4. Получателей не меняй.
5. Темы не меняй.
6. Разрешено менять только тело письма.
7. После правки проверь папку «Запланированные».
8. Убедись, что дата и время остались прежними.
Иногда Gmail временно снимает письмо с расписания во время редактирования. После правки его нужно вернуть в исходный слот.
Если скилл Outreach уже создан, копировать эти промпты при каждой партии не требуется.
Они нужны для ручного режима, тестирования отдельных этапов и первоначальной настройки процесса.
Этот вариант подойдёт тем, кто пока не хочет создавать скилл или предпочитает контролировать каждый этап отдельной командой.
Ты — архитектор Codex Skills и специалист по персональному outreach.
Твоя задача — провести интервью с пользователем, изучить материалы его проекта и создать отдельный Codex-скилл для конкретной outreach-кампании.
Важно: итоговый скилл НЕ должен быть универсальным. Он должен быть заточен под конкретную компанию, продукт, задачу, аудиторию, отправителя, предложение, канал и рабочий процесс пользователя.
Не начинай создавать скилл сразу. Сначала собери контекст.
# 1. Режим общения
Общайся с пользователем простым языком, без технического жаргона.
Задавай вопросы по одному:
1. Задай один вопрос.
2. Дождись ответа.
3. Изучи ответ и предоставленные материалы.
4. Зафиксируй полученные сведения.
5. Задай следующий вопрос.
Не отправляй пользователю длинную анкету из 15–20 вопросов одним сообщением.
Не спрашивай то, что можно узнать из:
- прикреплённых файлов;
- сайта компании;
- проектной папки;
- проектных инструкций;
- CRM или базы контактов;
- подключённых документов;
- официальных внешних источников.
Если пользователь передал файл, ссылку или папку, сначала изучи их полностью, а затем задавай только вопросы о недостающих данных.
Если пользователь не знает ответа, помоги ему:
- предложи 2–3 понятных варианта;
- кратко объясни различия;
- порекомендуй подходящий вариант;
- не принимай важное решение молча.
# 2. Какой результат нужно создать
Создай проектный скилл, который сможет выполнять outreach именно этого пользователя.
В зависимости от задачи скилл должен уметь:
- искать подходящие компании и контактных лиц;
- работать с готовым списком адресатов;
- проверять и обогащать контактную базу;
- исследовать компанию, продукт и получателя;
- выбирать персональный повод для обращения;
- определять основной аргумент для конкретного адресата;
- писать первые персональные письма;
- готовить follow-up-письма;
- создавать различающиеся письма для серии;
- проверять факты и контакты;
- проверять качество текста;
- создавать черновики в используемом почтовом сервисе;
- обновлять таблицу или CRM, если пользователь это разрешил;
- отправлять письма только после отдельного прямого разрешения.
Включай только те возможности, которые нужны конкретному пользователю.
# 3. Первый этап — изучение доступного контекста
Перед вопросами проверь доступные материалы:
- инструкции текущего проекта;
- описание компании;
- описание продукта или услуги;
- сайт;
- презентации;
- коммерческие предложения;
- прошлые письма;
- примеры коммуникации;
- брендбук или Tone of Voice;
- таблицу с адресатами;
- CRM;
- почтовый сервис;
- файлы с условиями кампании;
- применимые юридические и организационные ограничения.
Составь внутренний список:
- что уже известно;
- что подтверждено источниками;
- что является предположением;
- чего не хватает;
- какие сведения критичны для создания скилла.
Не проси пользователя повторно сообщать найденную информацию.
# 4. Второй этап — интервью
Проведи адаптивное интервью. Не задавай вопрос, если ответ уже найден в материалах.
## 4.1. Компания и проект
Выясни:
- название компании или проекта;
- чем занимается компания;
- какой продукт, услуга или инициатива продвигается;
- официальный сайт;
- основные преимущества;
- подтверждённые результаты, кейсы и цифры;
- географию работы;
- язык коммуникации;
- материалы, которые считаются каноническими.
Предложи пользователю прислать:
- описание компании;
- презентацию;
- ссылку на сайт;
- коммерческое предложение;
- описание продукта;
- существующие тексты.
## 4.2. Цель outreach
Выясни:
- зачем запускается рассылка;
- какого результата хочет пользователь;
- что должен сделать адресат;
- что считается успешным ответом;
- является ли кампания продажей, партнёрством, приглашением, исследованием, PR-коммуникацией или другой задачей;
- это разовая кампания или постоянный процесс.
Попроси сформулировать:
- что компания предлагает адресату;
- что хочет получить взамен;
- почему адресату это может быть полезно;
- почему предложение актуально именно сейчас.
Если формулировка размыта, помоги превратить её в конкретное предложение.
## 4.3. Целевая аудитория
Выясни:
- каким компаниям или людям нужно писать;
- отрасль;
- размер компании;
- географию;
- тип продукта или бизнеса;
- нужные должности и роли;
- признаки подходящего адресата;
- признаки неподходящего адресата;
- приоритетные сегменты;
- исключения и стоп-лист.
Если аудиторий несколько и для них нужны разные предложения, укажи это пользователю.
Не объединяй принципиально разные кампании в один скилл без согласования. Предложи:
- отдельные скиллы;
- либо отдельные сценарии внутри одного скилла.
## 4.4. Контактная база
Выясни, есть ли готовый список адресатов.
Если список есть:
- попроси файл, ссылку на таблицу или доступ к CRM;
- изучи структуру полей;
- проверь, какие сведения уже собраны;
- выясни, какие поля можно читать;
- выясни, какие поля можно изменять;
- выясни, как фиксировать статус контакта;
- не изменяй данные без прямого разрешения.
Если списка нет:
- выясни, должен ли будущий скилл искать компании;
- определи критерии поиска;
- определи нужные источники;
- определи нужные данные по каждой компании;
- определи нужные роли контактных лиц;
- согласуй формат создаваемого списка;
- согласуй, куда сохранять найденные контакты.
Отдельно выясни, разрешено ли использовать:
- общие адреса;
- личные рабочие адреса;
- формы обратной связи;
- социальные сети;
- профессиональные платформы;
- другие каналы.
## 4.5. Отправитель
Выясни:
- от чьего имени идут письма;
- имя;
- должность;
- компания;
- рабочий email;
- подпись;
- отношение отправителя к предложению;
- нужно ли представляться в начале;
- есть ли несколько отправителей;
- какой аккаунт использовать для черновиков и отправки.
Не придумывай отправителя, должность или подпись.
## 4.6. Содержание письма
Выясни:
- какие факты обязательно должны быть в письме;
- какое предложение делается;
- какая выгода или ценность есть для адресата;
- какие доказательства можно использовать;
- какой основной призыв к действию;
- какие альтернативные действия допустимы;
- какие сроки нужно сообщить;
- какие ссылки разрешены;
- нужны ли вложения;
- какие формулировки обязательны;
- какие формулировки запрещены;
- какие обещания нельзя давать;
- нужна ли фраза о прекращении дальнейших сообщений.
Не превращай список обязательных фактов в жёсткий шаблон письма. Итоговый скилл должен уметь естественно встраивать их в разные композиции.
## 4.7. Стиль коммуникации
Выясни:
- желаемый тон;
- степень официальности;
- допустимую длину;
- обращение на «ты» или «вы»;
- язык писем;
- особенности терминологии;
- правила написания брендов и продуктов;
- правила использования тире, кавычек, сокращений и эмодзи;
- допустим ли юмор;
- есть ли примеры хороших писем;
- есть ли примеры неудачных писем.
Если пользователь предоставил примеры, извлеки из них принципы стиля. Не копируй случайные ошибки или нежелательные шаблонные конструкции.
## 4.8. Персонализация
Выясни:
- насколько глубоко исследовать каждого адресата;
- какие факты использовать для персонализации;
- какие источники считать надёжными;
- сколько времени допустимо тратить на одного адресата;
- какие данные запрещено использовать;
- нужен ли отдельный аргумент под каждый сегмент;
- нужно ли искать конкретного человека;
- можно ли писать на общий адрес.
Согласуй правило:
персонализация должна объяснять, почему обращение направлено именно этой компании или человеку, а не ограничиваться подстановкой имени и названия компании.
## 4.9. Серия и follow-up
Выясни:
- нужно ли только первое письмо;
- нужны ли повторные сообщения;
- сколько касаний допустимо;
- через какие интервалы;
- должен ли каждый follow-up добавлять новый аргумент;
- когда прекращать коммуникацию;
- как обрабатывать положительный ответ;
- как обрабатывать отказ;
- что делать при отсутствии ответа.
Не придумывай график отправки без согласования.
## 4.10. Черновики и отправка
Выясни:
- должен ли скилл только писать тексты;
- создавать черновики;
- отправлять письма;
- работать с таблицей или CRM;
- фиксировать результаты;
- планировать follow-up.
Разделяй разрешения:
- написать текст;
- создать черновик;
- отправить письмо;
- изменить базу;
- поставить follow-up.
Одно разрешение не включает остальные.
Зафиксируй, какие действия скилл может выполнять самостоятельно, а какие требуют отдельного подтверждения.
## 4.11. Ограничения
Выясни:
- географию адресатов;
- применимые правила рассылки;
- требования к персональным данным;
- внутренние правила компании;
- ограничения почтового сервиса;
- запрещённые категории адресатов;
- существующий стоп-лист;
- правила обработки отказа;
- допустимый темп отправки.
Не выдавай предположение о юридической допустимости за подтверждённый факт.
# 5. Минимум данных для создания скилла
Не переходи к созданию скилла, пока не определены:
- компания или проект;
- продукт или предмет предложения;
- цель кампании;
- целевая аудитория;
- предложение адресату;
- желаемое действие адресата;
- отправитель;
- канал коммуникации;
- обязательные факты;
- основные ограничения;
- источник контактов или правила их поиска;
- разрешённые внешние действия.
Если часть информации отсутствует, продолжи интервью.
# 6. Согласование проектного брифа
После интервью подготовь краткий структурированный бриф:
1. Компания и продукт.
2. Цель outreach.
3. Целевая аудитория.
4. Критерии подходящего адресата.
5. Сегменты.
6. Предложение.
7. Ценность для адресата.
8. Желаемый ответ или действие.
9. Отправитель.
10. Канал и аккаунт.
11. Обязательные факты.
12. Ссылки и вложения.
13. Стиль.
14. Правила персонализации.
15. Follow-up.
16. Работа со списком или поиск контактов.
17. Разрешённые действия.
18. Запрещённые действия.
19. Неподтверждённые сведения.
20. Открытые вопросы.
Покажи бриф пользователю и попроси подтвердить его.
Не создавай скилл до подтверждения брифа.
Если пользователь внёс исправления, обнови бриф и снова покажи изменённую версию.
# 7. Создание проектного скилла
После подтверждения создай Codex-скилл именно для согласованной компании и кампании.
Название скилла должно:
- отражать проект или компанию;
- отражать outreach-задачу;
- состоять из строчных латинских букв, цифр и дефисов;
- быть короче 64 символов.
Пример принципа названия:
`<project>-outreach`
Не используй это буквально, если можно подобрать более точное имя.
Определи место создания скилла:
- спроси пользователя, если он указал предпочтительную папку;
- иначе используй стандартную директорию пользовательских скиллов текущего окружения.
Используй штатный процесс создания Codex Skills, если он доступен:
1. Инициализируй скилл.
2. Создай необходимые файлы.
3. Сгенерируй интерфейсные метаданные.
4. Проверь структуру.
5. Запусти валидацию.
6. Исправь найденные ошибки.
7. Повтори проверку.
# 8. Структура проектного скилла
Создавай только необходимые файлы.
Рекомендуемая структура:
<project>-outreach/
├── SKILL.md
├── agents/
│ └── openai.yaml
└── references/
├── campaign.md
├── checklist.md
└── sources.md
При необходимости добавь:
- `references/audiences.md` — если есть несколько сегментов;
- `references/style.md` — если правила стиля подробные;
- `references/contact-research.md` — если скилл должен самостоятельно искать адресатов;
- `references/data-schema.md` — если он работает с таблицей или CRM;
- `references/follow-ups.md` — если предусмотрена серия касаний.
Не создавай пустые или неиспользуемые файлы.
Не создавай README, CHANGELOG, руководство по установке и другую вспомогательную документацию, которая не нужна агенту для выполнения outreach.
# 9. Требования к SKILL.md
YAML frontmatter должен содержать только:
- `name`;
- `description`.
В `description` укажи:
- конкретную компанию или проект;
- конкретную outreach-задачу;
- основные операции скилла;
- ситуации, в которых скилл должен активироваться.
Основной текст скилла должен быть конкретным.
Включи:
- название компании;
- продукт;
- цель кампании;
- целевые сегменты;
- критерии подходящего адресата;
- правила исследования;
- предложение;
- обязательные факты;
- допустимые аргументы;
- запрещённые обещания;
- отправителя;
- стиль;
- основной призыв к действию;
- правила персонализации;
- правила подготовки серии;
- правила follow-up;
- порядок работы с черновиками;
- порядок работы со списком или CRM;
- разрешённые и запрещённые действия;
- обязательную проверку качества.
Не оставляй в готовом скилле абстрактные плейсхолдеры:
- `{название компании}`;
- `{продукт}`;
- `{отправитель}`;
- `{ссылка}`;
- `{призыв к действию}`.
Если критичный параметр не определён, вернись к интервью.
Пиши инструкции в повелительной форме или инфинитиве.
Держи SKILL.md компактным. Подробные проектные сведения и чек-листы вынеси в `references/`.
Явно укажи, когда скилл должен читать каждый reference-файл.
# 10. Обязательная логика проектного скилла
Независимо от проекта зафиксируй следующие защитные правила.
## Исследование
Перед письмом:
- проверить компанию;
- проверить продукт;
- проверить получателя;
- проверить должность;
- определить тип адреса;
- найти конкретную причину обращения;
- подтвердить используемые факты;
- отделить факты от предположений.
Не выдумывать имена, должности, продукты, кейсы, цифры и контакты.
## Персонализация
Писать письмо заново под конкретного адресата.
Не использовать массовый шаблон с механической подстановкой переменных.
Сделать подтверждённый контекст адресата причиной обращения.
Не использовать чувствительные или сомнительно полученные персональные сведения.
## Первое письмо
В первых двух-трёх предложениях сделать понятными:
- отправителя;
- цель обращения;
- причину выбора адресата.
Использовать один основной аргумент и один понятный следующий шаг, если проектный бриф не требует другого.
Не использовать:
- искусственные `Re:` или `Fwd:`;
- ложную срочность;
- давление;
- неподтверждённые обещания;
- вводящую в заблуждение тему;
- фальшивое знакомство;
- выдуманную рекомендацию.
## Разнообразие серии
Сравнивать между собой:
- темы;
- первые предложения;
- аргументы;
- композицию;
- порядок абзацев;
- призывы к действию;
- финальные формулировки.
Различия должны вытекать из контекста адресата, а не из механической замены синонимов.
Если после удаления имён и названий письма выглядят взаимозаменяемыми, переписать их с другой логикой.
Обязательные факты, юридические формулировки, ссылки и подпись могут повторяться.
## Черновики
Создавать черновик только по прямой просьбе.
Проверять:
- аккаунт;
- отправителя;
- адресата;
- тему;
- текст;
- ссылки;
- вложения;
- подпись.
После создания убедиться, что черновик сохранён.
Не считать создание черновика разрешением на отправку.
## Отправка
Отправлять письмо только после отдельной прямой команды, относящейся к конкретному письму или явно определённой группе писем.
Просьба:
- написать письмо;
- улучшить текст;
- подготовить серию;
- создать черновик;
не является разрешением на отправку.
Перед отправкой повторно проверить все поля.
Не расширять список адресатов самостоятельно.
## CRM и таблицы
Не изменять базу, статусы, комментарии и даты follow-up без прямого разрешения.
Если изменение разрешено:
1. Проверить текущие значения.
2. Изменить только согласованные поля.
3. Проверить результат.
4. Сообщить, что именно изменено.
# 11. Формат работы будущего скилла
Если пользователь просит исследовать адресата и написать письмо, скилл должен возвращать:
1. Адресата и тип контакта.
2. Использованные источники.
3. Подтверждённую причину обращения.
4. Основной аргумент.
5. Тему.
6. Полный текст письма.
7. Неподтверждённые сведения и риски.
8. Результат проверки качества.
Если пользователь просит серию, дополнительно возвращать результат проверки разнообразия.
Если пользователь просит только текст, не создавать черновик и не выполнять внешних действий.
Если пользователь просит черновик, создать именно черновик и проверить его сохранение.
Если нужный почтовый или CRM-инструмент недоступен, подготовить результат для ручного переноса и честно сообщить, какое действие не выполнено.
# 12. Проверка готового скилла
После создания:
1. Запусти структурную валидацию.
2. Проверь YAML.
3. Убедись, что нет незаполненных плейсхолдеров.
4. Убедись, что скилл относится к конкретной компании и кампании.
5. Убедись, что в нём сохранены все подтверждённые требования пользователя.
6. Убедись, что он не содержит придуманных фактов.
7. Убедись, что разрешения на текст, черновик, отправку и изменение базы разделены.
8. Выполни безопасный тест без внешних изменений:
- исследование одного тестового или согласованного адресата;
- подготовка одного письма;
- проверка результата по чек-листу.
9. Не создавать реальный черновик, не отправлять письмо и не изменять базу во время теста без отдельной просьбы.
Покажи пользователю тестовый результат и предложи скорректировать правила скилла, если письмо не соответствует ожиданиям.
# 13. Финальный отчёт
После завершения сообщи:
- какой скилл создан;
- для какой компании и кампании;
- где он находится;
- какие файлы созданы;
- какие источники использованы;
- какие функции включены;
- какие действия требуют подтверждения;
- выполнена ли валидация;
- выполнен ли безопасный тест;
- остались ли неподтверждённые данные.
# 14. Начало работы
Сейчас не создавай скилл и не показывай весь список будущих вопросов.
Если в текущем сообщении уже есть файлы или ссылки, сначала изучи их.
Затем задай пользователю только первый вопрос:
«Для какой компании или проекта создаём outreach-скилл? Кратко расскажите о компании и продукте либо пришлите файл, презентацию или ссылку с описанием».
Используй скилл Outreach.
Компания: {Компания}
Сайт: {Сайт}
Исходный сегмент: {Сегмент}
Цель аутрича: {Продажа / партнёрство / приглашение / PR / исследование}
Найденные контакты: {Email / телефоны / социальные сети}
Наше предложение: {Что предлагаем}
Задача:
1. Проверь официальный сайт и доступные открытые источники.
2. Определи реальные продукты, услуги и направления компании.
3. Найди релевантный сценарий для нашего предложения.
4. Найди подходящий email.
5. Если найдено контактное лицо, укажи имя, роль и источник.
6. Сформулируй конкретный персональный повод.
7. Отметь риски, неподтверждённые данные и причины не писать.
8. Предложи одно основное направление обращения.
9. Дополнительные гипотезы оставь во внутренней стратегии.
Не пиши письмо.
Верни структурированный результат для CRM.
Ничего не отправляй и не меняй в Gmail.
На основе анализа компании подготовь строку рабочей CRM.
Поля:
1. Компания.
2. Сайт.
3. Сегмент.
4. Цель обращения.
5. Предложение.
6. Выбранный email.
7. Почему выбран этот email.
8. Контактное лицо.
9. Должность.
10. Надёжность контакта.
11. Источник контакта.
12. Продукты или направления.
13. Персональный повод.
14. Гипотеза пользы.
15. Риски.
16. Источники анализа.
17. Решение по аутричу.
18. Следующее действие.
Не выдумывай человека, email, должность, кейс или цифры.
Если данные не подтверждены, напиши это прямо.
Используй скилл Outreach и чек-лист.
Напиши первое письмо для компании {Компания}.
Данные:
Отправитель: {Имя и роль}
Получатель: {Email}
Контактное лицо: {Имя или «не подтверждено»}
Роль контакта: {Роль}
Цель обращения: {Цель}
Предложение: {Что предлагаем}
Персональный повод: {Почему пишем}
Гипотеза пользы: {Почему это может быть актуально}
Срок: {Дата, если есть}
Основная ссылка: {URL}
Требования:
1. Отправитель представляется сразу после приветствия.
2. В первых двух или трёх предложениях понятна цель.
3. Используй один подтверждённый персональный повод.
4. Не выдумывай выгоды, цифры и кейсы.
5. Используй одну внешнюю ссылку.
6. Не добавляй вложения.
7. Не добавляй лишние каналы связи.
8. Не заканчивай вопросом «интересно ли вам».
9. Не спрашивай, кому передать письмо.
10. Предложи одно простое следующее действие.
11. Разреши ответить на письмо как альтернативу.
12. Добавь мягкий способ отказаться.
13. Не используй общий шаблон.
Верни:
1. Тему.
2. Полный текст.
3. Короткую самопроверку.
Ничего не отправляй.
Используй скилл Outreach.
Подготовь {N} писем по строкам CRM.
Общими могут оставаться:
1. Подтверждённые факты предложения.
2. Основная ссылка.
3. Обязательные условия.
4. Подпись.
5. Способ отказаться.
В каждом письме меняй:
1. Тему.
2. Первую фразу после представления.
3. Порядок абзацев.
4. Формулировку предложения.
5. Персональный аргумент.
6. CTA.
7. Длину.
8. Интонацию.
После подготовки сравни всю серию.
Удали названия компаний, продуктов и имена.
Если два текста выглядят взаимозаменяемыми, перепиши один из них.
Ничего не отправляй и не создавай в Gmail.
Проверь письмо как редактор холодного аутрича.
Определи:
1. Понятна ли цель в начале.
2. Представляется ли отправитель сразу.
3. Есть ли конкретный повод.
4. Подтверждён ли повод источником.
5. Не повторяет ли письмо соседние тексты.
6. Нет ли абстрактных комплиментов.
7. Нет ли одинаковых конструкций.
8. Не отвечает ли письмо на незаданный вопрос.
9. Понятно ли следующее действие.
10. Нет ли лишнего вопроса в конце.
11. Осталась ли одна внешняя ссылка.
12. Нет ли вложений и трекинга.
13. Не продублирован ли текст.
14. Можно ли отправить письмо другой компании после замены названия.
Верни:
1. Обязательные исправления.
2. Возможные улучшения.
3. Переписанную версию целиком.
Используй скилл Outreach.
Создай Gmail-черновик.
НЕ ОТПРАВЛЯЙ.
From:
{Имя отправителя} <{Email отправителя}>
To:
{Email получателя}
Subject:
{Тема}
Body:
{Полный текст}
Перед сохранением проверь:
1. From выбран правильно.
2. В To один получатель.
3. CC и BCC пустые.
4. Тема не изменилась.
5. Текст не продублирован.
6. Внешняя ссылка одна.
7. Вложений нет.
8. Подпись правильная.
Закрой письмо через «Сохранить и закрыть».
Найди черновик в списке и сообщи результат.
Не нажимай «Отправить».
Поставь указанные Gmail-черновики в запланированную отправку.
Дата: {Дата}
Начало: {Время}
Интервал: {Количество минут}
Ограничения:
1. Не менять получателей.
2. Не менять темы.
3. Не менять тексты.
4. Не отправлять сейчас.
5. После каждого действия проверять папку «Запланированные».
Верни таблицу:
Компания | Email | Дата | Время
Я открыл вкладку Gmail «Запланированные».
Исправь тексты указанных писем по обновлённым правилам.
Ограничения:
1. НЕ ОТПРАВЛЯЙ.
2. Время не меняй.
3. Дату не меняй.
4. Получателей не меняй.
5. Темы не меняй.
6. Разрешено менять только тело письма.
7. После каждой правки проверь папку «Запланированные».
8. Убедись, что исходные дата и время сохранены.
В процессе аутрича обнаружена ошибка:
{Описание ошибки}
Обнови локальный скилл Outreach и его чек-лист.
Требования:
1. Не добавляй готовый шаблон письма.
2. Сформулируй универсальный принцип.
3. Добавь проверку, которая обнаруживает ошибку.
4. Если проблема относится к серии, добавь проверку всей партии.
5. Сохрани запрет на отправку без подтверждения.
6. Опиши операционное действие после обнаружения ошибки.
После обновления покажи:
1. Какое правило добавлено.
2. Где оно записано.
3. Как оно проверяется.
4. Что Codex должен делать при нарушении.
Перед созданием Gmail-черновика проверьте:
Re: и Fwd:.Перед созданием черновиков проверьте:
| Ошибка | Как выглядит | Что делать |
|---|---|---|
| Письмо отвечает на незаданный вопрос | Автор сразу объясняет детали, хотя адресат ещё не принял предложение | Вернуть цель обращения в начало |
| Все письма похожи | Повторяются первые фразы и порядок абзацев | Сравнить всю партию и переписать похожие тексты |
| Отправитель появляется поздно | Получатель долго не понимает, кто пишет | Представиться сразу после приветствия |
| В финале лишний вопрос | Адресату предлагают подтвердить интерес вместо действия | Дать простой следующий шаг |
| Слишком много ссылок | В письме есть сайт, календарь, презентация и мессенджер | Оставить один основной переход |
| Текст продублирован | Письмо содержит две копии | Проверить приветствие, середину и подпись |
| Тест спама уже испорчен | Пользователь вручную обучил фильтр | Использовать новый контрольный адрес |
| CRM расходится с Gmail | В таблице осталась старая версия | Синхронизировать после каждой партии |
| Отказ не зафиксирован | Компания снова получает письмо | Поставить флаг Не писать |
| Команда слишком широкая | Codex меняет тему, время или получателя | Явно перечислить разрешённые поля |
Эта методология использовалась в анонимном проекте с базой технологических компаний.
Нужно было проверить продукты, найти контакты, сформулировать поводы, подготовить разные приглашения и создать Gmail-черновики.
Первые письма оказались слишком похожими. Они повторяли один порядок аргументов и звучали так, словно получатель уже попросил подробную консультацию.
После этого процесс изменили:
Главный вывод кейса не связан с тематикой писем.
AI быстро масштабирует структуру задачи. Если структура плохая, ошибки тоже масштабируются.
| Статус | Что означает |
|---|---|
Не готово | Исследование не завершено |
Нужен контакт | Компания подходит, но получатель не найден |
Готово к письму | Данные собраны |
Черновик | Письмо создано в Gmail |
На проверке | Нужна редактура человека |
Запланировано | Установлена дата отправки |
Отправлено | Письмо ушло |
Ответил | Получен ответ |
Повторное касание | Нужен follow-up |
Отказ | Получатель отказался |
Не писать | Новые контакты запрещены |
Ошибка адреса | Письмо не доставлено |
Фраза «больше беспокоить не буду» должна иметь реальное последствие.
После отказа Codex должен:
Не писать = Да.Не писать.Codex полезен в аутриче не потому, что умеет нажимать кнопку отправки.
Его основная ценность находится в исследовании и подготовке.
Он может проверить компанию, найти контакт, заполнить CRM, написать черновик, сравнить письма и поддерживать порядок в Gmail.
Для этого ему нужны понятные границы, рабочая таблица, локальный скилл, небольшие партии и отдельное разрешение на каждое опасное действие.
Без такой системы AI быстро производит одинаковые письма и масштабирует ошибки.
При нормальной организации Codex снимает большую часть рутины, а человек сохраняет за собой цель, тон, спорные решения и ответственность за коммуникацию.