Технічне завдання на розробку сайту: шаблон, приклад заповнення і типові помилки

Технічне завдання на розробку сайту (ТЗ) — це документ, у якому замовник і виконавець фіксують, що саме буде зроблено і як перевірити результат: цілі сайту, аудиторію, перелік сторінок, функції, інтеграції, вимоги до контенту, SEO та аналітики, критерії приймання і терміни. Для корпоративного сайту зазвичай достатньо 5–15 сторінок тексту, якщо в них немає загальних фраз.

Нижче є шаблон ТЗ із 13 розділів, який можна скопіювати й заповнити, умовний приклад для B2B-сайту, правила для критеріїв приймання і помилки, через які проєкт дорожчає вже після підписання договору.

Навіщо бізнесу технічне завдання на сайт

ТЗ захищає бюджет і терміни. Без нього кожна сторона розуміє «сайт під ключ» по-своєму, і суперечка починається в день здачі.

Типова ситуація: замовник чекає калькулятор вартості, фільтр по каталогу та англійську версію, а студія порахувала п'ять сторінок із формою зворотного зв'язку. Обидві сторони чесні, просто ніхто не записав очікування. ТЗ перетворює «хочемо сучасний сайт» на перелік, який можна оцінити в годинах і перевірити по пунктах.

Бриф і ТЗ часто плутають. Бриф описує бізнес-задачу: хто ви, що продаєте, кому, які сайти вам подобаються. ТЗ описує рішення: які сторінки, які поля у формі, куди йде заявка, яка швидкість завантаження прийнятна. Бриф зазвичай заповнює замовник, а ТЗ пишуть разом зі студією після одного-двох інтерв'ю.

Є ще одна причина мати документ: так можна порівнювати комерційні пропозиції. Якщо три студії оцінюють однаковий текст, різниця в ціні пояснюється обсягом і якістю роботи, а не тим, що кожна уявила свій проєкт. Як ставити підрядникам правильні питання, ми розібрали в матеріалі як вибрати веб-студію.

Структура технічного завдання на сайт: 13 розділів

Повне ТЗ складається з 13 блоків, від загальної інформації до порядку внесення змін. Для лендінгу частину розділів можна об'єднати, для корпоративного сайту чи інтернет-магазину пропускати їх не варто.

Шаблон ТЗ на розробку сайту: скопіюйте і заповніть

Шаблон нижче можна вставити в Google Docs і відповісти на кожен пункт конкретно: цифрами, назвами сервісів, посиланнями. Якщо відповіді немає, так і пишіть: «не знаємо, потрібна рекомендація студії». Це чесніше, ніж вигадувати.

1. Загальна інформація

• Назва компанії, сфера діяльності, коротко про продукт чи послуги.
• Поточний сайт (якщо є) і домен, на якому працюватиме новий.
• Хто ухвалює рішення і хто ще погоджує макети.
• Бюджет у вигляді діапазону і бажана дата запуску. Чи вона жорстка: виставка, сезон, старт реклами.

2. Цілі сайту і показники успіху

• Головна дія відвідувача: заявка, дзвінок, покупка, запис, завантаження прайсу.
• Другорядні дії: підписка, перехід у месенджер, перегляд кейсів.
• Цільові показники: скільки заявок на місяць, яка конверсія, який трафік.
• Що не працює на поточному сайті і чому ви вирішили робити новий.

3. Цільова аудиторія

• 2–3 сегменти клієнтів: хто вони, яку задачу вирішують, що зупиняє їх від покупки.
• Хто ухвалює рішення в B2B: власник, закупівельник, технічний спеціаліст.
• Частка мобільного трафіку (з Google Analytics, якщо дані є).
• Звідки прийдуть відвідувачі: Google, реклама, соцмережі, email, офлайн.

4. Структура сайту

• Перелік сторінок деревом: головна, послуги (скільки), кейси, блог, про компанію, контакти, політика конфіденційності.
• Кількість унікальних шаблонів. Наприклад, одна сторінка послуги як шаблон для 12 послуг.
• Мови сайту і чи перекладаються всі сторінки.

5. Функціонал

• Форми: які поля, які з них обов'язкові, що бачить людина після відправки.
• Каталог, фільтри, пошук, калькулятор, бронювання, особистий кабінет, якщо вони потрібні.
• Що команда редагуватиме сама в CMS: тексти, ціни, кейси, вакансії, банери.
• Ролі в адмінці: хто що може змінювати.

6. Інтеграції

• CRM (яка саме), куди потрапляє заявка і з якими полями.
• Телефонія, онлайн-чат, месенджери, email-розсилка.
• Оплата, доставка, облікова система (1С, BAS), якщо сайт продає.
• Для кожної інтеграції: напрямок даних (тільки з сайту в CRM чи двосторонній обмін) і частота синхронізації.

7. Контент

• Хто пише тексти: ви, студія чи копірайтер, і хто відповідає за точність експертних фактів.
• Фото і відео: власні, нова зйомка чи стокові.
• Обсяг на старті: скільки сторінок послуг, кейсів, статей.
• Міграція зі старого сайту: що переносимо, а що видаляємо.
• Дедлайн передачі матеріалів.

8. Дизайн

• Брендбук або логотип, кольори, шрифти; чи потрібне оновлення стилю.
• 3–5 референсів із поясненням, що саме подобається: навігація, типографіка, подача кейсів.
• Що категорично не підходить.
• Кількість ітерацій правок на кожному етапі.

9. SEO-вимоги

• Людино-зрозумілі URL і логічна структура адрес.
• Редагування title, description і H1 для кожної сторінки.
• Автоматичні sitemap.xml і robots.txt, canonical, hreflang для мовних версій.
• Мікророзмітка schema.org: Organization, Service, Article, FAQPage, BreadcrumbList.
• Карта 301-редиректів, якщо новий сайт замінює старий.

10. Аналітика

• GA4, Google Tag Manager, Google Search Console, за потреби Meta Pixel.
• Події: відправка кожної форми, клік по телефону і месенджерах, завантаження файлів.
• Передача UTM-міток і джерела трафіку в заявку та CRM.
• Власник акаунтів аналітики: ваша компанія, а не підрядник.

11. Технічні вимоги

• Домен і хостинг оформлені на замовника, SSL, резервні копії.
• Цільові значення швидкості (Core Web Vitals).
• Підтримувані браузери і пристрої, мінімальна ширина екрана.
• Доступність (WCAG 2.1), захист форм від спаму, банер згоди на cookies.

12. Критерії приймання

• Чек-лист перевірки по кожному розділу ТЗ.
• На яких пристроях і в яких браузерах тестуємо.
• Хто з боку замовника перевіряє і за скільки днів дає зворотний зв'язок.
• Що вважається помилкою, а що новою задачею.

13. Терміни, етапи і зміни

• Етапи з датами і результатом кожного: прототип, дизайн, розробка, запуск.
• Графік оплат, прив'язаний до етапів.
• Процедура змін: як оцінюється нова задача, хто її погоджує, як зсуваються терміни.
• Гарантійний період і умови підтримки після запуску.

Приклад заповнення ТЗ для корпоративного сайту

Нижче умовний приклад для вигаданої компанії, яка проєктує та монтує промислову вентиляцію. Він показує рівень конкретики, до якого варто прагнути.

У жодному рядку немає слів «зручний», «сучасний» чи «швидкий» без цифри поруч. Саме так ТЗ стає робочим інструментом, а не формальністю для договору.

Як прописати критерії приймання, щоб не сперечатися на здачі

Критерій приймання має бути перевірним: дві різні людини, прочитавши його, мають дійти однакового висновку, виконано чи ні. Якщо це неможливо, пункт переписують.

Значення LCP і CLS відповідають порогу «добре» з рекомендацій Google щодо Core Web Vitals. Частину пунктів ви зможете перевірити самостійно: мета-теги в генераторі мета-тегів, карту сайту в генераторі sitemap, правила індексації в генераторі robots.txt. Для перевірки аналітики створіть тестове посилання в UTM-генераторі, відправте з нього заявку і подивіться, чи дійшли мітки до CRM. Як правильно називати джерела і кампанії, є в повному гіді з UTM-міток.

Типові помилки в технічному завданні

Більшість помилок ТЗ не технічні: документ або занадто загальний, або описує функції без зв'язку з метою бізнесу.

1. Скопійоване ТЗ з інтернету. Шаблон корисний як чек-лист, але «модуль новин» і «форум» потрапляють у проєкт лише тому, що були в чужому документі.
2. «Як у конкурента» без пояснень. Посилання на чужий сайт нічого не каже, поки ви не напишете, що саме там працює: структура кейсів, калькулятор, подача цін.
3. Немає відповідального за контент. Дизайн готовий, верстка готова, а тексти послуг пишуться третій місяць. У нашій практиці це найчастіша причина зсуву запуску.
4. Інтеграції одним рядком. «Підключити CRM» може зайняти і годину, і тиждень. Потрібні назва CRM, перелік полів, напрямок обміну і правило для дублів.
5. Забули про міграцію. Новий сайт без карти редиректів втрачає позиції старих сторінок. Якщо у сайту вже є органічний трафік, редиректи описують окремим розділом.
6. Немає процедури змін. Нові ідеї з'являються завжди. Без правила «оцінили, погодили, зсунули дедлайн» кожна правка стає конфліктом.
7. Усе й одразу. Особистий кабінет, програма лояльності і три мови на старті роблять проєкт удвічі довшим. Позначте такі функції як «етап 2» і запускайтеся з тим, що приносить заявки.
8. Доступи не прописані. Якщо ніде не сказано, що домен, хостинг і акаунти аналітики належать вам, зміна підрядника може перетворитися на переговори.

Хто має писати ТЗ і скільки часу це займає

Найкращий результат дає спільна робота: замовник відповідає за бізнес-частину (цілі, аудиторія, контент), студія за технічну (структура, функціонал, SEO, аналітика). Для лендінгу вистачає брифу й однієї зустрічі, для корпоративного сайту етап аналітики зазвичай триває від кількох днів до двох тижнів.

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

Одні студії продають аналітику і ТЗ окремою послугою, інші включають їх у перший етап проєкту. У SEQUENCE розробка корпоративного сайту починається зі стратегії та інформаційної архітектури: ми інтерв'юємо ваших продавців і маркетологів, будуємо структуру навколо запитів клієнтів і погоджуємо прототипи до того, як починаємо малювати дизайн. Сайт на 8–12 сторінок з CMS коштує орієнтовно від 90 000 грн, запуск займає 40–60 днів, а суму ми фіксуємо в договорі. З чого складається ціна різних форматів, ми розібрали в огляді скільки коштує сайт у 2026 році.

ТЗ не замінює живої розмови. Воно фіксує домовленості, але найкращі рішення з'являються, коли студія ставить незручні питання про ваші продажі: де клієнти сумніваються, що питають на першому дзвінку, чому обирають конкурентів.

Підсумок

• ТЗ фіксує, що буде зроблено і як перевірити результат; бриф описує лише бізнес-задачу.
• Беріть 13 розділів шаблону за основу, але викидайте пункти, які не працюють на вашу ціль.
• Кожна вимога має містити цифру, назву сервісу або перевірний критерій.
• Окремо пропишіть інтеграції, міграцію з редиректами, власника доступів і процедуру змін.

Часті запитання

Чим технічне завдання відрізняється від брифу?

Бриф описує бізнес: продукт, аудиторію, конкурентів, побажання до стилю. Технічне завдання описує рішення: перелік сторінок, функції, інтеграції, вимоги до SEO й аналітики, критерії приймання і терміни. Бриф зазвичай заповнює замовник самостійно, а ТЗ складають разом зі студією на основі брифу та інтерв'ю.

Чи можна розробити сайт без технічного завдання?

Можна, якщо це простий лендінг і підрядник працює за детальним брифом та погодженим прототипом. Для корпоративного сайту чи інтернет-магазину відсутність ТЗ майже завжди означає непередбачувані терміни, доплати за «нові» функції та суперечки під час здачі, бо кожна сторона пам'ятає домовленості по-своєму.

Хто має писати технічне завдання на сайт?

Обидві сторони. Замовник знає бізнес, аудиторію і процес продажу, студія знає, як перетворити це на структуру, функції та технічні вимоги. Найпрактичніший варіант: ви заповнюєте бриф і бізнес-розділи шаблону, студія після інтерв'ю дописує технічну частину, а ви погоджуєте фінальну версію перед договором.

Скільки сторінок має бути в ТЗ на сайт?

Для лендінгу вистачає 2–4 сторінок, для корпоративного сайту зазвичай 5–15, для інтернет-магазину з інтеграціями більше. Обсяг не є показником якості: короткий документ із конкретними цифрами та критеріями приймання корисніший за довгий, заповнений загальними фразами на кшталт «сучасний дизайн» чи «зручна навігація», які неможливо перевірити під час здачі.

Чи можна змінювати ТЗ під час розробки?

Так, але за прописаною процедурою: нову вимогу описують, студія оцінює її в годинах і впливі на терміни, ви погоджуєте зміну письмово. Без такого порядку дрібні правки накопичуються і зривають і бюджет, і дату запуску, а наприкінці проєкту ніхто не пам'ятає, що було в початковому обсязі.