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