Задача
Покупателю огнетушителя мало названия и фотографии. Выбор зависит от класса пожара, огнетушащего агента, вместимости, области применения, совместимости компонентов, стандарта, сертификации и регламента обслуживания — ошибка здесь стоит не денег, а безопасности объекта. Корпоративному клиенту дополнительно нужны повторные закупки, документы и согласованное исполнение заказа, муниципальному — тендерная информация, а сервисному заказчику — понятный путь от обращения до инспекции или ремонта.
Всё это должно было уместиться в одну Magento-систему: розница и согласованные дистрибьюторские условия, глубокая номенклатура и понятная навигация, продажа оборудования и сервисные работы по нему же.
Решение
Каталог по инженерным признакам. Огнетушители разделены по агенту и назначению — dry chemical, CO2, clean agent, wet chemical, water and mist, automatic, lithium-ion; отдельно живут шкафы, кронштейны, бирки, чехлы, тележки, составы для перезарядки, противопожарные полотна, сервисные запчасти и engineered suppression equipment. Сигнализация и аварийное освещение включают панели, извещатели, ручные пожарные извещатели, звонки, оповещатели, тестовое оборудование, знаки выхода, батареи и компоненты мониторинга. Спринклерное и standpipe-направление — оросители, клапаны, узлы test-and-drain, соединительные головки для пожарной техники, насосы, сигнализаторы, рукава, катушки, стволы, переходники и фитинги. Один SKU появляется в категории, поиске, подборке бренда, специальных предложениях и блоках связанных товаров, не превращаясь в дубликат товарной сущности.
Характеристики как данные, а не как текст. Класс пожара, огнетушащий агент, применимые ratings, размер, вместимость, материал, стандарты и listings хранятся структурированно. Только поэтому работают фильтры и сравнение, а layered navigation собирается из атрибутов конкретного раздела: для огнетушителей это размер, тип агента и бренд, для storage — тип шкафа, назначение и конструктивные параметры.
Поиск на два разных запроса. Индексируются SKU и model/part number, бренд и производитель, полное и сокращённое название, категория и назначение, класс пожара и агент, числовые параметры, ссылка на стандарт или сертификацию и распространённые варианты написания. Точное совпадение по артикулу получает приоритет — подрядчик, который ищет конкретный клапан, не должен пролистывать похожие позиции. Advanced Search сужает выбор сразу по нескольким полям, а покупатель, который начинает с задачи, приходит к тому же товару через категорию и фильтры.
Совместимость и граница компетенции. Пожарные системы состоят из взаимозависимых компонентов, поэтому связи compatible products, accessories, replacements и consumables — часть товарных данных, а не маркетинговый блок: они не дают собрать несовместимую конфигурацию. Там, где решение зависит от проекта, нормативов, обследования объекта или инженерного расчёта, платформа переводит покупателя к специалисту. Каталог не подменяет профессиональное проектирование и обязательную инспекцию, и это заложено в сценарий, а не написано в дисклеймере.
Розница и опт в одной системе. Customer groups разделяют публичный розничный контур и согласованные клиентские или дистрибьюторские условия, вход — через Client & Distributor Login. Права и доступные данные проверяются сервером; интерфейс не является единственным уровнем ограничения, и клиентские условия нельзя получить подстановкой чужого адреса страницы.
Заказ. Корзина хранит точный SKU, выбранную конфигурацию, количество, цену позиции, итог строки, применённую акцию и состояние доступности, а перед checkout цены, налоги, наличие и допустимые способы исполнения пересчитываются заново. Товар с обязательными опциями не попадает в корзину, пока вариант не выбран. Pick-Up Counter вынесен в отдельный способ получения с понятными инструкциями и состоянием готовности, для доставки система проверяет адрес и доступные методы. Повторная отправка формы или повторный callback платёжного провайдера не должны создавать дублирующий заказ или второе списание.
Сервис отдельным процессом. Заявка проходит собственную последовательность: первичное обращение, квалификация объекта и системы, согласование объёма, планирование, назначение исполнителя, выполнение, фиксация результата и последующая коммуникация. Коммерческий заказ и сервисная работа связаны клиентом и объектом, но имеют разные статусы, разных ответственных и разные операционные правила — смешивать их в одном заказе нельзя.
Assisted sales и тендеры. Для комплектных поставок, сложного оборудования и муниципальных закупок работают обращение в отдел продаж и раздел Supply Ontario Tender: фиксируются контакт, организация, предмет запроса и комментарий, дальше менеджер уточняет техническую задачу, совместимость, количество, адрес объекта и способ исполнения. Если задачу закрывает стандартный магазин, клиент получает согласованный состав корзины; проектные и сервисные запросы продолжаются в управляемом sales/service flow.
Целостность данных. Magento остаётся источником истины по состоянию заказа: внешние callbacks и повторные события обрабатываются идемпотентно, ошибки интеграций попадают в очередь повторной обработки и мониторинг. Массовые операции в back office проходят валидацию и формируют отчёт об ошибках — импорт с неизвестным атрибутом или дублирующим SKU не должен незаметно изменить цены и доступность каталога. Аналитика следит не только за покупками, но и за качеством навигации: поисковые запросы без результатов, использование фильтров, воронка checkout и ошибки оплаты, выбор самовывоза и доставки, источники сервисных заявок.
Результат
Получился один продукт, который одновременно продаёт оборудование и приводит заказы на профессиональные сервисы. Техническая глубина ассортимента скрыта за понятной навигацией, но профессиональные параметры, совместимость и документы остаются доступными для точного выбора: подрядчик находит позицию по артикулу, розничный покупатель приходит от задачи, корпоративный клиент повторяет закупку из истории, а сервисный заказчик попадает не в корзину, а в очередь координатора вместе со сведениями об объекте. Операционная команда ведёт каталог, заказы, клиентов, заявки и контент в одном back office, а не в нескольких несвязанных инструментах.
