ТЗ на сайт услуг: что согласовать до начала разработки

Фраза «нужен сайт с заявками» допускает разные толкования. Заказчик может ожидать новые страницы и сохранённые обращения, а исполнитель — макет и кнопку, открывающую почту. Чтобы не выяснять разницу после разработки, заранее зафиксируйте состав страниц, владельцев материалов, путь обращения и наблюдаемые критерии сдачи.

Техническое задание не обязано предписывать стек или содержать проектную документацию на каждую интеграцию. Его задача — дать заказчику и исполнителю одинаковое представление о первой версии сайта и вынести неизвестные условия в список решений.

Опишите задачу сайта и состав первой версии

Начните не с платформы, а с цепочки:

кто приходит → какую услугу ищет → что должен понять → какое действие совершить → кто получает обращение.

Для учебного сервиса обслуживания оборудования цепочка выглядит так: представитель компании ищет диагностику → открывает состав и ограничения услуги → понимает, подходит ли она для обсуждения → оставляет контакт → обращение получает назначенный ответственный. Сайт не обещает рост продаж, не рассчитывает точную цену и не назначает время выезда автоматически.

Различайте три вида проекта. Для нового сайта нужно согласовать всю первую структуру. При переработке — ещё определить, какие адреса, материалы и подключения сохраняются. При ограниченной доработке самостоятельным этапом может быть одна страница или форма: полная переделка не обязательна, если меньший объём решает задачу.

В первую версию внесите конкретные страницы, формы, шаблоны и согласованный перенос. Интернет-магазин, кабинет, реклама, постоянный выпуск материалов, калькулятор и CRM не входят автоматически. Каждое неизвестное условие оформите вопросом: «Нужно ли создавать карточку CRM? Ответственный — владелец продаж; решение — до оценки подключения». Молчание стороны не считается согласием.

Если вам нужна реализация согласованного объёма, Switch On AI предлагает разработку и доработку сайта для бизнеса: структура, страницы, форма, поисковая основа и передача определяются требованиями конкретного проекта.

Составьте карту страниц и повторяющихся шаблонов

Страница — самостоятельный адрес с конкретной ролью и содержанием. Шаблон — повторно используемый каркас. Несколько услуг могут использовать один шаблон, но каждая страница всё равно требует своего описания, ограничений, материалов и следующего шага. Готовность каркаса не доказывает готовность всех страниц.

Для каждой страницы укажите рабочий адрес, место в меню, источник материалов, следующий переход и форму или контакт. Спорные дубли услуг соберите в один список и решите до разработки, нужны ли отдельные страницы.

Для действующего сайта добавьте к карте прежний адрес, сохраняемые материалы и одно решение: «оставить», «обновить» или «перенаправить». Это входные данные для будущего переноса, а не инструкция миграции. Не назначайте отдельный URL каждой услуге только ради количества страниц: самостоятельная страница нужна, когда у неё есть отдельная задача и содержательная разница.

Назначьте ответственных за тексты, изображения и факты

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

В реестре используйте однозначные состояния: «нет», «черновик», «согласовано». Момент предоставления каждого материала стороны определяют вместе; универсальный срок здесь не нужен.

Карту и прототип можно начать с временным содержанием, если оно явно помечено. Перед выпуском нужно отдельно сверить наполнение с реестром. Макетная подпись, результат учебного примера или AI-иллюстрация не становятся фактом компании. Если фотография не разрешена, оставьте её в состоянии «нет», а не заменяйте чужим кейсом.

Опишите поведение страниц на телефоне и с клавиатуры

Формулировка «сайт должен быть удобным и современным» не задаёт проверяемого результата. Согласуйте нужные размеры экранов и браузеры с учётом посетителей, затем опишите последовательность действий на конкретном шаблоне и реальном содержании.

Для формы зафиксируйте пять состояний: исходное, фокус, отправка, успех и ошибка. После исправимой ошибки посетитель должен иметь возможность повторить действие без ненужной потери уже введённого — точное поведение закрепите в требованиях.

Скорость задавайте отдельной будущей приёмкой: назовите страницы, метод, среду, устройство или профиль подключения и допустимые условия. Выбор WordPress, Next.js или другой основы сам по себе не подтверждает скорость.

Распишите форму от ввода до сохранения и уведомления

Сначала составьте словарь полей для выбранного процесса. Ниже — пример, а не обязательный набор для любого сайта.

Разделите результаты маршрута:

1. R1 — серверная проверка: сервер проверил поля и применимые согласия.
2. R2 — подтверждённая запись: хранилище подтвердило запись и вернуло номер обращения.
3. R3 — уведомление: выбранный канал отдельно сообщил результат доставки.
4. R4 — CRM: карточка создана или обновлена только тогда, когда CRM включена в объём и подтвердила операцию.

Для учебной модели обращение принято, только если серверная проверка успешна и запись подтверждена: accepted = server_validation_ok AND storage_write_confirmed. Доставка уведомления и создание карточки CRM в этот результат не входят. Если хранилище отказало, номер и сообщение об успешном принятии не показывают. Если запись уже подтверждена, последующая ошибка уведомления не отменяет принятие.

Отдельно задайте поведение при пустом контакте, отказе сохранения, точном повторе события и недоступности уведомления. Способ формирования идентификатора, срок его уникальности, число попыток и ответственного за ошибку согласуют в проекте. Универсального правила дедупликации нет: новое обращение того же контакта может быть новой задачей.

В собственном ТЗ Switch On AI от 8 сентября 2026 года подтверждённая запись обращения отделена от последующей доставки в Telegram. Это позволяет независимо оценивать принятие и уведомление. Опубликованный материал про собственный сайт Switch On AI описывает реализованный проект: обращения сохраняются в базе, а уведомления отправляются отдельным процессом. Новая отправка формы для этой статьи не выполнялась; пример не устанавливает обязательный стек для читателя.

Если форма запускает отдельный процесс между системами, используйте шаблон ТЗ на автоматизацию процесса. Подробный путь обращения от сайта до ответственного в CRM стоит проектировать отдельно: сайт, уведомление и CRM имеют разные результаты.

Согласуйте адреса, поисковую подготовку и события аналитики

Для каждой страницы задайте один основной адрес, решение по прежним полезным URL, метаданные, внутренние переходы и проверку опубликованной версии. Отдельно пометьте страницы для поиска и служебные страницы.

Поручите исполнителю проверить применимые robots, noindex, sitemap, canonical и видимую разметку. Это разные механизмы: например, ограничение обхода не равнозначно запрету индексирования, а наличие sitemap не гарантирует попадание страницы в индекс. Официальное руководство Google также не обещает индексацию или первое место за выполнение рекомендаций.

Для аналитики опишите не только название события, но и точку срабатывания, владельца доступа и проверку с тестовыми данными.

Условия включения аналитики и состав передаваемых данных согласуйте отдельно. Не передавайте в событие содержимое контакта и обращения и не помещайте его в публичные снимки. Наличие счётчика на странице ещё не доказывает корректное измерение.

Укажите, кто обновляет сайт и владеет доступами

До выбора платформы перечислите обычные операции редактора: изменить описание услуги, заменить изображение, добавить материал. Для каждой операции назовите роль, проверку перед выпуском и случаи, когда нужна помощь разработчика.

Передача разработки не отменяет условия сторонних продуктов. Резервное копирование, восстановление, обновления и сопровождение тоже не включаются автоматически: укажите ответственного, состав копии, способ проверки восстановления и отдельно согласованные условия реакции.

Сравнивайте платформы по этим операциям, доступам, функциям и сопровождению. Нельзя объявить WordPress или Next.js лучшим, безопасным, бесплатным либо более быстрым без контекста конкретного проекта.

Свяжите требования с проверками, этапами и изменениями

Присвойте каждому существенному требованию понятный идентификатор. Рядом укажите исходные данные, действие, ожидаемый результат, подтверждение и принимающую роль. Так формулировка «форма работает» превращается в будущую проверку.

Результаты этапов удобно связывать последовательно: карта страниц → согласованный шаблон → материалы и рабочая версия → опубликованная версия и передача. Макет или локальная сборка подтверждают только свой этап; они не доказывают публикацию и доставку обращений.

В шапке ТЗ запишите версию, согласующего и нерешённые зависимости. Изменение объёма проходит отдельное решение: сначала оценивают влияние новой страницы, языка, формы, калькулятора или CRM, затем добавляют работу в согласованный состав.

Пример строки журнала: «Версия 1.2 — предложена вторая форма; владелец изменения — заказчик; влияние на шаблон, хранение, аналитику и приёмку оценивает исполнитель; до согласования форма не входит в первую версию».

Перед сдачей заранее определите перечень передачи: опубликованные страницы, исходники и материалы в договорном объёме, доступы, инструкции, известные замечания и ответственных. Это условия будущей сдачи, а не заявление, что сайт уже проверен.

Учебный фрагмент ТЗ для сайта услуг

EX-W01. Учебный пример на вымышленных данных, проверки не выполнялись. Это фрагмент задания, не внедрение и не выполненная проверка.

Входные сведения. Сервис обслуживания оборудования заказывает сайт: обзор услуг, отдельную страницу диагностики и контакты. Посетитель должен понять состав диагностики и оставить контакт. CRM в первой версии не согласована. Учебная модель предусматривает сохранение обращения на стороне сайта и отдельное уведомление ответственному.

При составлении задания стороны должны согласовать карту и переход от обзора к услуге; назначить контакт обязательным, а комментарий необязательным; отдельно определить форматы и документы; считать запись с номером точкой принятия; проверять уведомление как следующий независимый результат; внести обычный и ошибочные пути в будущую приёмку.

Учебное правило точного повтора можно записать как new_record = event_id_not_seen. Оно действует только внутри EX-W01 и не является универсальной схемой дедупликации. Новое обращение того же контакта с новым идентификатором не отбрасывается автоматически.

Исключения первой версии: CRM, онлайн-оплата, кабинет и автоматическое назначение цены не входят. Ошибка сохранения и ошибка уведомления имеют разные результаты. Новое обращение того же контакта не считается точным повтором события без отдельного правила.

Нерешённые условия: конкретное хранилище и канал уведомления; допустимые форматы контакта; тексты согласий и состав данных; способ формирования и срок уникальности идентификатора; число попыток; ответственный за ошибки; размещение; резервные копии; проверка восстановления и поддержка.

Выход примера — готовые требования W-01—W-03 и план будущей приёмки. Он не подтверждает выполненные тесты, запуск сайта, подключение CRM или рост заявок. Как и в собственном проекте Switch On AI, хранение и уведомление здесь разделены, но конкретные технологии проекта читателя выбирают после согласования.

Если нужен новый сайт услуг или переработка действующего, подготовьте перечень услуг, адрес текущего сайта, примеры подтверждённых материалов и обезличенное описание маршрута обращения. Со Switch On AI можно обсудить состав вашего сайта и критерии результата. Не передавайте через открытую форму пароли, токены, клиентские базы и другие закрытые данные.