Омниканальный мультирезерв для «Снежной Королевы»: объединение e-com и розницы

Главное о кейсе

У «Снежной Королевы» была отключена функция бронирования товара в магазине. Причина — конфликт учета: при примерке клиент мог заменить товар, старый заказ отменялся, новый учитывался как розничный. E-commerce терял вклад в продажу, метрики искажались.

4 года выкуп в магазине был недоступен. Это снизило внутреннюю конкуренцию, но ухудшило пользовательский опыт и конверсию.

Мы разработали модуль мультирезерва: заказ оформляется онлайн, может быть изменен в магазине, а финальная продажа корректно учитывается одновременно в e-commerce и рознице.

Компания вернула формат «забрать в магазине» без конфликта метрик и потери управляемости.

Как проект изменил жизнь пользователей

Клиенты → Могут примерить, заменить размер или модель и добавить новые товары → без повторного заказа и ожидания доставки.

E-commerce команда → Получает корректный учет вклада в продажу → прозрачная аналитика каналов.

Розничные магазины → Не конкурируют с онлайн-каналом → работают в единой омниканальной модели.

Бизнес в целом → Повышает конверсию и средний чек без внутреннего конфликта.

Бизнес-задача и ее решение

Бизнес-задача: вернуть бронирование в магазине, сохранив корректный учет продаж между онлайн и розницей.

Как решили:
— Разработали новый модуль мультирезерва на PHP + Magento.
— Интегрировали OMS и 1С:Розница с двусторонним обновлением статусов.
— Переработали логику учета, чтобы изменения заказа в магазине сохраняли принадлежность к онлайн-каналу.

Результат:
— Восстановлен канал «забрать в магазине» после 4 лет отключения.
— Заказ можно изменять без потери атрибуции.
— Устранен конфликт интересов между департаментами.

Крафт (мастерство), реализация, технические детали

1. Полный пересбор модуля → отказ от legacy → контроль логики учета
Старый модуль не масштабировался. Новый функционал написан с нуля.

2. Сквозная интеграция OMS ↔ 1С ↔ онлайн-магазин → целостность данных
Заказ создается онлайн, изменяется в магазине, финальный статус возвращается в e-com.

3. Плавная миграция → отсутствие сбоев
На переходный период дублировали логику резерва и мультирезерва, затем полностью перевели поток на новую модель.

4. Защита от злоупотреблений → контроль повторных резервов
Предусмотрен механизм ограничения количества повторных броней для предотвращения блокировки товара.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

Инсайт 1: проблема была не в функции бронирования, а в модели учета продаж.
→ Переработали логику атрибуции.
→ Устранили конфликт между каналами.

Инсайт 2: омниканальность невозможна без синхронизации IT-систем.
→ Построили двусторонний обмен через OMS.
→ Обеспечили целостность заказа на всем жизненном цикле.

Инсайт 3: пользовательский опыт напрямую влияет на конверсию.
→ Вернули примерку и корректировку заказа в магазине.

Скриншоты