Поиск по артикулу на inSales: зачем B2B-магазину live-панель

В B2B и оптовых витринах клиент редко печатает «синяя куртка XL». Он печатает код: то, что стоит в прайсе, в 1С, на этикетке склада. Если поиск магазина «не понимает» артикул, путь к заказу обрывается на шапке — ещё до карточки и корзины.

Ниже — зачем нужен поиск по SKU на inSales, чем он отличается от поиска «по красивому названию», и когда live-панель с артикулом в выдаче имеет смысл. Без обещаний Elastic и без кейсов с чужих платформ.

Сравнение форматов поиска (dropdown vs панель) — в статье AjaxSearch vs live-поиск. Здесь один сценарий: код в голове клиента.

Типичные роли:

• закупщик по Excel-прайсу или каталогу поставщика;
• менеджер, который повторяет заказ «как в прошлый раз» по коду;
• оптовый клиент, у которого SKU совпадает с внутренней номенклатурой;
• B2C с сильным SKU-брендингом (запчасти, расходники, техника), где модель = код.

Им не нужна «умная семантика». Нужен матч по коду и быстрая проверка: это та позиция, та цена, то наличие.

Штатный AjaxSearch на inSales — dropdown под полем. Он хорош для подсказок по названию. Для артикула ограничения обычно такие:

1. Что индексируется. Если SKU лежит в поле варианта, а тема/индекс подсказывает в основном title — код «не видят».
2. Мало места в UI. Даже при матче в dropdown трудно сразу сверить фото, цену и «тот ли это вариант».
3. Ложный «пустой» ответ. Клиент решает, что товара нет, хотя он есть — просто запрос не попал в то поле, которое dropdown умеет.

Итог для магазина: повторные звонки «почему не находит код», уход в мессенджер, ошибки в заказе. Это не «плохой AjaxSearch» — это не тот формат, когда основной интент — SKU.

Live-поиск DanForge открывает полноэкранную панель (своя сцена по CSS-триггерам; ядро AjaxSearch не вырезается). В выдаче покупатель видит:

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

Для B2B это значит: запрос «как в прайсе» → сразу витринная проверка → карточка или следующий код. Меньше циклов «напечатал → пусто → ушёл в WhatsApp».

Честно: качество матча зависит от того, как заполнены артикулы в каталоге inSales. Панель не создаёт SKU из воздуха и не заменяет нормализацию данных в админке.

Смотрите на долю запросов, а не на «красоту шапки».

Если 3–5 реальных запросов с вашего прайса в штатном поиске дают пустоту или неверный товар — это уже аргумент смотреть панель, а не «ещё один редизайн иконки лупы».

1. Возьмите 5–10 артикулов из прайса, которыми реально пользуются клиенты.
2. Введите их в текущий поиск шапки (как покупатель).
3. Зафиксируйте: нашёл / нашёл не то / пусто.
4. Откройте карточку «правильного» товара и сверьте, где лежит SKU (товар / вариант).
5. Если пустоты и промахи повторяются — проблема не в «лени клиента», а в UX/индексе поиска.

Демо live-панели и пакеты установки — на странице модуля (ссылка ниже). Сверяйте свои коды, не чужой каталог.

«Достаточно ли заполнить артикул в карточке?»
Нужно, чтобы код был в данных, которые поиск реально использует (часто — SKU варианта). Заполненный «где-то в описании» текст не всегда попадает в suggestions.

«Live-поиск заменяет AjaxSearch?»
Нет как факт ядра темы. Панель — отдельный UX поверх триггеров. Подробнее — в сравнении AjaxSearch vs live-поиск.

«Нужен Elastic?»
Для типичного сценария «найти код и увидеть цену/фото» чаще не хватает понятной панели и корректных SKU в каталоге, а не отдельного поискового движка. Elastic/AI в продукте DanForge нет — и мы его не обещаем.

Если ваш магазин живёт запросами по артикулу — следующий шаг: посмотреть, как live-панель показывает SKU, фото и цену, и какие пакеты установки есть под вашу тему.

Подключить поиск с SKU →

На странице модуля: лицензия и установка под ключ, настройки админки, актуальные пакеты (от 5 000 ₽). Совместимость Gen-2 / Gen-4 — уточняйте у DanForge с ссылкой на ваш магазин.