Пример ТЗ на интернет-магазин на 1С-Битрикс: структура и требования

01

Зачем интернет-магазину ТЗ и с чего начать

Техническое задание на интернет-магазин на 1С-Битрикс нужно не для того, чтобы подрядчик получил список страниц «Главная, Каталог, Контакты». Такой список не объясняет, как покупатель находит товар, какие остатки он видит, почему цена меняется, куда попадает заказ и кто отвечает за ошибку обмена. В результате команда делает интерфейс по макету, а бизнес затем отдельно оплачивает доработки корзины, фильтров, CRM и аналитики.

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

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

Если часть требований пока неизвестна, не заменяйте ее фразой «сделать как на другом сайте». Отметьте решение как открытый вопрос, назначьте владельца и дату согласования. Это честнее и дешевле, чем считать референс спецификацией: на чужом сайте не видны права доступа, правила цен, обработчики ошибок и ограничения интеграций.

03

Опишите каталог как набор данных, а не как витрину

В Битрикс каталог обычно строится на инфоблоках, торговых предложениях, свойствах и ценах. В ТЗ важно отделить данные, которые приходят из учетной системы, от редакционных данных сайта. Артикул, остаток, вес, базовая цена и признак активности могут обновляться обменом; SEO-текст категории, баннер и порядок подборок — редактироваться контент-менеджером. Если не разделить зоны ответственности, ручные изменения будут перезаписываться при первом обмене.

Для каждого типа товара укажите обязательные свойства, тип поля и источник. Например: артикул — строка из 1С; бренд — справочник; цвет — свойство торгового предложения; инструкция — файл; габариты — числа с единицами измерения. Отдельно зафиксируйте правила отсутствия данных: товар без цены скрывать, выводить «под заказ» или разрешать заявку вместо покупки.

Фильтр нельзя описывать формулой «сделать удобный». Нужен перечень фильтров по разделам, логика «И» и «ИЛИ», диапазоны, множественный выбор, ссылка с параметрами и поведение пустой выдачи. Если фильтр формирует индексируемые страницы, это уже SEO-решение: определите шаблон URL, мета-данные, canonical и запрет индексации технических комбинаций.

04

Заказ, оплата и доставка: требования на уровне статусов

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

Опишите статусы отдельно для заказа, оплаты и отгрузки. «Новый заказ» не равен «оплачен». Например, заказ может перейти из N «Принят» в P «Ожидает оплаты», затем в F «Оплачен», D «Передан в доставку» и S «Завершен». Укажите, кто меняет каждый статус: платежный модуль, менеджер, обработчик обмена или служба доставки. Также зафиксируйте, какие письма и сообщения получает покупатель на переходах.

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

05

Интеграция с CRM: какие данные передавать и как не плодить дубли

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

Передавайте не только телефон и комментарий. Минимальный набор для разбора рекламного канала: URL страницы, referrer, utm_source, utm_medium, utm_campaign, utm_content, utm_term, client_id или идентификатор визита, дата и время создания. Для заказа добавьте номер, состав, сумму, скидку, способ оплаты, доставку, промокод и ссылку на заказ в административной части. Названия полей сайта и CRM нужно свести в таблицу соответствий.

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

Интеграция считается готовой не в момент создания сделки, а когда менеджер видит источник, состав заказа и понятную причину ошибки при сбое.

06

Как заложить аналитику, UTM и SEO до запуска

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

UTM-метки сохраняйте при первом визите в cookie или сессии, а затем переносите в заказ и CRM. Это особенно важно, если покупатель возвращается через несколько дней, оформляет заказ после звонка или проходит на другой поддомен. Зафиксируйте срок хранения и правило перезаписи: например, first-touch сохраняется всегда, last-touch обновляется при новом рекламном переходе. Проверка только адресной строки не подтверждает работу атрибуции.

SEO-раздел ТЗ должен покрывать не «продвижение», а технические условия: ЧПУ, шаблоны title и description, правила H1, canonical, robots.txt, XML-карту, редиректы со старых URL, микроразметку и управление индексируемыми страницами фильтра. Перед стартом согласуйте список разделов, которые обязаны быть доступны без JavaScript, и требования к скорости на мобильных устройствах.

1. 1

   Составьте карту событий. Свяжите каждое событие с конкретным действием пользователя и параметрами товара или заказа.

2. 2

   Определите источники. Укажите, какие UTM и идентификаторы визита сохраняются в cookie, заказе и CRM.

3. 3

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

4. 4

   Проведите тестовый заказ. Оформите покупку по размеченной ссылке и проверьте путь данных от браузера до CRM.

08

Приемка: проверяйте не макет, а сквозной сценарий

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

Для каждого сценария укажите входные условия, действия и ожидаемый итог. Пример: перейти по ссылке с utm_campaign=spring, выбрать вариацию товара, применить промокод, оформить оплату картой. В результате номер заказа создан, итоговая сумма совпадает, UTM сохранены, в CRM появилась одна запись с составом заказа, а событие purchase передало тот же номер. При ошибке платежа не должно появиться ложное подтверждение оплаты.

Отдельно проверьте права: контент-менеджер меняет карточку и мета-теги, но не видит токены интеграции; менеджер меняет статус заказа, но не редактирует цену после оплаты без журнала; администратор может повторить отправку в CRM. В проектах ICONICA такие проверки фиксируют в приемочном листе, а примеры реализованных процессов можно посмотреть в портфолио.

09

Что должно остаться после согласования ТЗ

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

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

Подключать подрядчика стоит на этапе, когда бизнес-правила уже собраны, но их нужно перевести в архитектуру Битрикс, схему обмена и план работ. Это снижает число оценок «на глаз» и помогает сравнивать предложения команд по одинаковому объему, а не по обещаниям сделать магазин быстро.