ТЗ для магазина: как составить задание на интернет-магазин, чтобы заказы не терялись

Заказчик просит «сделать магазин», дизайнер рисует карточки товара, разработчик подключает корзину, а после запуска выясняется: клиент не может оформить заказ без регистрации, оплата проходит не во всех случаях, остатки в 1С и на сайте расходятся, письма о заказе не уходят, а админка осталась у подрядчика. Формально магазин есть, фактически — он не зарабатывает. В e-commerce цена размытого ТЗ особенно высока: здесь ошибка не в «красивой кнопке», а в потерянном заказе, испорченной репутации и_simple_юридических рисках. Разбираем, как составить ТЗ для магазина так, чтобы на выходе получить работающую торговую систему, а не набор страниц.

Что такое ТЗ для магазина и когда оно спасает

ТЗ для магазина — это документ, который описывает не только внешний вид каталога, но и бизнес-процессы: как товар заводится, как считается цена, как обновляется остаток, как клиент оформляет заказ, как деньги проходят оплату, как доставка получает данные, как менеджер видит заказ в админке или CRM, как формируются чеки и как всё это принимается. Это спецификация денежного пути: от клика «Купить» до отгруженного заказа и поступившей оплаты.

Такое ТЗ особенно нужно, когда магазин:

• работает с остатками и 1С/CRM/WMS. Без описания источника истины сайт и учётная система будут жить в разных реальностях.
• принимает онлайн-оплату. Нужны сценарии успеха, ошибки, возврата, частичной оплаты, чеков и сверки.
• запускается в срок под рекламу или маркетплейсы. Если трафик пойдёт, а корзина падает, бюджет сгорит.
• переносится со старой платформы. Важно сохранить URL, товары, клиентов, историю заказов, SEO и акции.
• обслуживается несколькими ролями. Маркетолог, менеджер, склад, бухгалтер, контент-редактор — каждому нужны свои права и процессы.

Магазин — это не витрина. Это система: товар + цена + остаток + корзина + оплата + доставка + учёт + документы + поддержка. ТЗ должно описывать систему, а не только фасад.

Простой тест: если по ТЗ можно написать тест-кейсы для заказа, проверить интеграцию с 1С, убедиться, что чек уходит клиенту, и принять магазин без вопроса «а где доступы?» — документ рабочий. Если остаются пробелы в оплате, остатках, правах или юридических согласиях — ТЗ нужно дополнять. Для общей постановки задачи полезна статья ТЗ для разработки ПО, а для сбора входных данных — Данные для ТЗ.

Специфика ниши магазина: 5 особенностей, которые влияют на ТЗ

Интернет-магазин отличается от корпоративного сайта, лендинга или приложения. Здесь каждый элемент связан с деньгами и операционкой. Эти особенности нужно закладывать в ТЗ заранее.

1. Корзина и оформление — зона максимальной потери денег

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

2. Товарные данные и остатки — это не контент, а учёт

В магазине важны SKU, артикулы, варианты, характеристики, цена, старая цена, остаток, резерв, статус «под заказ», единицы измерения, изображения, SEO-URL, категории, фильтры. Если источник истины не определён, менеджеры будут править цену на сайте, склад — в 1С, а клиент увидит одно, закажет другое и получит конфликт. В ТЗ нужно зафиксировать: где создаётся товар, как синхронизируется, с какой частотой, что делать при нулевом остатке, как обрабатывать дубли и удалённые позиции.

3. Оплата, доставка и фискальные данные требуют явных сценариев

«Подключить оплату» — недостаточное требование. Нужно указать способы: карта, СБП, наличные при получении, рассрочка, корпоративный счёт, предоплата или постоплата. Для каждого — статус заказа, проверка, возврат, чек, сверка. Доставка тоже не одна кнопка: тарифы, зоны, сроки, трекинг, самовывоз, интервалы, ограничение по весу и габаритам. Если магазин работает в РФ, отдельно продумайте требования по кассе, персональным данным, оферте и правилам дистанционной торговли — актуальные нормы лучше проверять с юристом до запуска.

4. Админка и роли важнее, чем кажется на презентации

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

5. AI ускоряет магазин, но не заменяет контроль

В 2026 году AI используют для генерации описаний товаров, умного поиска, рекомендаций, чат-ботов, генерации изображений и автоматической разметки каталога. Это может повысить конверсию. Но AI не отвечает за корректность остатков, юридические формулировки, лицензии на изображения, защиту персональных данных и галлюцинации в рекомендациях. Если AI участвует в проекте, в ТЗ нужно указать: какие задачи автоматизированы, кто проверяет результат, какие данные нельзя передавать в сторонние сервисы и как оформляются права. Полезная рамка — ТЗ для ИИ.

Структура ТЗ для магазина

1. Цель: какой бизнес-результат должен давать магазин

Начните не с «нужен интернет-магазин», а с задачи. Цель должна быть измеримой: продавать N заказов в месяц, сократить ручную обработку заявок, выйти в новый регион, увеличить средний чек за счёт комплектов, перенести старый каталог без потери позиций. Хорошая формула: «Магазин нужен, чтобы [аудитория] могла [действие] и приносил бизнесу [метрику]».

Пример: «Интернет-магазин хозяйственных товаров должен позволять клиенту выбрать товар, оформить заказ с доставкой или самовывозом и оплатить онлайн, обеспечивая не менее 80% заказов без участия менеджера в первые 3 месяца после запуска».

2. Требования: функциональные, нефункциональные, интеграционные и правовые

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

Функциональные требования — что магазин умеет:

• каталог: категории, подкатегории, фильтры, сортировка, поиск, пагинация;
• карточка товара: галерея, варианты, характеристики, цена, остаток, описание, документы, отзывы, блок «с этим покупают»;
• корзина: изменение количества, сохранение, купоны, доставка, промокоды, мини-корзина;
• оформление: гостевой заказ и личный кабинет, адрес, контакты, способ доставки, оплата, согласие, подтверждение;
• заказы: статусы, история, отмена, возврат, повтор заказа, дубликаты;
• личный кабинет: заказы, адреса, документы, подписки, поддержка;
• админка: товары, заказы, клиенты, скидки, контент, отчёты, импорт/экспорт, роли.

Нефункциональные требования — как магазин работает:

• мобильная версия и адаптив;
• скорость: например, LCP до 2,5 сек, страница товара до 3 сек на 4G;
• SEO-база: ЧПУ, метатеги, sitemap, robots, микроразметка товаров, canonical, редиректы;
• безопасность: HTTPS, защита от брутфорса, проверка файлов, разграничение прав, логирование;
• надёжность: резервные копии, восстановление, мониторинг ошибок, запас по нагрузке.

Интеграции — с чем магазин обменивается данными:

• 1С/ERP/WMS: товары, остатки, цены, заказы, статусы;
• CRM: лиды, клиенты, история коммуникаций;
• платёжные системы: эквайринг, СБП, возвраты, чеки;
• службы доставки: расчёт, создание заказа, трекинг, статусы;
• почта/SMS/мессенджеры: подтверждения, уведомления;
• аналитика: события, цели, e-commerce-отчёты;
• кассовое ПО и ОФД, если требуется фискализация.

Для карточек товаров и маркетплейсов полезно отдельно смотреть ТЗ для карточки товара и ТЗ для маркетплейса. Если магазин синхронизируется с учётной системой, используйте ТЗ для 1С.

3. Объём: что входит в первую версию и что не входит

В ТЗ для магазина нужен явный список границ. Например:

• входит: 1 язык, 3 роли, 5000 SKU, 5 категорий верхнего уровня, фильтры по 8 атрибутам, гостевой заказ, 2 способа оплаты, 3 службы доставки, базовый личный кабинет, интеграция с 1С, аналитика, перенос 3000 товаров;
• не входит: мобильное приложение, мультиязычность, B2B-прайс, маркетплейс-фиды, фотосъёмка, написание SEO-текстов, настройка рекламы, сложная BI-аналитика, программа лояльности;
• оплачивается отдельно: новые интеграции, изменение логики корзины, редизайн, миграция дополнительных систем.

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

4. Сроки: этапы, зависимости и точки согласования

Магазин нельзя сдать одной датой. Нужен план по этапам:

• аудит данных и утверждение ТЗ;
• структура каталога и прототип;
• дизайн ключевых страниц;
• backend и админка;
• загрузка товаров и настройка фильтров;
• корзина, оплата, доставка;
• интеграции с 1С/CRM/кассой;
• тестирование сценариев;
• пилот на ограниченной группе;
• запуск и передача доступов.

Отдельно зафиксируйте ответственность заказчика: предоставить товары, цены, остатки, доступы к 1С, платёжному шлюзу, доставке, юридические документы. Если этих данных нет, этап не может начаться, и срок должен сдвигаться. Для структурирования сроков полезен план для ТЗ.

5. Критерии приёмки: как понять, что магазин готов

Приёмка магазина должна быть сценарной. Не «страницы открываются», а:

• клиент нашёл товар через фильтр, добавил в корзину, оформил без регистрации, выбрал доставку и оплату, получил подтверждение;
• заказ появился в админке и ушёл в 1С/CRM с корректными статусами;
• остаток обновился, товар с нулём недоступен для заказа или помечен как «под заказ» согласно ТЗ;
• письмо/SMS отправлено, чек сформирован, если требуется;
• менеджер может изменить статус, добавить комментарий, оформить возврат;
• админка позволяет импортировать товары и редактировать цены без разработчика;
• скорость и мобильная версия соответствуют требованиям;
• юридические согласия и оферта отображаются до отправки заказа.

6. Формат передачи: что заказчик получает после запуска

Магазин нельзя принять, если не переданы активы. В ТЗ нужно указать:

• доступы к домену, хостингу, CMS, базе данных, FTP/SFTP, платёжному кабинету, сервисам доставки, почте, аналитике;
• исходный код или репозиторий, если это предусмотрено;
• документацию: архитектура, API, инструкция администратора, инструкция менеджера;
• список лицензий на плагины, шрифты, стоки, AI-генерации;
• резервные копии и порядок восстановления;
• обучение команды или видеоинструкцию;
• гарантийный срок и канал поддержки.

Критично, чтобы домен, хостинг, платёжные аккаунты и ключи были оформлены или переданы заказчику. Иначе после конфликта магазин может остаться у подрядчика.

7. Правки: что считается доработкой, а что новой задачей

В e-commerce правки неизбежны, но их нужно разграничить. Исправление бага, несоответствие согласованному ТЗ, опечатка в интерфейсе, корректировка отступов — правка. Новая интеграция, другой платёжный метод, B2B-модуль, редизайн, миграция additional системы, изменение логики скидок — новая задача. В ТЗ зафиксируйте: изменения согласовываются письменно, с оценкой влияния на срок и стоимость. На Workink такие договорённости удобно фиксировать в чате заказа: переписка имеет силу ТЗ и помогает отделить правку от расширения объёма.

Мини-пример фрагмента ТЗ для магазина

Проект: интернет-магазин хозяйственных товаров на 5000 SKU.

Цель: не менее 80% заказов оформляются клиентом самостоятельно, обработка заказа менеджером сокращается до 10 минут.

Каталог: источник истины — 1С; синхронизация цен и остатков каждые 15 минут; товары с нулевым остатком скрываются из заказа, но остаются в каталоге со статусом «Нет в наличии».

Оформление: гостевой заказ обязателен; личный кабинет опционален; доставка — самовывоз, курьер по городу, СДЭК; оплата — СБП, карта, наличные при получении для курьера.

Интеграции: 1С — товары, остатки, заказы; CRM — клиенты и статусы; касса — чеки при онлайн-оплате; почта — подтверждение и счёт; аналитика — события view_item, add_to_cart, begin_checkout, purchase.

Не входит: мобильное приложение, маркетплейс-фиды, фотосъёмка, B2B-прайсы, программа лояльности.

Приёмка: 20 тестовых заказов пройдены端到端; остатки обновились в 1С; чеки сформированы; доступы и документация переданы.

Критерии приёмки результата магазина

Магазин можно принимать, если выполнены измеримые условия:

• Товары и остатки корректны. Цена, остаток, варианты, изображения и статусы совпадают с источником истины. Нулевые остатки не позволяют оформить заказ, если это предусмотрено ТЗ.
• Поиск и фильтры работают. Клиент находит товар по артикулу, названию, категории и атрибутам. Пустые выдачи показывают понятные подсказки.
• Карточка товара полная. Есть галерея, описание, характеристики, документы, отзывы или их отсутствие обосновано. Кнопка «Купить» ведёт в корзину без лишних шагов.
• Оформление заказа проходит端到端. Гостевой и авторизованный пользователь могут выбрать доставку, оплату, ввести данные, получить подтверждение и номер заказа.
• Оплата и доставка обрабатывают ошибки. При сбое платёжного шлюза клиент видит понятное сообщение и может повторить попытку. Статусы доставки и оплаты корректно обновляются.
• Интеграции синхронизируются. Заказ уходит в 1С/CRM, статусы возвращаются на сайт, товары и цены обновляются по расписанию. Ошибки обмена логируются.
• Админка и роли настроены. Менеджер видит заказы, редактор — товары, бухгалтер — платежи, админ — настройки. Критичные действия логируются.
• Нефункциональные требования соблюдены. Мобильная версия удобна, скорость в норме, HTTPS работает, бэкапы настроены, SEO-база заполнена.
• Юридические элементы на месте. Оферта, политика конфиденциальности, согласия на обработку данных, реквизиты, условия возврата доступны до отправки заказа.
• Активы переданы. Доступы, код, документация, лицензии, инструкции и обучение переданы заказчику. Магазин не зависит от одного исполнителя.

Вопросы для уточнения до старта

Эти вопросы нужно задать себе, подрядчику и внутренним командам до начала работы:

• Что продаём: физические товары, цифровые продукты, услуги, подписки?
• Сколько SKU, вариантов, категорий, атрибутов и изображений на старте?
• Где источник истины по товарам, ценам и остаткам: 1С, CRM, Excel, сайт?
• Нужна ли синхронизация в реальном времени или достаточно раз в час/сутки?
• Какие способы оплаты и доставки обязательны, какие — на втором этапе?
• Нужны ли чеки, онлайн-касса, ОФД, корпоративные платежи, рассрочка?
• Есть ли личный кабинет, история заказов, повторный заказ, возвраты?
• Кто будет управлять контентом и какие роли нужны в админке?
• Нужен ли перенос старого магазина, SEO-URL, клиентов и истории заказов?
• Какие интеграции обязательны: 1С, CRM, доставка, почта, SMS, аналитика, маркетплейсы?
• Есть ли требования к скорости, нагрузке, безопасности, резервным копиям?
• Кто отвечает за юридические документы: оферту, политику, согласия, реквизиты?
• Нужны ли AI-функции: рекомендации, поиск, чат-бот, генерация описаний?
• Что входит в поддержку после запуска и на какой срок?
• Какие файлы, доступы и документация должны быть переданы заказчику?

Чек-лист готовности ТЗ

Перед публикацией заказа или стартом разработки пройдитесь по короткому чек-листу. Если хотя бы два пункта не закрыты, ТЗ лучше дополнить.

• Цель магазина сформулирована через заказы, метрики и сроки.
• Описаны каталог, товарные данные, источник истины и правила остатков.
• Зафиксированы сценарии корзины, оформления, оплаты и доставки.
• Перечислены интеграции, формат обмена и обработка ошибок.
• Указаны роли админки, права и требования к логированию.
• Прописаны нефункциональные требования: скорость, мобильная версия, SEO, безопасность, бэкапы.
• Отдельно зафиксированы юридические документы и согласия.
• Определены критерии приёмки, состав передачи и правила правок.

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

Как заказать магазин на Workink

На Workink задача по магазину публикуется в категории «Техническое задание (ТЗ)». Это удобно, когда нужно не просто найти разработчика или дизайнера, а передать структурированное задание: цель, каталог, корзина, оплата, доставка, интеграции, роли, приёмка и передача.

Платформа снижает типовые риски e-commerce-проектов:

• Безопасная сделка: деньги находятся в резерве до приёмки работы. Вы платите за результат, а не за обещание запустить магазин.
• Комиссия 11% за заказ и 0% за вывод: прозрачные условия без удержания при выводе средств.
• Доработки бесплатно до соответствия ТЗ: если магазин не соответствует согласованным требованиям, исполнитель дорабатывает результат.
• Договорённости в чате имеют силу ТЗ: всё, что вы обсудили по товарам, оплатам, интеграциям, срокам, доступам и правкам, фиксируется в переписке и защищает обе стороны.

Если вы заказчик, начните с сильного ТЗ: цель, данные, процессы, интеграции, приёмка и передача. Если вы исполнитель, просите эти пункты до старта — они защищают от бесконечных «а добавьте ещё маркетплейс» и снижают риск бесплатных переделок.

Найти исполнителя Разместить заказ Защита покупателей

Полезные материалы по теме

• ТЗ для карточки товара — если магазин начинается с правильных карточек.
• ТЗ для маркетплейса — если продажи идут не только на своём сайте.
• ТЗ для 1С — для синхронизации товаров, остатков и заказов.
• ТЗ для разработки ПО — общая логика постановки сложной системы.
• Данные для ТЗ — какие товары, цены, доступы и документы подготовить.
• Документы для ТЗ — оферты, политики, ТЗ на интеграции и акты.
• План для ТЗ — как разложить запуск магазина по этапам.