Как написать ТЗ на сайт для клиники

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

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

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

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

Объём зависит от проекта. Для лендинга одной услуги хватает двух страниц текста. Для сайта многопрофильного медцентра с онлайн-записью, кабинетом пациента и интеграцией в медицинскую CRM документ выходит на десять и больше страниц, и это нормально.

Раздел 1. Бизнес-задача и целевое действие

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

Кажется формальностью. На деле именно здесь отсеивается половина лишней работы, потому что каждый спорный блок дальше проверяется одним вопросом: он приближает человека к целевому действию или просто занимает экран, который тот всё равно пролистает, пока ищет кнопку записи.

Сюда же пишется, откуда придёт трафик. Сайт под контекстную рекламу и сайт под поиск строятся по-разному: первый требует посадочных под конкретные объявления, второй требует структуры под запросы пациентов.

Раздел 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 году.