Кейс: Магазин инструментов для груминга

Отрасль и клиент

Рынок и задача

Грумеру нужна машинка для стрижки, сменный нож и насадка. В каталоге эти позиции лежат в разных разделах. Карточка машинки описывает мощность и комплектацию, карточка ножа — длину среза, а совместимость приходится выяснять в переписке с консультантом. В результате покупатель собирает заказ из отдельных товаров, хотя на работе ему нужен один пригодный комплект.

Для специализированного интернет-магазина в Беларуси собрали каталог примерно на 450 товарных позиций. Основной покупатель — работающий грумер или владелец небольшого салона. Магазин хранит товары на собственном складе; данные о наличии ведёт его команда. Цель продукта — помочь выбрать инструменты под конкретную задачу, проверить документально подтверждённую совместимость связки «машинка — нож — насадка» и довести выбор до заказа.

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

Масштаб первой версии

Каталог карточек не равен пригодному комплекту: нужна рабочая среда, где задача, состав и проверка живут вместе.

Роли

Как было

Путь начинается с категории

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

История ответа остаётся в чате, а состав корзины — на сайте. У магазина нет единого объекта, который связывает задачу, выбранные товары, проверку и принятое решение.

Почему фильтров недостаточно

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

Центральная сущность сервиса — не корзина и не набор карточек, а рабочий комплект.

Решение

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

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

Как устроен новый путь

1. Покупатель начинает с задачи, например «обновить комплект для стрижки корпуса». Сервис предлагает категории инструментов и даёт добавить уже имеющуюся машинку вручную, если её модель есть в справочнике.
2. При добавлении ножа и насадки правила показывают один из трёх исходов: «Совместимость подтверждена», «Не подтверждена» или «Нужна проверка».
3. Статус «Нужна проверка» означает недостаток данных, а не обещание совместимости. Для ножниц, щёток и других товаров, где техническая связка не требуется, система не придумывает искусственную проверку.
4. Покупатель видит состав комплекта и актуальное наличие, сохраняет его и оформляет заказ. Если сочетание требует проверки, вместо обычного завершения он отправляет комплект консультанту.
5. Консультант видит конкретные модели и причину вопроса, проверяет документацию и предлагает подтверждённый вариант. Изменение состава возвращается покупателю на согласование.
6. Только согласованная версия переходит к оформлению: замена не попадает в заказ молча.

Три статуса совместимости

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

Спорную связку не красят в автоматический зелёный статус и в закупочном проекте сантехники: там формальные правила отделены от профессиональной ответственности, здесь «нужна проверка» остаётся ручной очередью консультанта.

Карточка товара и рабочее пространство

Главная публичная страница ведёт в каталог по типу инструмента и в сценарий «Собрать комплект». Категории остаются полноценными индексируемыми страницами: опытный грумер может быстро найти конкретный нож, не проходя мастер подбора. Фильтры описывают проверяемые свойства товара, а не обещают результат стрижки для каждой породы или типа шерсти.

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

Карточка товара связывает обычное описание с контекстом комплекта: технические характеристики, варианты, комплект поставки, доступность и проверенные сочетания. Если грумер пришёл из сохранённого комплекта, кнопка говорит «Добавить в комплект»; при обычном входе — «Выбрать для комплекта». У неизвестной модели нет зелёного индикатора совместимости: виден честный статус «Нет проверенных данных».

Карточка ведёт процесс, а не витрину — тот же принцип в портале заказа цветов сотрудникам: там поздравление до вручения, здесь комплект до заказа.

Очередь «Требуют проверки»

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

Очередь того, что требует действия, а не dashboard с общими числами — тот же принцип в операционном контуре сети коммерческих парковок.

Наличие, версии и повторная покупка

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

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

MVP

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

ИИ не входит в ядро MVP. В этом сценарии ошибки исходных данных опаснее, чем ручное уточнение. Импорт остатков, уведомления о возврате в наличие и расширенные подборки — следующий этап, а не обещание первой версии.

UX, стек и план

Индексируемый каталог и Livewire-комплект

Серверная выдача каталога обеспечивает доступные поисковым системам категории и карточки. Интерактивности комплекта и очереди достаточно, чтобы менять состав без отдельного frontend-приложения. Каталог остаётся входом, решение принимается в сохранённом объекте — как в подборе склада и производства по техническому паспорту.

Архитектура

Основа реализации — Laravel как модульный монолит, серверные страницы Blade, интерактивные элементы комплекта и очереди на Livewire и Alpine.js, одна база MySQL. Индексируемый каталог на Blade и Livewire, решение в объекте процесса — та же конфигурация без SPA в портале долгосрочной аренды квартир. Здесь данные в MySQL, фотографии хранятся вместе с приложением.

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

Пилот по одной категории

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

Метрики

Целевые показатели пилота сравниваются с замером аналогичных заказов до запуска. Для первой оценки берётся выборка из 30 последовательных комплектов до запуска и 30 после, отдельно отмечая случаи, в которых данных о совместимости недостаточно. Такая выборка покажет сбои сценария, но не даст оснований объявлять устойчивый эффект для всего магазина.

В первой итерации важнее увидеть сбои маршрута: где справочник врёт, где очередь обходится чатом и где состав меняется после согласия покупателя.

Риски и выводы

Риски

Как меняется продажа

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