ТЗ на разработку B2B-портала или личного кабинета должно фиксировать бизнес-цель, роли пользователей, доступные каждой роли данные, ключевые сценарии, интеграции и критерии приёмки. Цвет каждой кнопки можно определить в дизайне; правила доступа, источники документов и поведение при ошибке нужно согласовать до разработки.
Ниже — структура ТЗ для корпоративного сайта, производителя или B2B-сервиса.
1. Контекст и цель проекта
Начните с короткого описания бизнеса:
- что продаёт компания;
- кому и в каких регионах;
- как устроен цикл сделки;
- откуда сейчас приходят обращения;
- какую роль должен выполнять сайт.
Цель «сделать современно» невозможно проверить. Лучше сформулировать наблюдаемое изменение: упростить запрос коммерческого предложения, объяснить линейку продуктов, подготовить SEO-структуру или сократить ручные консультации по типовым вопросам.
Выберите одну главную цель и несколько вспомогательных. Если сайт одновременно должен продавать, обучать партнёров, обслуживать клиентов и заменять внутреннюю систему, проект следует разделить на этапы.
2. Аудитории и участники решения
В B2B страницу часто изучают несколько ролей. Собственника интересуют риски и экономика, инженера — характеристики, закупщика — условия, пользователя — эксплуатация.
Для каждой роли зафиксируйте:
| Роль | Главный вопрос | Нужный материал | Целевое действие |
|---|---|---|---|
| Руководитель | Почему этому поставщику можно доверять? | Кейсы, цифры, этапы | Запросить обсуждение |
| Инженер | Подходит ли решение по параметрам? | Характеристики, чертежи | Отправить ТЗ |
| Закупщик | Как получить цену и документы? | Условия, сертификаты | Запросить КП |
| Пользователь | Как решение работает? | Инструкции, FAQ | Получить консультацию |
Такой список помогает не сводить сайт к одной универсальной странице.
3. Карта страниц и сценарии
Для каждого раздела укажите задачу и переход. Например, карточка оборудования помогает оценить параметры и ведёт к запросу цены, а отраслевая страница объясняет применимость и ведёт к подбору решения.
Отдельно опишите ключевые сценарии:
- Посетитель находит продукт через поиск.
- Сравнивает характеристики.
- Проверяет документы и опыт.
- Отправляет запрос.
- Получает подтверждение и следующий шаг.
Не ограничивайтесь меню. Важны также фильтры, поиск, связанные материалы, формы и состояния после отправки.
4. Функциональные требования
Разделите требования на обязательные и желательные. Это упростит оценку и поможет сохранить бюджет.
Примеры функций:
- каталог и фильтры;
- поиск по сайту;
- загрузка файлов к заявке;
- калькулятор или конфигуратор;
- личный кабинет;
- несколько языков;
- управление контентом;
- интеграция с CRM;
- уведомления в Telegram или email;
- передача UTM-меток;
- карта объектов или дилеров.
Для каждой интеграции укажите систему, доступность API, владельца доступа и ожидаемый обмен данными. Формулировка «интегрировать с 1С» слишком широкая: нужно перечислить конкретные сущности и направление синхронизации.
5. Контент и ответственность
Для личного кабинета отдельно перечислите данные, которые видит клиент: договоры, счета, заказы, обращения, статусы и файлы. Для каждого объекта укажите систему-источник, допустимые действия, правила доступа и поведение при недоступности CRM или 1С. Это отделяет B2B-портал от обычного корпоративного сайта и позволяет оценить backend и интеграции.
Большая часть задержек возникает не из-за кода, а из-за материалов. Составьте таблицу контента заранее:
| Материал | Формат | Кто предоставляет | Срок |
|---|---|---|---|
| Описания продуктов | Документ или таблица | Продуктовый специалист | До прототипа |
| Характеристики | Структурированная таблица | Инженер | До разработки каталога |
| Фотографии | Оригиналы | Маркетинг | До дизайна |
| Сертификаты | Отдел качества | До наполнения | |
| Кейсы | Факты и разрешения | Продажи | До подготовки текстов |
Если тексты создаёт подрядчик, заказчик всё равно должен предоставить факты и согласовать техническую точность.
6. SEO до разработки
SEO-требования нельзя добавлять после готового дизайна. До прототипа определите:
- основные группы поисковых запросов;
- посадочные страницы;
- правила URL;
- требования к title, description и заголовкам;
- перелинковку;
- индексируемые и служебные страницы;
- правила переноса старых адресов.
При замене существующего сайта подготовьте карту редиректов и сохраните страницы, которые уже получают трафик. Для этого используйте чек-лист технического SEO при переносе.
7. Нефункциональные требования
Зафиксируйте требования, которые определяют качество системы:
- поддерживаемые устройства и браузеры;
- доступность с клавиатуры;
- ожидаемая скорость;
- защита форм от спама;
- резервное копирование;
- журналирование ошибок;
- права пользователей;
- правила хранения персональных данных.
Не записывайте абстрактное «сайт должен быть быстрым». Укажите способ проверки и тестовые страницы.
8. Критерии приёмки
Приёмка должна проверять результат, а не личное ощущение. Примеры критериев:
- все страницы из утверждённой карты созданы;
- формы доставляют заявки в согласованные каналы;
- обязательные поля и ошибки работают;
- данные передаются в CRM по заданной схеме;
- редиректы соответствуют карте;
- контент корректно отображается на согласованных разрешениях;
- подключена аналитика событий;
- заказчику переданы доступы и инструкция.
Определите количество циклов правок и порядок фиксации новых требований. Новая функция после согласования прототипа — это изменение объёма, а не обычная правка.
9. Этапы и точки согласования
Практичная последовательность:
- Исследование и сбор требований.
- Карта сайта.
- Прототип ключевых страниц.
- Дизайн-концепция.
- Полный дизайн.
- Разработка и интеграции.
- Наполнение.
- Тестирование и перенос.
- Запуск и наблюдение.
На каждом этапе укажите ответственного и срок обратной связи. Без этого даже подробное ТЗ не защитит график.
Что отправить подрядчику для первой оценки
Для начального расчёта достаточно пяти материалов:
- ссылка на текущий сайт;
- краткое описание продукта и клиента;
- желаемый список разделов;
- обязательные функции и интеграции;
- ориентир по сроку.
Подробное ТЗ можно сформировать после диагностики. Для оценки состава работ используйте разбор сметы на разработку сайта. Если вам требуется готовый шаблон для дилеров и оптовиков с матрицей цен, ЭДО и синхронизацией номенклатуры, изучите ТЗ на разработку оптового B2B-портала с 1С.
Ограничение и источник
ТЗ не заменяет проверку прототипа и тестирование реальных сценариев. Требования «быстро», «современно» или «безопасно» должны быть переведены в проверяемые критерии. Для доступности интерфейса используйте W3C WCAG.
Разработка по вашему ТЗ
Требования к заказам, счетам, документам и ролям можно использовать для оценки разработки личного кабинета клиента B2B. Если проект ограничивается публичными страницами и приёмом заявок, изучите состав услуги разработки сайта для бизнеса.
Ведущий инженер и разработчик веб-систем. Специализируется на Next.js, чистой архитектуре, Core Web Vitals и алгоритмическом ранжировании.
