ТЗ копирайтеру: как заказать статью, полезную клиенту и бизнесу

Начните с результата чтения, а не с количества знаков

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

Хорошее ТЗ копирайтеру помогает автору принять редакционные решения. Что объяснить подробно, какой термин расшифровать, где привести пример и что оставить за границами материала. Оно также даёт заказчику основу для приёмки: замечания относятся к понятным требованиям, а не к изменившемуся впечатлению от текста.

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

Опишите читателя через ситуацию и знания

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

Добавьте исходные знания. Например, читатель понимает, что CRM хранит клиентов, но не знает, чем отличается лид от сделки. Значит, термин придётся объяснить в момент первого использования, а программные подробности не должны занимать место практических действий.

В руководстве GOV.UK по потребностям пользователей работа с содержанием связывается с тем, что человеку нужно сделать. Для коммерческого блога полезно применять этот принцип как редакционный приём: описывать задачу читателя, а не только интересы компании. Это не требование к российскому бизнес-сайту, а подход к планированию объяснения.

Запишите результат одним предложением. Например: после статьи маркетолог сможет составить список форм сайта и проверить, какие сведения передаются в CRM. Если результат невозможно описать без слов «узнает всё о», тему стоит сузить до самостоятельного вопроса.

Поставьте границы, чтобы статья не повторяла соседние

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

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

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

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

Передайте автору факты и правила их проверки

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

Отделите проверяемые факты от редакционных рекомендаций. Функция доступна на определённом тарифе — это утверждение о продукте, которое нужно подтвердить. Предложение сначала испытать интеграцию на тестовой группе — рабочая рекомендация, которую автор объясняет задачей и последствиями возможной ошибки. Смешение этих типов делает текст либо чрезмерно уверенным, либо бесполезно осторожным.

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

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

План должен вести читателя к решению

Попросите план до полного текста, если тема сложная или границы ещё неясны. У каждого раздела сформулируйте вопрос, на который он отвечает. Заголовок «Преимущества решения» без конкретного предмета легко заполняется общими словами; «Что проверить в карточке CRM после отправки формы» задаёт понятную работу автору.

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

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

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

Как задать SEO без механического повторения ключей

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

В основных рекомендациях Google говорится об использовании слов, которыми люди ищут содержание, в понятных местах страницы, включая заголовки. Это не требование вставлять запрос в каждый раздел. Для ТЗ достаточно естественного употребления там, где формулировка точно описывает предмет.

Задайте отдельные H1, SEO title и description. H1 обозначает тему страницы, title помогает представить её в поиске, description кратко раскрывает содержание. Не копируйте описание в первый абзац: вступление должно начать объяснение ситуации и задачи.

Не выдавайте желаемый объём за правило поисковой системы. В руководстве Google о полезном содержании прямо отвергается представление о предпочтительном числе слов. Диапазон знаков в вашем ТЗ — редакционный ориентир, который помогает планировать глубину, а не универсальный фактор ранжирования.

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

Опишите качество языка через наблюдаемые признаки

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

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

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

Не используйте процент «человечности» или результат детектора ИИ как доказательство качества. Проверяйте сам материал: точность, ясность, полезность и самостоятельное объяснение. Если применялись инструменты генерации, они не снимают с редактора обязанности проверить факты и весь итоговый текст.

Как выглядит рабочая карточка задания

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

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

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

Как принимать статью в два прохода

Сначала прочитайте текст как будущий клиент. Понятно ли, зачем открывать страницу, объяснены ли решения, можно ли выполнить следующий шаг? Отмечайте места, где читатель вынужден угадывать термин или возвращаться назад. Не начинайте с подсчёта ключей: формально правильная семантика не исправит отсутствие ответа.

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

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

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

Что зафиксировать перед передачей задания

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

Для обсуждения статьи или раздела блога с ШТАБ ИТ подготовьте тему и задачу клиента, на которую должна отвечать страница. Сначала согласуйте полезный результат и содержание, затем объём и оформление. Тогда текст можно будет принять по тому, что он объясняет и помогает сделать, а не по впечатлению от длины.