Як написати ТЗ на сайт для клініки

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

Що таке ТЗ на сайт клініки

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

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

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

Розділ 1. Бізнес-задача й цільова дія

Перший розділ ТЗ відповідає на питання, навіщо клініці сайт і що людина має на ньому зробити. Цільова дія формулюється однією фразою: записатися на прийом онлайн, залишити заявку на консультацію, зателефонувати. Усі подальші рішення перевіряються цією фразою.

Здається формальністю. Насправді саме тут відсіюється половина зайвої роботи, бо кожен спірний блок далі перевіряється одним питанням: він наближає людину до цільової дії чи просто займає екран, який вона все одно проґортає, поки шукає кнопку запису. Якщо цільова дія це запис, то блок «наша історія з 2008 року» опускається нижче, а кнопка запису живе в шапці на всіх сторінках. Якщо цільова дія це дзвінок, бо клініка працює зі старшою аудиторією, номер має бути найпомітнішим елементом, а не сірим текстом у кутку.

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

Розділ 2. Структура сторінок

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

Найдорожча помилка формулювання виглядає так: «сторінки послуг». Скільки їх, п'ять чи двадцять п'ять? Підрядник закладе п'ять, клініка чекатиме двадцять п'ять, і на прийманні почнеться неприємна розмова. Пишіть поіменно. Навіть якщо перелік вийде на півсторінки й виглядатиме занудно, це та занудність, яка потім економить обом сторонам тиждень зʼясувань і кілька неприємних листів про те, хто що мав на увазі в момент підписання.

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

Розділ 3. Функціонал

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

Це найдорожчий розділ документа, і саме тут найчастіше ховається різниця між кошторисом на $750 і кошторисом на $2500. Один рядок «інтеграція з медичною CRM» може означати передачу заявки вебхуком за дві години роботи, а може означати двосторонню синхронізацію розкладу лікарів, і поки в ТЗ не написано, що саме, обидві сторони уявляють різне.

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

Розділ 4. Контент: хто дає тексти й фото

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

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

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

Розділ 5. Дизайн

Розділ дизайну містить логотип і фірмові кольори, приклади сайтів, які подобаються замовнику, і приклади, які категорично не підходять. Другий список корисніший за перший: він відсікає напрямок швидше, ніж десять референсів «нам подобається щось таке».

Фіксуйте кількість ітерацій. Дві правки макета входять у ціну, третя й далі оплачуються окремо. Без цього рядка процес затягується на місяці, бо в клініці зазвичай не одна людина з думкою про дизайн, і кожна нова людина відкриває обговорення заново.

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

Розділ 6. Технічні вимоги й SEO-база

Технічний розділ описує платформу, адаптивність, швидкість завантаження, мета-теги, мікророзмітку, налаштування аналітики й підключення до Search Console. Для медичного сайту сюди ж входить сторінка політики конфіденційності та згода на обробку персональних даних у формі запису.

Мінімум, який варто прописати цифрами: адаптив від 320 пікселів, час завантаження головної до трьох секунд на мобільному, підключені Google Analytics і Search Console, згенерований sitemap, мікророзмітка організації та FAQ. Усе це перевіряється на прийманні за десять хвилин, і саме тому має бути в документі.

Що не варто вимагати в ТЗ на розробку: конкретні позиції у пошуку. Розробка дає технічну базу, а позиції це вже окрема робота з просування з іншим бюджетом і горизонтом у місяці.

Розділ 7. Терміни, приймання й гарантія

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

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

Готовий кістяк ТЗ

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

1. Про клініку. Назва, напрями, міста присутності й адреса поточного сайту, якщо він уже існує і його треба враховувати при переносі контенту.
2. Задача й цільова дія. Одна фраза про те, що людина має зробити на сайті, і другий рядок про те, звідки прийде трафік — пошук, контекст чи соцмережі.
3. Структура. Поіменний перелік усіх сторінок із точною кількістю сторінок послуг, бо саме вона найсильніше рухає кошторис.
4. Функціонал. Запис, форми, інтеграції, мовні версії, і окремою колонкою поділ на першу чергу та другу, щоб частину роботи можна було свідомо відкласти без перегляду всього документа.
5. Контент. Хто дає прайс, фотографії лікарів і робіт, дані про освіту, до якого числа, і що відбувається з термінами, якщо матеріали затримались.
6. Дизайн. Логотип і фірмові кольори, два-три референси «так», обовʼязково два «ні», а також кількість безкоштовних ітерацій правок макета.
7. Техніка. Адаптив від 320 пікселів, цільова швидкість завантаження, підключення аналітики й Search Console, мікророзмітка, а для медичного сайту ще й політика конфіденційності зі згодою у формі.
8. Терміни й приймання. Етапи з датами, строк на подання зауважень одним списком і гарантійний період із чіткою межею між виправленням помилок і новими доробками.

Помилки, які трапляються найчастіше

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

1. «Сучасний дизайн». Оцінний прикметник, який неможливо ані виконати, ані перевірити на прийманні, тому він завжди читається обома сторонами по-різному.
2. Функціонал одним словом. «Онлайн-запис» без деталей чесно коштує і дві години, і два тижні — залежно від того, що саме уявляв собі той, хто писав документ.
3. Немає дати на матеріали. Проєкт зупиняється на порожніх сторінках, формально винних немає, і зрив дедлайну списують на підрядника.
4. Нескінченні правки. Кількість ітерацій не зафіксована, тож кожна нова людина в клініці відкриває обговорення макета заново.
5. Позиції у пошуку в ТЗ на розробку. Це інша послуга з іншим бюджетом і горизонтом у місяці, тому в документі на розробку вона створює лише хибні очікування.

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