Вернуться к статьям Покупатель открывает каталог, выбирает товар, добавляет его в корзину — и сталкивается с тем, что нужной вариации нет, остаток неясен, доставка рассчитывается позже, а менеджеру приходится вручную уточнять состав заказа. Проблема обычно не в самой витрине. Она возникает, когда логика ассортимента и обработки заказов сложнее структуры страницы.
Перед сборкой стоит описать товарные данные, правила корзины, сценарии оплаты и дальнейшую работу с заказом. Конструктор оценивают по тому, поддерживает ли он согласованные сценарии каталога и оформления заказа. Такой список помогает определить, достаточно ли конструктора или проекту нужна отдельная торговая система.
Интернет-магазин на Тильде: когда формат уместен
Конструктор можно рассматривать как способ собрать витрину и базовый путь покупателя: от карточки товара до отправки заказа. Для проекта проверяют структуру ассортимента, зависимости между товарами и порядок внесения изменений в каталог.
Например, каталог может содержать изделия с фотографиями, описаниями, несколькими вариантами и единым способом оформления. Сначала определяют состав карточки: название, изображения, характеристики, вариант исполнения, наличие, условия получения. Затем проверяют, какие данные покупатель должен увидеть до добавления товара в корзину.
Если в каталоге появляются связанные позиции, персональные условия, разные правила для групп покупателей или расчёт товара из множества параметров, требований к витрине становится больше. Значение имеет не количество карточек, а сложность правил вокруг них.
Каталог товаров на Тильде: структура до наполнения
Каталог нередко заполняют сразу после выбора шаблона. Тогда одинаковые товары получают разные названия полей, характеристики дублируются в тексте, а разделы строятся без общего принципа. Исправление структуры после публикации затрагивает навигацию, адреса страниц и поиск товаров.
До наполнения полезно подготовить таблицу товарных данных. В ней фиксируют:
- категории и подкатегории;
- обязательные поля карточки;
- варианты одного товара;
- правила формирования названия;
- изображения и порядок их показа;
- признаки для сравнения позиций;
- товары, которые нельзя заказать отдельно.
Отдельно проверяют вариантность. Размер, цвет, объём, материал или комплектация могут выглядеть одинаково в карточке, но по-разному влиять на состав заказа. Если у каждого варианта свои остатки, артикулы или условия выдачи, это следует описать до настройки каталога.
Карточка товара должна отвечать на практические вопросы: что входит в комплект, чем отличаются варианты, что покупатель получит после оформления и какие данные потребуются для заказа.
Корзина в интернет-магазине: что проверить на сценариях
Корзина связывает варианты товара, количество, данные покупателя, способ получения и правила обработки заказа. Ошибки в этой части становятся заметны при нестандартном заказе.
Перед запуском стоит пройти несколько сценариев от лица покупателя:
- добавить один товар и изменить количество;
- выбрать разные варианты одной позиции;
- удалить товар и собрать заказ заново;
- оформить заказ с неполными данными;
- проверить сведения, которые получает сотрудник после отправки;
- отменить действие на каждом шаге и вернуться в каталог.
Для каждого сценария нужен ответ: где хранится заказ, кто видит уведомление, какие данные можно уточнить вручную и как отмечается дальнейший статус. Если менеджер переносит состав заказа в отдельную учётную систему, стоит сверить названия товаров, варианты и служебные идентификаторы. Свободный текст в комментарии не заменяет структурированные позиции заказа.
Варианты товара, наличие и комплектация
Распространённая ошибка в небольшом каталоге — считать все различия товара обычными характеристиками. Покупатель выбирает цвет, размер или комплект, а сотрудник видит в заказе только общее название позиции. Для уточнения состава приходится связываться с покупателем.
Для каждой характеристики определяют роль. Одни поля объясняют товар: состав, габариты, инструкция по уходу. Другие меняют выбранную позицию: размер, исполнение, набор элементов. Третьи относятся к заказу в целом: пожелание к доставке или комментарий покупателя.
Отдельного решения требуют составные товары. Если набор состоит из нескольких позиций, заранее определяют, продаётся ли он только комплектом, допускается ли замена элемента и как сотрудники узнают о такой замене. Когда эти правила существуют только в переписке, каталог перестаёт быть источником актуальной информации.
Для наличия также нужен единый процесс: кто и когда меняет отметку, откуда берутся данные и что происходит с товаром, который уже добавили в корзину.
Оформление заказа и работа сотрудников
После отправки заказа начинается внутренняя часть процесса. Покупателю нужен понятный результат действия, а сотруднику — данные для проверки и исполнения. Текст для покупателя не обязан повторять внутренние инструкции, а служебное уведомление должно содержать структурированные сведения о заказе.
До настройки оформления согласуют маршрут заказа. Кто получает его первым? В какой системе проверяют наличие? Кто связывается с покупателем, если выбранный вариант недоступен? Как отличить новые обращения от обработанных? Где фиксируют отмену или корректировку?
В проекте отдельно определяют, какая система отвечает за публикацию витрины, какие данные используются при оформлении и где сотрудники обрабатывают обращения и заказы. Это разграничение зависит от согласованной схемы работы и настроенной интеграции. Перед её настройкой описывают поля и статусы: какие сведения передаются, какие заполняет сотрудник, какое поле считают источником данных при расхождении.
Границы конструктора и признаки сложного магазина
Конструктор рассматривают, когда логика продажи укладывается в согласованную структуру каталога и повторяемые сценарии. При усложнении процессов растёт число ручных исключений.
Архитектуру пересматривают, если проекту нужны нестандартные правила ценообразования, персональные каталоги, зависимые конфигурации товаров, сложное резервирование, синхронизация нескольких источников остатков или разные условия для одного товара. Отдельный признак — ситуация, когда сотрудники постоянно исправляют заказ после оформления.
Сначала фиксируют требования: где ведётся номенклатура, кто меняет остатки, какие данные обязательны в заказе и какие операции нельзя выполнять вручную. Для части проектов достаточно доработки текущей витрины и обмена данными с внешней системой. В других случаях рассматривают систему управления сайтом с более детальной торговой логикой, например 1С-Битрикс: Управление сайтом. Выбор зависит от сценариев работы с каталогом и заказами.
Как сформулировать задачу на интернет-магазин
Техническое задание на интернет-магазин начинается с процесса продажи, а не с макета главной страницы. Подрядчику нужны примеры реальных товаров, вариантов, исключений и заказов. Формулировка «обычный каталог» не описывает будущую работу.
Полезно подготовить образцы: простой товар, товар с вариантами, комплект, товар без наличия, заказ с комментарием и заказ, требующий ручной проверки. По ним видно, где корзина передаёт недостаточно данных, какие поля нужны в карточке и какие ограничения следует показать покупателю заранее.
Исключения лучше фиксировать до запуска. Фотографии, характеристики и правила комплектации также требуют ответственного сотрудника: без этого витрина постепенно теряет актуальность.
Часто задаваемые вопросы
- Можно ли сделать интернет-магазин на Тильде, если товаров много?
Количество товаров само по себе не определяет выбор. Нужно проверить структуру каталога: повторяются ли поля, есть ли варианты, кто обновляет данные и как меняется наличие. Если позиции строятся по одному шаблону, каталог проще поддерживать. Если у каждой группы товаров свои правила, эти различия описывают до настройки.
- Как передавать варианты товара в заказ?
В заказе должны быть указаны название товара и выбранные параметры, которые меняют состав позиции: размер, цвет, комплектация или другой вариант. Перед запуском следует оформить тестовый заказ и проверить сведения глазами сотрудника, который будет его обрабатывать.
- Что делать, если товара нет после оформления заказа?
Нужен согласованный сценарий: кто проверяет доступность, как фиксируется замена или отмена и где хранится актуальное наличие. Если действия выполняются вручную, их включают во внутренний порядок обработки, а не решают заново для каждого обращения.
- Нужна ли интеграция с системой работы с обращениями?
Интеграцию рассматривают, если заказ должен попадать в установленный процесс обработки без ручного переноса данных. Сначала определяют состав передаваемых полей, ответственных и статусы, затем проверяют обмен на тестовых заказах. Если сотрудники всё равно переписывают сведения вручную, сначала пересматривают структуру данных.
- Когда вместо конструктора нужна другая система управления сайтом?
Основанием служат конкретные требования: зависимые варианты, сложные правила заказов, несколько источников товарных данных, персональные условия или постоянные ручные исправления. Решение принимают после разбора сценариев и определения системы, где будут храниться исходные данные.