Главное за минуту
- ТЗ отвечает не на вопрос «какой сайт нужен», а «какой результат должен получить бизнес».
- Каждая форма описывается полями, маршрутом в CRM, UTM-метками и уведомлениями.
- Критерии приемки проверяют на тестовых данных, а не по словам подрядчика.
- Неопределенные формулировки «современно» и «удобно» заменяют сценариями и измеримыми условиями.
01
Когда пример ТЗ превращается в рабочий документ
Шаблон из интернета полезен только как каркас. Для корпоративного сайта в нем должны появиться конкретные решения: какие услуги продвигаем, откуда приходит лид, кому он назначается в CRM и что увидит менеджер.
Начните с одного маршрута: посетитель приходит из рекламы на страницу услуги, оставляет заявку, получает сообщение, а отдел продаж — карточку лида с источником и UTM. Если этот путь нельзя проверить по ТЗ, документ еще не готов к оценке.
Отдельно зафиксируйте границы проекта: что переносится со старого сайта, кто готовит тексты, какие доступы предоставляет заказчик и что не входит в смету.
02
Карта требований
Таблица связывает бизнес-задачу, страницу, действие пользователя и проверяемый результат.
03
Из чего состоит ТЗ на корпоративный сайт
Не описывайте сайт списком экранов. Сначала закрепите цель и целевые действия, затем состав разделов, контент, функциональность и интеграции. Для каждого пункта укажите владельца решения: маркетинг, продажи, контент или разработка.
Дизайн фиксируйте через прототипы и сценарии: что пользователь должен найти, сравнить или отправить. Это точнее, чем требование «сделать современно».
Цели
Заявки на услуги, обращения партнеров, поиск контактов филиалов.
Структура
Главная, услуги, отрасли, кейсы, о компании, контакты, политика.
Функции
Формы, поиск, фильтры, карта, мультирегиональность — если нужна.
Контент
Источник материалов, формат миграции, ответственный и срок подготовки.
04
Проверьте формулировки до передачи подрядчику
Большинство рисков появляется в словах, которые можно понять по-разному. Задача маркетолога — заменить оценочные требования наблюдаемыми действиями и условиями. Тогда разработчик оценивает объем, а не угадывает ожидание.
Особенно внимательно проверьте формы, мобильную версию, доступы к CRM и правила обработки персональных данных.
| Неудачно | Проверяемо |
|---|---|
| Удобная форма | Поля: имя, телефон, комментарий; обязательны имя и телефон |
| Заявка идет в CRM | Создается лид с UTM, страницей, формой и ответственным |
| Быстрый сайт | Целевые страницы проверяются в согласованном сервисе после запуска |
| Адаптивный дизайн | Сценарии формы и меню проверяются на согласованном списке устройств |
05
Пример требований к заявке и CRM
Для каждой формы используйте отдельный идентификатор и понятное назначение: «Запросить расчет», «Получить консультацию», «Стать партнером». Это позволит сегментировать обращения и видеть эффективность страниц.
Передавайте в CRM не только контакт. Без источника, UTM-меток, URL страницы и названия формы маркетинг не сможет сопоставить рекламный расход с лидами.
Готовое сообщение
Формулировка задачи разработчику
Цель: получать заявки с раздела «Услуги» в CRM для обработки отделом продаж.
Форма: поля «Имя», «Телефон», «Комментарий»; обязательны имя и телефон. До отправки пользователь принимает политику обработки данных.
Передача: создать лид в CRM. Передавать имя, телефон, комментарий, URL страницы, название формы, utm_source, utm_medium, utm_campaign, utm_content, utm_term.
Критерий приемки: отправить тестовую заявку с UTM. В CRM появляется один лид с корректными полями, ответственным и источником; посетитель видит сообщение об успешной отправке.
Документация: после запуска передать инструкцию по настройке и перечень использованных обработчиков.
06
Как принять корпоративный сайт по ТЗ
Приемка проходит по сценариям, а не по общему впечатлению. Подготовьте тестовые данные заранее: номера телефонов, UTM-метки, почтовые адреса и доступы к тестовой CRM. Результат каждого шага фиксируйте в таблице замечаний с приоритетом и сроком исправления.
- 1
Проверьте структуру. Все согласованные страницы открываются, меню и хлебные крошки ведут в нужные разделы.
- 2
Пройдите формы. Проверьте обязательные поля, сообщения об ошибках, согласие с политикой и защиту от повторной отправки.
- 3
Сверьте CRM. Отправьте заявки из разных форм с UTM и сопоставьте поля карточки лида с ТЗ.
- 4
Проверьте аналитику. Убедитесь, что цели фиксируют успешную отправку, а не только клик по кнопке.
- 5
Зафиксируйте передачу. Получите доступы, резервную копию, инструкцию редактора и список внешних сервисов.
07
Четыре признака неполного ТЗ
Если один из пунктов отсутствует, оценка почти наверняка изменится после старта. Это не обязательно ошибка подрядчика: часто бизнес-правило просто не было описано и его невозможно было включить в первоначальный объем.
Проведите короткий аудит документа до договора — он занимает меньше времени, чем согласование допработ в середине проекта.
Контент
Не определено, кто и в каком виде передает тексты, фото и документы.
CRM
Не указаны воронка, ответственный, поля карточки и доступ для настройки.
Метрика
Нет списка целей, счетчиков и событий, которые нужны маркетингу.
Приемка
Нет тестовых сценариев, сроков исправления и состава передачи проекта.
08
Что приложить к техническому заданию
ТЗ не обязано содержать весь контент и финальный дизайн, но должно ссылаться на материалы, без которых нельзя оценить объем. Приложения лучше нумеровать и фиксировать их версии в договоре или постановке задачи.
Для 1С-Битрикс полезно указать редакцию продукта, требования к ролям редакторов и порядок обновлений. Технические возможности платформы сверяйте с официальной документацией 1С-Битрикс, а не с предположениями.
Если нужны примеры
Для реальных решений и форматов подачи используйте опубликованные кейсы ICONICA: https://iconica.site/portfolio/.
Цели и KPI; карта страниц; прототипы или референсы; перечень форм и полей; CRM-воронка и доступы; UTM и цели аналитики; список контента; сценарии приемки; порядок передачи доступов
FAQ
Частые вопросы
Можно ли начать разработку без полного ТЗ?
Можно начать с этапа аналитики и прототипирования, но не стоит утверждать фиксированную смету всего проекта без согласованных границ.
Кто должен писать ТЗ?
Бизнес формулирует цели и правила, маркетинг — лидогенерацию и аналитику, подрядчик помогает проверить реализуемость и декомпозицию.
Нужны ли макеты всех страниц?
Для оценки важнее прототипы ключевых типов страниц и правила для типовых блоков. Финальные макеты можно делать отдельным этапом.
Как оформить изменения после старта?
Фиксируйте изменение отдельной задачей: причина, новый сценарий, затронутые разделы, оценка, срок и решение о приоритете.
