Клиент оформил заказ, магазин подтвердил наличие, оплата прошла. Когда покупатель приехал за товаром, последнюю доступную единицу уже продали через обычную кассу.
Проект охватывал несколько брендов и более 800 магазинов, включая франчайзинговые. Каждый месяц компания разбирала сотни заказов, в которых клиент не мог получить уже оплаченный товар. Еженедельно появлялись десятки негативных отзывов.
Возврат не происходил автоматически. Несколько сотрудников проверяли платеж, связывались с покупателем, оформляли документы и контролировали возврат денег. Один несостоявшийся заказ создавал работу сразу для магазина, e-commerce, поддержки и финансовой службы.
Ошибок в отдельных системах при этом могло не быть. Сайт принимал заказ, магазин подтверждал остаток, платежный сервис списывал деньги, касса проводила чек.
Проблема находилась между ними: онлайн-заказ никак не менял возможность продать тот же товар в магазине.
Почему подтверждение магазина не защищало заказ
Раньше мы не брали деньги, пока торговая точка не подтвердит наличие.
В магазин поступала задача. Продавец искал нужный артикул в торговом зале, подсобном помещении или на складе и только после этого подтверждал заказ. Иногда проверка занимала полчаса, иногда несколько часов.
Все это время клиент не мог оплатить покупку. Пока магазин проверял остаток, человек успевал передумать, найти товар у конкурента или просто закрыть страницу.
Чтобы убрать ожидание, оплату разрешили проводить сразу после оформления заказа. Пауза перед платежом исчезла, но компания по-прежнему не могла гарантировать выдачу.
Если магазин не находил товар, приходилось запускать возврат. Вместо продажи компания получала обращение в поддержку, ручную работу сотрудников и клиента, который уже расстался с деньгами, но не получил покупку.
Еще хуже работал сценарий, когда магазин успевал подтвердить наличие.
Продавец находил нужный артикул и менял статус заказа. Клиент оплачивал покупку, однако товар продолжал лежать в торговом зале, а касса считала его свободным.
Другой покупатель мог взять последнюю единицу с полки и купить ее раньше, чем онлайн-клиент приезжал за заказом.
С точки зрения участников процесса никто не ошибся. Магазин нашел и подтвердил товар. Платежный сервис принял деньги. Кассир провел разрешенную операцию.
В итоге мы обещали один товар двум людям.
Первый забирал его на кассе. Второй приезжал за уже оплаченным заказом и узнавал, что товара больше нет.
Ручное подтверждение меняло статус заказа, но ничего не резервировало физически.
Онлайн-заказ должен был остановить кассу
В архитектуру проекта я заложил обязательную связь между OMS и кассовой системой: если товар забронирован или оплачен онлайн, продать эту единицу через другой канал нельзя.
После создания заказа OMS передавала блокировку на кассу, а магазин получал задачу снять товар с полки и подготовить его к выдаче. При попытке провести заблокированную позицию касса запрещала продажу и показывала причину: товар зарезервирован по онлайн-заказу.
Для неоплаченной брони установили срок 30 минут. Если клиент не завершал платеж, OMS автоматически снимала ограничение, и касса снова могла продать товар.
Оплаченный заказ оставался заблокированным до выдачи покупателю.
Так онлайн-заказ впервые начал управлять не только статусом на сайте, но и реальной продажей в магазине. Одновременно появилась новая операция, которой раньше не существовало: продавец должен был быстро найти товар и убрать его из торгового зала.
Ни интеграция, ни кассовая блокировка не могли сделать это за человека.
Поэтому решение сначала запустили в 30 магазинах. Нужно было проверить не только обмен статусами, но и то, как новый процесс работает в обычной смене, среди покупателей, очередей и текущих задач продавцов.
Касса сработала. Товар остался на полке
Пилот довольно быстро показал следующий разрыв.
OMS блокировала товар корректно, но сотрудники не всегда успевали снять его с полки. Покупатель видел доступную позицию в торговом зале, приносил ее на кассу и только там узнавал, что купить товар нельзя: его уже забронировал или оплатил онлайн-клиент.
Для кассы это была штатная блокировка. Для человека у кассы - отказ продать товар, который он уже выбрал.
Попытки провести заблокированную позицию стали отдельным контрольным сигналом. По ним было видно, что задача дошла до магазина, касса получила ограничение, а физическая операция не была выполнена вовремя.
На снятие товара с полки установили SLA 15 минут. OMS фиксировала, когда магазин получил задачу, когда сотрудник начал сборку и когда заказ был готов к выдаче.
Сам SLA ситуацию не изменил. У продавца появилась дополнительная операция, которая конкурировала с работой в торговом зале, но почти не влияла на результат магазина и личный доход сотрудника.
На проектном комитете мы оставили архитектуру без изменений и пересобрали мотивацию розницы.
Онлайн-заказы включили в план торговой точки. Сотрудник начал получать личный бонус за сборку и выдачу, а скорость обработки вошла в KPI и стала влиять на премию.
При выдаче заказа магазин также мог сделать допродажу на кассе.
После этого продавец видел не просто новую задачу в терминале. За ней стояли выручка точки, выполнение плана и его собственные деньги.
Как e-commerce встроили в экономику магазина
Онлайн-заказ засчитывался в результат той точки, которая собирала и выдавала товар. Магазин больше не обслуживал продажу, которая существовала только в отчетности e-commerce.
Те же правила действовали и во франчайзинговых магазинах.
Единый клиентский сервис был закреплен в условиях франшизы: покупатель не должен был замечать, кому юридически принадлежит конкретная точка. Для него это один бренд, один сайт и одно обещание получить оплаченный товар.
При этом исполнение не держалось только на договоре. Онлайн-заказ входил в план партнерского магазина, сотрудник получал бонус за сборку и выдачу, а визит клиента создавал возможность для допродажи. Для франчайзи это была продажа его точки, а не бесплатная обработка заказа головной компании.
Зоны ответственности разделили заранее. E-commerce управлял заказом и разбирал отклонения, розница отвечала за работу магазинов и мотивацию сотрудников, ИТ - за архитектуру и обмен статусами между OMS и кассами.
Отдельно настроили работу с бронями, которые клиент не оплатил.
Неоплаченная бронь жила 30 минут, после чего OMS снимала кассовую блокировку. Если продавец уже убрал товар из торгового зала, он получал задачу вернуть его на полку.
На возврат давали еще 30 минут. Затем включалась эскалация, а просрочка отражалась в KPI и премии.
Без этой операции система снова расходилась бы с реальностью: по данным OMS товар доступен для продажи, но физически он продолжает лежать в зоне сборки среди отмененных заказов.
Поэтому отслеживали весь путь единицы товара: создать резерв, снять с полки, собрать заказ, выдать покупателю либо вернуть в продажу после отмены.
Оставался еще один источник ошибок - расхождение между учетным и физическим остатком. Товар мог быть поврежден, лежать не на своем месте или отсутствовать при положительном остатке в системе.
Раньше об этом часто узнавали, когда клиент уже приезжал за оплаченным заказом. После запуска OMS отклонение сразу попадало в работу команды e-commerce.
Сотрудники проверяли остатки в других точках, переносили место выдачи, связывались с покупателем или запускали возврат до его приезда. Во многих случаях заказ удавалось сохранить, просто отправив его в другой магазин.
У проблемного заказа появился конкретный владелец. Магазин больше не оставался один на один с клиентом, которому нечего выдать, а несколько подразделений не начинали разбирать ситуацию постфактум.
Полный процесс сначала отладили на 30 магазинах. Только после этого его распространили на всю сеть из 800+ точек.
Результат за шесть месяцев
Количество ситуаций, когда клиент оплатил заказ, но не смог получить товар, сократилось более чем на 97%.
Скорость обработки выросла в четыре раза - на 300%. Основной поток больше не ждал ручного подтверждения магазина перед оплатой.
За первые шесть месяцев после запуска количество онлайн-заказов выросло на 50% относительно предыдущего полугодия. Онлайн-выручка увеличилась сопоставимо.
Рост подтвердился и при сравнении год к году. Рекламный бюджет и промоактивность в сопоставимых периодах существенно не отличались, а главным изменением в процессе онлайн-продаж стали OMS и новая модель работы магазинов.
Инвестиции в запуск составили около 12 млн рублей. В эту сумму вошли лицензии и проект внедрения. Новые серверы и оборудование покупать не пришлось - использовали имеющиеся мощности.
Совокупный финансовый эффект за первые шесть месяцев превысил 36 млн рублей. В расчет вошли маржинальный доход от сохраненных и дополнительных заказов, а также снижение затрат на ручную обработку возвратов.
ROI считали за тот же шестимесячный период по классической формуле: финансовый эффект за вычетом затрат, деленный на затраты. Он превысил 200%.
Касса научилась блокировать повторную продажу за несколько секунд.
Чтобы товар исчезал с полки за 15 минут, пришлось менять план магазина и премию продавца.