45
11 мин
Лендинг часто начинают обсуждать с дизайна: какие цвета использовать, где поставить кнопку, сколько экранов сделать, какие анимации добавить. Но для бизнеса это не первый вопрос. Сначала важно понять, что именно должна решить страница, какие заявки она должна приносить, какие данные попадут в CRM и где заканчивается зона ответственности подрядчика. Если это не зафиксировать до старта, проект быстро превращается в цепочку правок, доплат и взаимных ожиданий.
Короткий вывод. ТЗ на лендинг — это не формальность и не документ «для галочки». Это рабочий инструмент управления проектом: он фиксирует цель, структуру, функционал, критерии приемки, состав работ и ограничения. Поэтому разработка лендинга по ТЗ обычно проходит спокойнее: клиент понимает, что получит на выходе, команда не угадывает требования, а бюджет не расползается из-за решений, которые «вспомнили» уже после дизайна.
Кому полезна эта статья
- собственнику, который хочет заказать лендинг и заранее понимать, за что платит;
- маркетологу, которому нужно связать страницу, рекламу, CRM и аналитику;
- руководителю продаж, который хочет получать не просто заявки, а понятные обращения с нужными полями;
- команде клиента, если важно пройти этапы создания лендинга без хаоса, переделок и спорных зон ответственности.
1. Почему ТЗ — это не формальность, а защита бюджета
Плохой сценарий обычно начинается без злого умысла. Клиент говорит: «Нам нужен лендинг под рекламу». Подрядчик отвечает: «Сделаем красиво». Все согласны, работа стартует. Через неделю выясняется, что нужна не одна форма, а три; не просто кнопка, а квиз; не базовая заявка, а интеграция с CRM; не общий текст, а разные офферы под два сегмента аудитории. Формально речь всё ещё о лендинге, но по объёму это уже другой проект.
Именно здесь ТЗ работает как финансовый ограничитель. Оно заранее отвечает на вопросы: что входит в проект, что не входит, какие материалы предоставляет клиент, сколько итераций согласования предусмотрено, какие функции считаются обязательными, а какие пойдут отдельной оценкой. Если нужна разработка одностраничного сайта под конкретную бизнес-задачу, это должно быть видно не только в коммерческом предложении, но и в техническом задании.
Хорошее ТЗ не убивает гибкость. Наоборот, оно отделяет управляемые изменения от хаоса. Если после анализа выясняется, что нужно добавить новый блок, команда понимает, почему он появился, как влияет на сроки и нужно ли пересматривать бюджет. Если же в ТЗ нет границ, каждая доработка превращается в спор: это «мелкая правка» или новый функционал?
2. Что должно быть понятно до первого макета
До дизайна важно согласовать не пиксели, а логику результата. Лендинг создаётся не ради страницы как таковой, а ради бизнес-действия: заявки, звонка, записи, расчёта, брони, покупки, скачивания прайса или перехода в мессенджер. Поэтому сначала мы фиксируем задачу, а уже потом переходим к структуре и визуалу.
Если говорить коротко, прозрачная разработка сайта начинается с пяти базовых ответов:
1. какой продукт или услугу продвигаем;
2. кому именно продаём и что для этой аудитории важно;
3. какое действие считаем главным на лендинге;
4. откуда придёт трафик и какие обещания уже есть в рекламе;
5. как будем принимать результат: по структуре, функционалу, адаптиву, скорости, формам, аналитике и юридическим блокам.
Такой подход близок к логике ГОСТ 34.602‑2020: в техническом задании должны быть цели, назначение, требования к системе, состав работ, порядок разработки и правила приемки. Для коммерческого лендинга мы не переносим ГОСТ буквально, но берём главный принцип: сначала описываем, зачем создаётся система, потом — что она должна делать и как её проверять.
3. Наш процесс: 5 шагов от брифа до подписания
Ниже — как работает агентство по созданию сайтов, если задача не просто «собрать красивую страницу», а сделать лендинг, который можно нормально запустить в рекламу, подключить к аналитике и поддерживать без ручного хаоса.
Шаг 1. Бриф: фиксируем бизнес-задачу
На первом шаге мы собираем исходную информацию: что продаёт компания, кому продаёт, какие каналы уже работают, какая средняя стоимость сделки, какие возражения есть у клиентов, что уже пробовали в рекламе и почему текущий сайт не устраивает. Бриф нужен не для архива. Это точка, где команда перестаёт гадать и начинает собирать лендинг вокруг реальной задачи.
Что получает клиент: структурированный список вопросов, карту исходных данных и понимание, какой информации не хватает для старта. Если данных нет, мы сразу обозначаем, что придётся проверить на этапе анализа: конкурентов, спрос, аудиторию, рекламные связки или текущую аналитику.
Шаг 2. Анализ: проверяем рынок, аудиторию и риски
После брифа мы смотрим, насколько задача подтверждается рынком. Для этого изучаем конкурентов, спрос в Wordstat, рекламные объявления, посадочные страницы, отзывы, типовые возражения и сценарии принятия решения. Для ниш с длинным циклом сделки, например для недвижимости, ремонта или B2B-услуг, важно учитывать не только первый клик, но и путь клиента до обращения. Поэтому для таких проектов полезно заранее смотреть отраслевые решения для строительных компаний и похожие механики лидогенерации.
Что получает клиент: не абстрактное «мы всё изучили», а выводы, которые влияют на структуру. Например: какой оффер поставить на первый экран, какой блок доверия нужен до формы, нужно ли показывать цены, какие возражения закрывать отзывами, кейсами или гарантиями, какие события нужно передавать в Яндекс.Метрику.
Шаг 3. Черновик ТЗ: превращаем выводы в структуру
На этом этапе появляется первая версия документа. В ней мы описываем структуру лендинга, блоки, формы, поля заявок, сценарии клика, требования к адаптиву, юридические элементы, интеграции, аналитику и материалы, которые нужны от клиента. Черновик не должен быть идеальным сразу. Его задача — вынести все важные решения из переписок и созвонов в один документ.
Если в проекте планируется реклама, ТЗ сразу связывается с будущей аналитикой: какие цели настраиваем, какие формы отслеживаем, что отправляем в CRM, какие UTM-метки должны сохраняться, какие события считаем обязательными. Без этого сайт может выглядеть готовым, но для маркетинга он будет «слепым».
Шаг 4. Ревью: обсуждаем спорные места до разработки
Ревью — это не формальное согласование в стиле «посмотрите документ». Мы отдельно проходим зоны, где чаще всего появляются доплаты: дополнительные экраны, сложные формы, квизы, интеграции, калькуляторы, мультилендинги, анимации, редактируемость блоков, тексты, изображения, перенос контента и тестирование.
На этом шаге удобно открыть подробный чек-лист и проверить, не упустили ли базовые вещи. Например, если нужен более широкий контроль состава работ, можно свериться с материалом что включить в ТЗ на лендинг, чтобы не слить бюджет — там собраны обязательные пункты, которые часто забывают на старте.
Что получает клиент: список уточнений и решений. Например: «квиз включаем в первый релиз», «онлайн-оплату не делаем на старте», «тексты пишет агентство», «фотографии предоставляет клиент», «дополнительные языковые версии оцениваются отдельно».
Шаг 5. Подписание: фиксируем границы проекта
Финальный шаг — утверждение ТЗ. Здесь важно не просто поставить подпись, а зафиксировать версию документа, дату, состав работ, критерии приемки и порядок изменений. Если после подписания появляется новая задача, она не теряется в чате, а оформляется как изменение: оценивается по срокам, бюджету и влиянию на результат.
В проектах, где нужен быстрый запуск, такая фиксация особенно важна. Например, в кейсе запуска сайта застройщика за 7 дней скорость была возможна не потому, что этапы пропустили, а потому что задача, структура и приоритеты были собраны в понятный порядок до активной разработки.
4. Что получает клиент на каждом этапе
| Этап | Что делает команда | Что получает клиент |
| Бриф | Собираем цели, продукт, аудиторию, каналы трафика, ограничения, ожидания по срокам и бюджету. | Понимание исходной задачи и список данных, которые нужны для старта. |
| Анализ | Изучаем конкурентов, спрос, офферы, рекламные связки, текущий сайт, аналитику и риски. | Выводы, которые объясняют будущую структуру лендинга. |
| Черновик ТЗ | Собираем документ: блоки, формы, функционал, адаптив, интеграции, контент, юридические элементы. | Первую версию ТЗ, где уже видно, что входит в проект. |
| Ревью | Проходим спорные зоны, уточняем детали, убираем разночтения, отмечаем отдельные оценки. | Согласованный состав работ и список решений до разработки. |
| Подписание | Фиксируем финальную версию, критерии приемки, порядок изменений и ответственность сторон. | Защиту бюджета, сроков и границ проекта. |
5. Как фиксируем границы проекта
Самая частая причина переплат — не «дорогой подрядчик», а размытая зона проекта. На старте кажется, что все всё понимают. Но потом появляется вопрос: кто пишет тексты? Кто подбирает изображения? Кто настраивает домен? Кто подключает политику конфиденциальности? Кто проверяет формы на мобильном? Кто отвечает за передачу заявок в CRM?
Чтобы этого не было, в ТЗ мы разделяем работы на четыре категории.
| Категория | Что фиксируем | Зачем это нужно |
| Входит в проект | Блоки, формы, адаптив, базовая аналитика, тестирование, публикация, конкретные интеграции. | Клиент видит, за что платит, команда понимает обязательный объём. |
| Не входит в проект | Например, копирайтинг, фотосъёмка, CRM-настройка отдела продаж, SEO-продвижение, рекламные кампании. | Снижает риск ожиданий, которые не были учтены в смете. |
| Нужно от клиента | Логотип, реквизиты, фотографии, документы, доступы, прайс, контакты, информация о продукте. | Проект не стоит из-за отсутствующих материалов. |
| Оценивается отдельно | Дополнительные языки, личный кабинет, сложный калькулятор, новые разделы, нестандартные интеграции. | Новые идеи не ломают основной бюджет и сроки. |
Такой блок кажется простым, но именно он чаще всего экономит деньги. Если границы не прописаны, каждая новая идея воспринимается как часть «обычного лендинга». Если прописаны, команда может спокойно сказать: это хорошая идея, но она меняет объём работ, давайте оценим её отдельно.
6. Пример подписанного ТЗ с комментариями
Ниже — упрощённый пример фрагмента ТЗ. Это не полный документ, а схема, которая показывает, как должны выглядеть зафиксированные требования. В реальном проекте каждый пункт раскрывается подробнее и согласуется с клиентом.
| Фрагмент ТЗ | Как формулировать | Комментарий |
| Цель проекта | Создать лендинг для продвижения услуги ремонта квартир в Санкт-Петербурге. Главное целевое действие — заявка на расчёт стоимости. | Цель измеримая: понятно, какой результат должна поддерживать страница. |
| Структура | Первый экран, преимущества, виды работ, калькулятор, этапы, кейсы, отзывы, FAQ, форма заявки, контакты. | Состав блоков зафиксирован, поэтому новые экраны не появляются незаметно. |
| Формы | Форма содержит имя, телефон, тип объекта, комментарий. После отправки данные уходят в CRM и на почту. | Понятно, какие поля нужны и куда должна попадать заявка. |
| Адаптив | Корректная работа на ширинах 360, 390, 768, 1024 и 1440 px. Все формы и кнопки доступны на мобильном. | Критерий приемки не абстрактный, а проверяемый. |
| Правки | В проект включено 2 раунда правок по дизайну и 1 раунд правок после тестового наполнения. | Ограничивает бесконечные итерации и защищает сроки. |
| Подписание | ТЗ утверждается клиентом в редакции от 00.00.0000. Изменения после утверждения оформляются отдельным списком работ. | Фиксирует версию документа и порядок изменений. |
7. Где чаще всего возникают споры
Даже если все участники хотят нормальный результат, споры появляются в одних и тех же местах. Их лучше закрывать заранее, а не после первого макета.
| Спорная зона | Как звучит проблема | Как закрываем в ТЗ |
| Тексты | «Мы думали, вы сами всё напишете». | Отдельно фиксируем, кто пишет тексты, кто согласует смысл и кто отвечает за фактуру. |
| Изображения | «Поставьте красивые фото, у нас нет материалов». | Прописываем источники изображений: клиентские фото, стоки, иллюстрации, генерация, отдельная фотосъёмка. |
| Формы | «Добавьте ещё пару полей и квиз». | Фиксируем количество форм, поля, логику отправки, валидацию и сценарии после заявки. |
| Интеграции | «Нужно, чтобы всё попадало в CRM». | Указываем конкретную CRM, поля, ответственных за доступы, тестовые заявки и сценарии ошибок. |
| Аналитика | «Почему мы не видим заявки в отчёте?». | Фиксируем цели, события, UTM-метки, формы и порядок проверки перед запуском рекламы. |
| Правки | «Давайте ещё немного поменяем структуру». | Разделяем правки в рамках согласованной структуры и изменения состава работ. |
8. Как ТЗ защищает от доплат и переплат
ТЗ не гарантирует, что в проекте вообще не появятся изменения. Такое почти невозможно, особенно если бизнес быстро уточняет оффер, тестирует рекламу или получает новые вводные от отдела продаж. Но ТЗ делает изменения управляемыми.
Защита работает в трёх направлениях.
1. Состав работ виден до оплаты. Клиент понимает, какие блоки, функции и проверки включены в стоимость.
2. Изменения оцениваются отдельно. Если появляется новая задача, она не смешивается с исходным объёмом.
3. Приемка становится проверяемой. Команда сдаёт не «красивый макет», а страницу, которая соответствует зафиксированным требованиям.
Для клиента это снижает риск переплаты. Для агентства — риск делать бесконечные доработки без понятной рамки. Для проекта — риск запуститься позже, чем планировали, потому что часть требований всплыла слишком поздно.
9. Мини-чек-лист перед подписанием ТЗ
Перед тем как подписывать ТЗ, стоит пройти короткую проверку. Если хотя бы на несколько вопросов нет ответа, документ лучше доработать до старта.
- понятна главная цель лендинга и целевое действие;
- описана аудитория и её основные возражения;
- зафиксирована структура блоков;
- понятно, кто готовит тексты, изображения и документы;
- описаны формы, поля, сценарии отправки и сообщения после заявки;
- перечислены интеграции с CRM, почтой, мессенджерами, оплатой и аналитикой;
- есть требования к мобильной версии;
- есть юридические блоки: политика, согласия, оферта, если нужна;
- зафиксированы сроки, этапы согласования и количество раундов правок;
- понятен порядок изменений после подписания.
Вывод: сильное ТЗ экономит деньги ещё до разработки
Хорошее ТЗ не делает проект бюрократичным. Оно делает его предсказуемым. Клиент заранее видит, что получит на каждом этапе. Команда понимает, что именно нужно спроектировать, разработать, подключить и проверить. А спорные зоны не остаются «между строк», где потом появляются доплаты, задержки и взаимное раздражение.
Если лендинг должен работать как инструмент продаж, начинать стоит не с фразы «сделайте красиво», а с понятного процесса: бриф, анализ, черновик, ревью и подписание. Тогда страница создаётся не на догадках, а на согласованной задаче, измеримых критериях и прозрачных границах проекта.
