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

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

Ты начнешь объяснять на словах, что имел в виду. Подрядчик перепишет. Станет не про то по-другому. И так пять раз, пока один из вас не сдастся: либо ты примешь «ну, сойдет», либо он тихо возненавидит проект и начнет писать по верхам.

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

И вот что я понял за эти годы: между нишами не переносятся ни тексты, ни шаблоны статей. Переносится ровно одна вещь — дисциплина ТЗ. Одни и те же поля, одна привычка сначала описать задачу, потом писать. Поэтому про ТЗ я могу говорить долго и предметно: это буквально та деталь, на которой держится вся система.

Разберу по-честному: как выглядит техническое задание копирайтеру, по которому нельзя написать плохо. Не «подробное» — а про правильные вещи: для кого, зачем и против чего пишем. Пройдем по всем полям с ответом на вопрос «что сломается, если поля нет», отдельно разнесем миф про объем и плотность ключей, свяжем ТЗ с приемкой, разберем типовые ошибки и в конце я отдам копируемый шаблон, который заполняется за 15–20 минут. Погнали.

ТЗ на статью — это не «тема плюс количество знаков плюс ключи», а карта, по которой заказчик и подрядчик сверяют, одну ли статью они видят. Хорошее задание отвечает на три вопроса: для кого пишем, зачем и против чего — чем эта статья отличается от того, что уже в топе. Заполнить все поля — 15–20 минут; пропустить их — месяц переписки и пять переделок. Правки на этапе ТЗ стоят минуты, правки на готовом тексте — дни.

Давай честно про механику. Правка — это не «текст плохой». Правка — это «текст не совпал с картинкой у тебя в голове». А картинка у тебя в голове была всегда, просто ты ее не выгрузил.

Ты держал в уме, что статья — для действующих клиентов, а не для новичков. Что она должна закрывать возражение «дорого», а не рассказывать про историю компании. Что тон — спокойный и экспертный, а не бодрый маркетинговый. Ничего из этого в ТЗ не было. Подрядчик угадал иначе — и оказался виноват в том, что не прочитал твои мысли.

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

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

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

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

Ключевая мысль, которую я хочу, чтобы ты забрал из этого раздела: правки на этапе ТЗ стоят минуты, правки на этапе готового текста стоят дни. Переставить строчку «аудитория: действующие клиенты, а не новички» — это десять секунд. Переписать под нее готовую статью — это заново.

Все, что ты не проговорил в ТЗ, ты будешь проговаривать правками. Выбор только в том, когда: дешево в начале или дорого в конце. Третьего варианта — «проговорить не придется» — не существует. Контекст все равно выйдет наружу. Вопрос лишь, во что он тебе обойдется.

Плохое ТЗ описывает артефакт: тема, знаки, ключи, срок. То есть параметры файла, который ты хочешь получить. Хорошее ТЗ описывает задачу: кого мы хотим сдвинуть, из точки А в точку Б, каким рычагом. Файл — это следствие. Если ты правильно описал задачу, параметры файла подстроятся сами.

Сравни два ТЗ на одну тему.
Первое: «Статья про наш CRM, 6000 знаков, ключ „црм для отдела продаж“». Это описание артефакта. По нему можно написать сто разных статей, и девяносто девять тебе не подойдут.

Второе — то же самое, но описано как задача: «Читатель — руководитель отдела продаж на 5–15 человек, у которого сделки теряются в переписках и он не видит воронку. Он гуглит, потому что чувствует бардак, но еще не выбирает конкретную систему — он на стадии „а мне вообще это надо“. Задача статьи — показать ему цену бардака в деньгах и дать критерии, по которым он поймет, что дозрел. В конце он должен захотеть посмотреть демо, а не закрыть вкладку».

Вот по такому описанию из ста статей подойдут девяносто. Разница — не в объеме текста ТЗ, оба варианта короткие. Разница в том, про что они. Чтобы разница была совсем наглядной, вот она в одной таблице — по одним и тем же вопросам:

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

Отсюда, кстати, простое рабочее правило для проверки собственного ТЗ. Дай его прочитать человеку, который вообще не в контексте — коллеге из другого отдела, — и спроси, для кого эта статья и зачем. Если он не сможет ответить своими словами за десять секунд, значит, и подрядчик не сможет. Значит, ТЗ еще сырое.

Дальше — разбор по полям. Не как формальность и не «чтобы было по ГОСТу», а с ответом на конкретный вопрос: что именно сломается в готовом тексте, если этого поля в задании нет. Это и есть настоящие требования к написанию статьи — не про количество знаков, а про смысл.

Тема — это не заголовок. Тема — это о чем статья одним предложением, плюс главный запрос, под который она пишется, в той формулировке, как его реально вводят живые люди. Не «наш взгляд на автоматизацию продаж», а «как понять, что отделу продаж пора внедрять CRM».

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

Что сломается без поля: подрядчик напишет про то, что ему кажется темой, а не про то, что ищет читатель. Статья будет «около» — вроде и по теме, а мимо реального вопроса.

Самое важное поле и самое часто пропускаемое. Кто конкретно читатель — не «наши клиенты», а живой человек с ролью, контекстом и стадией зрелости. И какую его задачу статья закрывает — по логике Jobs To Be Done: с какой работой он к этой статье «нанимает» текст.

Человек не читает статью ради статьи. Он читает, чтобы что-то понять, решить, выбрать, перестать бояться, укрепиться в уже принятом решении. «Руководитель отдела продаж, сделки теряются, еще не выбирает систему, хочет понять — надо ли ему это вообще» — это аудитория с задачей. «Предприниматели» — это не аудитория, это перепись населения. Между этими двумя формулировками — вся разница между статьей, которая попадает, и статьей, которая вежливо ни о чем.

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

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

Читательский слой: «понял, что бардак в сделках стоит ему N потерянных денег в месяц, и захотел разобраться». Бизнес-слой: «прогрев к демо; статья работает на верх воронки, не на прямую продажу». Если оставить только бизнес-слой, подрядчик начнет продавать в лоб. Если только читательский — статья будет полезной, но не приведет ни к чему для бизнеса.

Что сломается без поля: подрядчик не знает, к чему вести. Статья заканчивается ничем — «вот такие дела, спасибо за внимание, подписывайтесь». Или наоборот, лепит в конце агрессивный призыв купить там, где читатель еще на стадии «а мне вообще это надо», и все ломает одним абзацем.

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

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

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

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

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

Перед тем как писать, нужно посмотреть, что уже стоит в топе по этому запросу, и ответить на один вопрос: чего там нет?

Не «напишем как у них, только лучше и длиннее» — а «вот пять статей в топе, все рассказывают про функции, и ни одна не говорит про то, что внедрение проваливается из-за саботажа менеджеров; вот наш зазор, вот про что напишем мы». Этот разбор — половина ценности всего ТЗ. Он превращает статью из «еще одной такой же» в «единственную, которая закрывает вопрос, висящий у всех и не закрытый никем».

Что сломается без поля: ты вложишься в статью, которая дублирует топ-5. Она не выделится ничем, и ее нечем будет продвигать — она не лучше существующих, просто новее. А «новее» в поиске не работает: чтобы обойти статью, которая уже собрала поведенческие сигналы, надо быть не такой же, а заметно другой и полезнее.

Ключи в ТЗ нужны, но не в роли «вставь эти слова N раз». Ключи — это карта того, какими словами читатель думает про свою проблему, и какие подтемы он ждет увидеть. Основной ключ задает ядро. Дополнительные — это подсказки о смежных вопросах, которые стоит закрыть: если рядом с «црм для отдела продаж» люди ищут «внедрение црм этапы» и «црм для малого бизнеса», значит, эти вопросы живут в голове читателя, и статья, которая их затрагивает, полнее и честнее закрывает тему.

Что сломается, если подать ключи неправильно: если написать «ключ „црм для отдела продаж“ — плотность 3%», подрядчик начнет натягивать фразу на текст, и живой язык умрет. Ключи как норма набивки убивают читаемость и ничего не дают ранжированию, кроме риска попасть под фильтр за переспам. Ключи как карта смысла — наоборот, помогают: подрядчик видит не квоту, а список вопросов, которые надо закрыть.

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

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

Что сломается без поля: подрядчик напишет «по мотивам гугла». Фактуры не будет. Экспертности не будет. Будет гладкий текст ни о чем — и его придется либо принимать таким, либо доливать фактуру правками, что дороже всего, потому что фактура постфактум ломает уже написанную структуру.

Откуда берем факты и числа. Что можно утверждать, а что — нельзя. Какие цифры компания готова назвать публично, а какие под запретом. Если в статье есть «по данным исследования X» — должно быть ясно, какого именно исследования и что оно реально говорит, а не «где-то читал, что рынок растет».

Что сломается без поля: подрядчик пойдет по одному из трех плохих путей. Либо напишет вообще без цифр — тогда текст жидкий и неубедительный. Либо придумает цифры — это прямо опасно, особенно в регулируемых нишах и в B2B, где читатель разбирается лучше автора. Либо навешает непроверяемых «по данным экспертов» и «как показывает практика» — это стыдно и палится сразу. Все три варианта ты потом ловишь на приемке и правишь, хотя мог задать рамку одной строчкой на входе.

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

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

Как звучит текст. Спокойный эксперт или бодрый маркетолог. На «ты» или на «вы». Допустимы ли ирония, профлексика, резкие формулировки — или все строго и нейтрально. Если у компании есть носитель голоса — основатель, чьим голосом идут статьи, — это фиксируется именно тут, и лучше с прямым примером-эталоном: «пиши вот как в этой статье».

Что сломается без поля: получишь текст в тоне, который тебе чужой. И это, поверь, самая мучительная правка из всех — «вроде все по фактам и по структуре, но звучит не как мы». Ее почти невозможно объяснить словами постфактум, потому что тон не раскладывается на пункты. Поэтому тон надо задавать на входе и обязательно образцом, а не прилагательными. «Экспертно, но по-человечески» — это не задание, под это подходит что угодно.

Где публикуется и, значит, по каким правилам живет. Статья на vc.ru, в отраслевом медиа и в собственном блоге — это три разных текста по одному и тому же ТЗ. Разная длина, разный уровень прямоты, разная допустимость саморекламы, разный формат подачи, разный порог входа читателя. На vc можно резко и с матом по делу, в отраслевом издании нужен тон «свой среди своих», в корпоративном блоге — сдержаннее.

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

Явный список того, что запрещено. Слова, которые компания принципиально не использует. Темы, которые нельзя поднимать. Конкуренты, которых нельзя называть. Обещания, которые нельзя давать — особенно в регулируемых нишах, где за лишнее слово прилетает не от клиента, а от закона. Формулировки, от которых тебя лично передергивает.

Что сломается без поля: подрядчик наступит на мину, о существовании которой не знал. И выглядеть это будет как его ошибка, хотя на деле ты просто не предупредил. Табу — это единственное поле, которое дешевле всего заполнить и обиднее всего пропустить: минута на входе против гарантированной переделки и осадка.

Как обе стороны поймут, что работа сдана. Это перевод всех полей выше в проверяемый чек-лист: раскрыта заявленная аудитория и ее задача; выдержан угол; есть фактура от эксперта; закрыт зазор относительно топа; тон соответствует эталону; табу не нарушены; структура на месте; цифры проверяемы. Приемка — это не «нравится / не нравится», это «соответствует ТЗ / не соответствует», пункт за пунктом.

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

Объем ставим последним и намеренно мягко: «ориентир 4000–5000 слов, но если тема закрывается за 3500 качественно — не растягиваем, а если честно нужно 6000 — пишем 6000». Объем — это следствие полноты раскрытия темы, а не самостоятельная цель, под которую подгоняют текст.

Что сломается, если сделать объем целью: подрядчик нальет воды до нужного знака. Ты получишь ровно 5000 знаков, из которых полторы тысячи — вводные обороты, повторы и «важно отметить, что». Формально ТЗ выполнено, фактически статья стала хуже, потому что читатель платит за воду вниманием и уходит.

Вынесу отдельно, потому что это главная ловушка, в которую попадают почти все, кто пишет техническое задание копирайтеру впервые. Объем и плотность ключей кажутся идеальными полями ТЗ: они измеримы. Их видно. По ним удобно проверять и удобно спорить — «тут 4200 знаков, а надо 5000», «ключ вошел два раза, а надо четыре». Именно поэтому люди делают их главными: с ними спокойно, они дают ощущение контроля над процессом, который иначе кажется творческим и неуправляемым.

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

Получается перекос, который я вижу постоянно: ТЗ жестко фиксирует то, что не важно (объем, плотность ключей), и молчит про то, что важно (аудитория, цель, угол, эксперт, зазор относительно топа). А потом все искренне удивляются, почему статья формально по ТЗ, а по сути мимо. Да потому что ТЗ было про не те вещи.

Измеримость — это не то же самое, что важность, это вообще ортогональные штуки. Хорошее ТЗ фиксирует важное, даже если его труднее проверить, а не гоняется за удобством контроля. Контролировать легко объем. Влияет на результат — угол.

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

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

Отсюда прямое правило, которое стоит повесить на стену:

сначала пиши критерии приемки, потом принимай. И критерии эти — не отдельный документ, который надо заводить, а последний раздел того же ТЗ.

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

Отдельно скажу вещь, которую заказчики недооценивают: приемка по ТЗ защищает не только тебя, но и подрядчика. Он может сказать «я сделал ровно то, что в ТЗ» — и это аргумент, а не оправдание. Спор смещается с «мне не нравится» на предметное «в ТЗ было иначе» или «такого в ТЗ вообще не было, это новая вводная». Это честно для обеих сторон и, что важнее, убивает вкусовщину как жанр отношений. А там, где нет вкусовщины, нет и пятой итерации.

Короткий ответ: вдвоем, и роли принципиально разные.

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

Подрядчик формализует: превращает контекст в структуру, добавляет разбор топа и семантику, задает правильные вопросы там, где заказчик недоговорил или сам не осознал, и оформляет все так, чтобы по документу можно было и писать, и потом принимать. Хороший подрядчик не сидит и не ждет готового ТЗ от клиента — он вытаскивает контекст вопросами и собирает бриф на контент сам, а заказчик его утверждает или поправляет. Это, к слову, один из честных маркеров зрелости подрядчика: слабый просит «пришлите ТЗ», сильный говорит «давайте я задам вам пятнадцать вопросов и соберу ТЗ, а вы утвердите».

Ошибка тут взаимная, и в ней-то и живут пять переделок. Заказчик думает: «ТЗ — это работа подрядчика, я же плачу деньги». Подрядчик думает: «пусть заказчик сначала сам напишет, чего он хочет, это его бизнес». В этом зазоре между двумя «пусть он» статьи и рождаются кривыми. ТЗ — это совместный документ по определению, и десять минут разговора на входе экономят месяц переписки на выходе.

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

Соберу в одну кучу то, что вижу чаще всего — считай это списком мин, по которым можно пройти заранее.

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

▸Нет аудитории. «Для предпринимателей», «для нашей ЦА» вместо конкретного человека с ролью и задачей. Текст получается адресованным всем и потому никому. Главный источник пустых, вежливых, никаких статей, которые вроде и без ошибок, а читать невозможно.

▸Нет цели. Непонятно, к чему вести читателя и какая за этим бизнес-задача. Статья либо заканчивается ничем и повисает, либо бьет призывом «купите» невпопад, там, где читатель еще не готов даже думать о покупке.

▸Нет угла. Тема есть, ракурса нет. Получается пересказ учебника, неотличимый от топ-5 по запросу. Продвигать такую статью нечем — она объективно не лучше существующих, а поисковику незачем поднимать копию над оригиналом.

▸«Сделайте красиво / поживее / поэкспертнее». Это вообще не ТЗ, это оценка, вынесенная на вход задачи. «Красиво» — для кого и относительно чего? «Поживее» — это как? Такие формулировки не задают ничего, кроме гарантированной правки, потому что «красиво» у тебя в голове и «красиво» у подрядчика в голове — это два разных «красиво», и совпадут они только случайно, раз из десяти.

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

Забирай, пользуйся. Это не форма ради формы и не бюрократия — это список вопросов, на каждый из которых надо ответить одной-двумя фразами перед стартом. Если на какой-то вопрос ответа нет — это и есть дырка, через которую к тебе придет правка. Так что незаполненное поле — не «пропустим», а красный флаг.

— О чем статья одним предложением:

— Главный запрос в формулировке читателя:

— Кто читатель (роль, контекст, стадия):

— Какую его задачу закрывает статья («нанимает» текст, чтобы...):

— Что читатель должен понять/сделать, дочитав:

— Какая за этим бизнес-задача (воронка, прогрев, продажа):

— Под каким углом заходим (чем отличаемся от учебника):

— От чьего лица повествование:

— Что уже стоит в топе по запросу:

— Чего там НЕТ — наш зазор:

— Основной:

— Дополнительные / смежные подтемы:

— Кто дает фактуру (имя, роль):

— Что именно он должен добавить (цифры, нюансы, грабли):

— Что можно утверждать и откуда:

— Что называть нельзя:

— Каркас смысловых блоков:

— Обязательные элементы (резюме, чек-лист, расчет и т.д.):

— Как звучит (+ пример-эталон, если есть):

— Где публикуется и по каким правилам площадки:

— Чего НЕ делать, каких слов/тем/обещаний избегать:

— По каким пунктам поймем, что сдано:

— Ориентир (не цель):

Заполнение занимает 15–20 минут на статью. Это дорого только на первый взгляд и только пока ты не сравнил с альтернативой. Пять переделок стоят на порядок больше — и времени, и нервов, и, что не восстанавливается, доверия между тобой и подрядчиком.

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

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

➤ТЗ — это работа, которую многие пропускают именно потому, что она невидимая. Написать статью — видно, вот текст, вот результат. Составить ТЗ — не видно, оно как будто «еще не работа», подготовка, которую хочется проскочить поскорее к делу. Поэтому его и проскакивают. Но именно эта невидимая работа на входе определяет, сколько будет видимой переделочной работы на выходе. Пропустить ТЗ — не значит сэкономить время. Значит перенести это время на потом и умножить на количество итераций.

➤И ТЗ не отменяет доверия к подрядчику. Самое подробное задание оставляет сотни микрорешений внутри текста, которые принимает автор по ходу письма: какое слово, какой пример, где пошутить, где нажать. Если ты не доверяешь этим решениям в принципе, никакое ТЗ не поможет — ты будешь переписывать за подрядчиком в любом случае, до последней запятой. ТЗ снимает расхождения по-крупному: для кого, зачем, под каким углом, с какой фактурой. А мелочи внутри — это зона мастерства автора, и ее надо ему отдать, иначе ты платишь за копирайтера, а работаешь копирайтером сам.

Короче. Большинство правок — это выгрузка контекста, который был у тебя в голове с самого начала, но вышел наружу только под давлением плохого драфта. ТЗ — это способ выгрузить его заранее, спокойно и дешево. Не про объем и ключи, а про то, для кого, зачем и против чего пишем. Хорошее ТЗ ты узнаешь по одному признаку: посторонний человек, прочитав его, написал бы примерно ту же статью, что задумал ты.

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

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

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

15–20 минут на статью, если у тебя уже есть шаблон и ты честно отвечаешь на 14 вопросов, а не отписываешься. Это дорого только на первый взгляд. Пять переделок стоят на порядок больше — и по времени, и по нервам, и по доверию между тобой и подрядчиком.

Это одно и то же, просто «бриф» звучит легче, а «ТЗ» — строже. Важно не название, а содержание: если внутри только тема, объем и ключи — это плохой бриф, по нему напишут мимо. Если внутри аудитория, цель, угол, эксперт и зазор относительно топа — это рабочее задание, как его ни назови.

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

Вдвоем. Заказчик дает контекст, которого нет больше нигде: кто клиент, зачем статья, кто внутренний эксперт, что называть нельзя. Подрядчик формализует это в структуру, добивает вопросами и добавляет разбор топа. Хороший подрядчик не ждет готового ТЗ, а сам собирает его вопросами и отдает тебе на утверждение.

Три вещи, которые чаще всего забывают и потом ловят правками: для кого пишем (живой человек с задачей, а не «наша ЦА»), под каким углом заходим (чем отличаемся от топа) и кто внутри компании дает фактуру. Тон и табу — сразу следом. Объем и ключи — в самом конце и мягко, они не про качество.

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

Мы это считаем на входе — например, на своем же ядре собрали 2364 запроса, а после очистки от омонимов, гео-мусора и коммерции осталось 1159 действительно информационных. «Большое ядро» и «рабочее ядро» — это, как правило, две очень разные цифры.

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

👉 Разобрать свое ядро: @vernedohub_bot

Как мы собираем такие системы — на vernedo.ru.

Александр Нефедкин, владелец агентства Vernedo. 15+ лет в контенте и SEO. За плечами — более 100 клиентов в 20+ нишах: от медицины и промышленного B2B до IT, облаков и e-commerce. Мы глубоко разбираемся в бизнесе клиента, поэтому делаем экспертный контент, который двигает выдачу.