Техническое задание для сайта интернет-магазина: структура и примеры

Главная
Блог
Техническое задание для сайта интернет-магазина: структура и примеры

Как составить грамотное ТЗ для сайта интернет магазина: пошаговое руководство

1. Задача ТЗ: зачем интернет-магазину вообще тратить время на подробное описание проекта

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

Для владельца магазина детально составленное техническое задание помогает:

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

Команде разработки хороший документ дает:

понятный объем работ и приоритеты, без угадываний «что заказчик имел в виду»;
возможность заранее спланировать архитектуру, нужные cms, необходимые внешними сервисами интеграции, настройки серверов и совместимость с браузерами;
осмысленное планирование спринтов: какие блоки реализации делать в первую очередь, чтобы запустить MVP в разумные сроки.

Маркетинг и аналитика выигрывают за счет того, что в ТЗ сразу заложены:

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

В случае отсутствия внятного ТЗ обычно происходить одно и то же:

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

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

2. Подготовка к написанию ТЗ: какие решения нужно принять до общения с разработчиками

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

Во-первых, сформулируйте цели проекта простым языком. Например:

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

Во-вторых, опишите товарную матрицу и особенности ассортимента:

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

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

с каких устройств люди чаще заходят: телефоны, планшеты, рабочие ноутбуки;
как они ищут товар: через поиск по сайту, из поиска Яндекса и Google, по рекламе в социальных сетях, из email-рассылок;
какие запросы в поиске чаще всего приводят к вам (это можно посмотреть в системах аналитика на старом сайте или в рекламных кабинетах);
нужен ли быстрый заказ без регистрации или ваша аудитория готова создавать личный кабинет ради бонусов и персональных условий.

Бизнес-ограничения тоже нужно зафиксировать до общения со специалистами по разработке интернет-магазинов:

примерный бюджет и формат оплаты (фикс, этапы, почасовая поддержка);
желаемый срок запуска: вы делаете MVP за 2–3 месяца или готовы подождать, но получить максимум функций сразу;
есть ли внутренняя команда, которая будет заниматься контентом, аналитикой, поддержкой клиентов и обновлением характеристик в каталоге;
какие процессы уже автоматизированы: учет в 1С, CRM для менеджеров, складские сервисы, внешними службами доставки интеграции.

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

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

Все эти вводные лучше оформить отдельным разделом ТЗ и приложить как файлы или текстовые блоки. Тогда у разработчиков, дизайнеров и аналитиков будет общая основа, на которой строится структура будущего проекта.

3. Структура ТЗ для сайта интернет-магазина: какие разделы должны быть обязательно

Большинство запросов в поиске по этой теме сводятся к одному вопросу: «Что именно должно быть в ТЗ для интернет-магазина?». Ниже — каркас, который можно адаптировать под любые ниши: от одежды до сложного оборудования.

Общий перечень разделов может выглядеть так.

Общая информация о проекте.
Целевая аудитория и пользовательские сценарии.
Функциональные требования к витрине и корзине.
Товарный учет и интеграции.
Требования к админ-панели.
Контент и дизайн.
Нефункциональные требования.
Сроки, этапы и критерии приемки.

Кратко разберем, что включать в каждый блок.

1. Общая информация о проекте:

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

2. Описание целевой аудитории и пользовательских сценариев:

типовые пользователи: гость, зарегистрированный покупатель, менеджер колл-центра, администратор, маркетолог;
3–5 ключевых сценариев, например: «найти товар по поиску и оформить заказ с оплатой картой», «повторить прошлую покупку из личного кабинета», «узнать статус доставки по номеру заказа», «получить консультацию и сделать заказ через телефон».

3. Функциональные требования к витрине и корзине:

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

4. Товарный учет и интеграции:

откуда берутся товары, остатки и цены: вручную, из 1С, из другой учетной системы, из внешних маркетплейсов;
как часто нужна синхронизация и в каком виде: по расписанию, по запросу, через API;
способы оплаты: банковские карты, электронную оплату через кошельки, рассрочка, оплата частями, оплата при получении;
способы доставки: курьер, пункты выдачи, постаматы, самовывоз, интеграции с логистическими сервисами;
нужны ли интеграции с CRM, системами email-маркетинга, сервисами аналитики.

5. Требования к админ-панели:

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

6. Контент и дизайн:

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

7. Нефункциональные требования:

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

8. Сроки, этапы и критерии приемки:

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

4. Пошаговое руководство: как заполнить ключевые разделы ТЗ (с примерами формулировок)

4.1. Описание функционала интернет-магазина простым языком

Начните с того, чтобы переписать абстрактные желания в конкретные формулировки. Вместо «хотим магазин как у Х» сформируйте список функций, которые вам нравятся в этом примере, и оформите их в виде требований.

Было: «Нужен удобный поиск товаров».
Стало: «Реализовать поиск по названию, артикулу и SKU с автодополнением и учетом опечаток. В результатах поиска показывать цену, наличие и ссылку на карточку товара».
Было: «Сделайте красивые акции и новинки на главной».
Стало: «На главной странице реализовать блоки: карусель баннеров, блок “Акции”, блок “Новинки”. Блоки управляются из админ-панели, поддерживают добавления баннеров с разными сроками действия и ссылками на нужные категории или конкретные товары».

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

4.2. Каталог, фильтры и карточка товара

Каталог — основа навигации. Опишите, как вы видите структуру:

сколько уровней категорий планируется (например, «Одежда → Женская → Платья»);
нужны ли отдельные страницы для брендов, сезонных коллекций, подборок «Подарки», «Новинки»;
какие параметры важны для фильтрации: размер, цвет, бренд, материал, срок годности, цена, наличие на складе, наличие в конкретном магазине;
нужен ли «умный фильтр», который скрывает значения без товаров, и подсчет количества подходящих позиций.

Карточка товара должна включать минимум обязательных блоков:

название и артикул;
цена, возможные скидки, старая цена, условия акций;
наличие: в конкретном складе, в офлайн-точках, сроки поставки;
варианты товара: размеры, цвета, комплекты, количество в упаковке;
подробные характеристики с группировкой по смыслу (например, «Основные», «Размеры», «Материалы»);
фотогалерея, возможно, видео в виде обзора;
блок доставки и оплаты: способы, сроки, цена;
отзывы и рейтинг, если это планируется в первом релизе.

Чтобы не раздувать MVP, прямо в ТЗ укажите, что можно отложить:

«В первой версии не реализовывать блок “С этим товаром покупают”. Оставить техническое место под него в структуре страницы»;
«Отзывы подключить на втором этапе, после накопления статистики и готовности модерации».

4.3. Корзина, оформление заказа и личный кабинет

Корзина и процесс оформления заказа — то, что чаще всего ищут пользователи в инструкциях по ТЗ, потому что здесь больше всего нюансов. Опишите:

как добавляются товары в корзину, как отображается количество и итоговая цена;
можно ли менять параметры прямо в корзине (размер, цвет, количество);
как применяется промокод, как пользователь видит размер скидки и итоговую сумму.

Процесс оформления заказа желательно разложить на шаги:

«Шаг 1 — Контакты: форма с полями имя, телефон, email. Проверка формата телефона и электронной почты»;
«Шаг 2 — Доставка: выбор типа доставки, адрес, время, комментарий курьеру»;
«Шаг 3 — Оплата: выбор способа, галочка согласия с условиями, информация о безопасности оплаты»;
«Шаг 4 — Подтверждение: итоговый перечень товаров в корзине, цена, стоимость доставки, кнопка “Подтвердить заказ”».

Варианты авторизации можно описать так:

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

4.4. Интеграции с платёжными системами, доставкой, учётом

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

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

По доставке:

какие службы вы планируете использовать: собственная курьерка, СДЭК, Boxberry, Почта России, другие;
нужны ли динамические расчеты стоимости по API или достаточно фиксированных тарифов по зонам;
как пользователь выбирает ПВЗ или постамат на карте;
нужен ли вывод статуса доставки в личном кабинете с привязкой к трек-номеру.

Для учета и складов:

опишите, какие системы уже используются (1С, МойСклад, другая CMS учета) и как именно с ними должен обмениваться магазин;
укажите, какие поля являются обязательными в обмене: остатки, закупочная цена, розничная цена, характеристики, штрихкоды;
зафиксируйте, кто отвечает за настройки интеграций и на чьей стороне происходит анализ логов и ошибок.

4.5. Админка: что должно быть удобно именно вам

Админ-панель — рабочий инструмент менеджеров. Здесь важно не «как принято», а как удобно вашим сотрудникам. Опишите ежедневные операции:

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

Примеры формулировок для ТЗ:

«В админ-панели реализовать массовое редактирование цен и остатков с возможностью выгрузки и загрузки в формате Excel»;
«Для каждого заказа хранить историю изменений статусов с указанием пользователя и времени изменения»;
«Предусмотреть раздел управления контентом: статические страницы, текстовый блок на главной, баннеры, раздел “Вакансии”, ссылки в подвале».

4.6. Нефункциональные требования без лишних терминов

Нефункциональные требования часто пишут сложным языком. На практике можно описать их через сценарии:

«Страница каталога до 1000 товаров должна открываться не дольше 2 секунд для пользователя из России при стабильном подключении 4G»;
«Время ответа сервера при оформлении заказа не более 3 секунд в 95% случаев при нагрузке до 200 одновременных пользователей»;
«Сайт должен корректно работать во всех актуальных версиях популярных браузеров, корректно отображаться на телефонах и планшетах».

По безопасности:

«Весь трафик сайта должен передаваться по HTTPS»;
«Персональные данные обрабатываются в соответствии с законодательством, данные банковских карт не хранятся на стороне магазина, оплата идет через сертифицированный платежный шлюз»;
«Доступ к админ-панели — по логину и паролю, с возможностью ограничения по IP и журналом входов».

5. Типичные ошибки в ТЗ для интернет-магазина и способы их избежать

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

Ошибка 1: ТЗ пишется «под идеальный магазин через год».

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

критично для запуска (MVP);
важно, но можно перенести на следующий этап;
хорошо бы иметь, если останется ресурс.

Ошибка 2: смесь бизнес-задач и технического жаргона без понимания.

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

Ошибка 3: отсутствие приоритетов.

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

Ошибка 4: недооценка контента и данных.

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

кто отвечает за тексты и фотографии;
какой формат данных нужен для импорта (таблицы, XML, API);
когда будут готовы материалы для ключевых категорий.

Ошибка 5: нет критериев приемки.

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

«Пользователь может найти товар через поиск по части названия, добавить его в корзину, оформить заказ с оплатой картой и доставкой курьером, получить письмо “Заказ принят” — без участия менеджера»;
«Маркетолог может создать акцию в админ-панели, указать список товаров, дату начала и конца, настроить баннер и ссылку на категорию без привлечения разработчика».

Ошибка 6: игнорирование аналитики.

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

6. Как согласовать ТЗ с командой разработки и не утонуть в правках

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

К обсуждению стоит подключить:

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

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

Список вопросов, которые полезно задать разработчикам по вашему ТЗ:

«Какие пункты кажутся рискованными по срокам или бюджету?»;
«Где вы видите технические ограничения выбранной CMS или стека?»;
«Какие функции лучше разбить на этапы?»;
«Есть ли готовые решения или шаблоны, которые уменьшат стоимость и ускорят реализацию без потери качества?».

Изменения в ТЗ должны документироваться. Лучшие практики:

нумерация версий документа (v1, v1.1, v2) с датами;
журнал изменений: что добавлено, что убрано, по чьей инициативе и с какими последствиями для сроков;
согласование только через ответственных лиц с обеих сторон, чтобы не было противоречивых указаний от разных участников.

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

7. Чек-лист готовности ТЗ для сайта интернет-магазина и когда стоит отдать подготовку специалистам

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

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

Если по большинству пунктов вы отвечаете «да» — ТЗ уже на хорошем уровне и отвечает задачам проекта. Если нет, имеет смысл доработать документ или привлечь внешних специалистов.

Когда особенно полезно отдать подготовку ТЗ профессиональной команде:

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

Наша команда занимается разработкой интернет-магазинов, мобильных приложений, веб-сервисов и CRM-систем. Мы можем:

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

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