Омниканальная платформа: как объединить клиентов, заказы и остатки
Покупатель оплатил товар на сайте и приехал за ним в магазин. Продавец не видит заказ, товар уже отложен другому человеку, а поддержка просит заново назвать состав покупки. У компании есть несколько каналов продаж, но переход между ними приходится организовывать самому клиенту.
Омниканальная платформа нужна, чтобы этот переход работал как единый процесс: заказ сохранял историю, товар был доступен для выбранного способа получения, а сотрудник понимал, какое действие уже выполнено. Ниже — решения, которые стоит согласовать до разработки.
Что объединяет омниканальная платформа
В этой статье омниканальность — возможность начать покупку в одном канале и продолжить в другом без повторного оформления. Например, выбрать товар в приложении, получить его в магазине и обратиться в поддержку по тому же заказу.
Для такого сценария недостаточно общего дизайна сайта и приложения. Нужны связанные данные о клиенте, заказе и запасах, а также правила, по которым системы принимают решения.
Показательный пример готового механизма — маршрутизация заказов в Shopify. Система выбирает точки исполнения по заданным правилам: учитывает возможность собрать покупку без разделения и близость к получателю. Само подключение магазинов такую логику не заменяет.
Единый профиль начинается с правил идентификации
Сначала стоит определить, как сайт, приложение, касса и поддержка узнают одного покупателя. Практический вариант — постоянный внутренний идентификатор клиента и таблица его соответствий аккаунтам в других системах. Телефон и электронная почта служат контактами, но не должны безусловно заменять этот идентификатор.
При проектировании нужно предусмотреть гостевую покупку, смену номера и несколько аккаунтов одного человека. Например, заказ без регистрации можно привязать к профилю после подтверждения доступа к контакту. Совпадение имени само по себе не должно открывать чужую историю покупок.
Объединение дублей лучше сделать отдельной операцией с журналом и возможностью исправить ошибку. Параллельно стоит ограничить доступы по ролям: продавцу нужны состав заказа и условия выдачи, поддержке — обращения и история действий, маркетологу — разрешённые для его задач данные. Общий профиль не означает общий доступ ко всему.
У заказа один номер, но несколько независимых состояний
Для заказа полезно сохранить постоянный внутренний номер и связанные номера в кассовой системе, ERP и службе доставки. ERP — система учёта ресурсов и операций компании. Такое соответствие позволяет найти одну покупку во всех сервисах, даже если они используют разные обозначения.
Статусы оплаты, сборки и получения следует вести отдельно. «Оплачен» не означает «готов к выдаче», а «передан в магазин» не подтверждает получение покупателем. У каждой смены состояния нужен источник: платёжный сервис, склад или сотрудник точки выдачи.
Для сценария самовывоза стоит заранее описать отмену после оплаты, замену магазина, частичную выдачу и истечение срока хранения. Это отдельные ветки процесса, а не комментарии к основному статусу. Если магазин не подтвердил наличие, покупателю нельзя отправлять сообщение «можно забирать» только потому, что сайт успешно создал заказ.
Рядом с текущим состоянием полезно показывать ожидаемое действие и ответственного: «магазин подтверждает резерв», «сотрудник готовит выдачу», «возврат платежа ожидает подтверждения». Так поддержка сможет объяснить задержку без звонков во все подразделения.
Общий остаток не равен всему товару на полках
На складе могут одновременно находиться свободные товары, резервы по заказам и позиции на проверке. В документации Shopify эти состояния разделены: физическое наличие включает доступное, закреплённое за операциями и недоступное количество. Товар в пути учитывается отдельно.
Для собственного проекта можно принять правило: доступно к продаже = физическое наличие − действующие резервы − недоступные позиции − страховой запас. Здесь все вычитаемые категории должны быть непересекающимися. Если исходная система уже передаёт свободный остаток, повторно вычитать из него резервы нельзя.
Расчёт нужно вести в одинаковых разрезах: товар, вариант, склад и при необходимости владелец или партия. Пять единиц одного размера не заменяют пять единиц другого. Наличие в магазине тоже не всегда означает возможность отправить оттуда заказ: точка может обслуживать только самовывоз.
Отдельное решение — кто подтверждает резерв. Если касса и сайт независимо продают последнюю единицу по своим копиям остатков, даже частый обмен оставляет риск конфликта. Для дефицитных позиций стоит предусмотреть общий механизм резервирования либо заранее распределённые квоты каналов. Страховой запас снижает риск, но не заменяет эти правила.
У каждого вида данных должен быть ответственный источник
До выбора технологий полезно составить карту владения данными. В ней фиксируют не только название системы, но и операцию, которую она вправе подтверждать. Возможный вариант распределения:
- CRM хранит профиль клиента и историю обращений.
- ERP или товарная система отвечает за номенклатуру и базовые цены.
- WMS — система управления складом — подтверждает складские операции и физическое наличие.
- Система управления заказами выбирает точку исполнения и связывает оплату, резерв и выдачу.
Это пример, а не обязательный набор продуктов. В небольшом бизнесе несколько функций может выполнять одна система. Важно, чтобы цена или резерв не менялись независимо в трёх местах без согласованного приоритета.
Интеграционный слой в такой схеме переводит форматы, сохраняет соответствия номеров и отслеживает доставку сообщений. Ему не стоит незаметно дублировать правила скидок или расчёт доступного остатка. Иначе бизнес будет менять условия в основной системе, а часть каналов продолжит работать по старой формуле.
Обмен должен переживать повтор и потерю подтверждения
Проектировать интеграцию стоит с учётом повторных сообщений. Например, Amazon SQS допускает повторную доставку в стандартных очередях. Для покупки это означает конкретное требование: повтор события не создаёт второй заказ и не уменьшает запас ещё раз.
Другая ситуация: заказ сохранился, но уведомление складу не отправилось. Для такого разрыва есть паттерн transactional outbox: изменение и запись о необходимой отправке сохраняются в одной транзакции. Дальше отдельный обработчик доставляет сообщение. Приёмнику всё равно нужна защита от дублей.
Помимо событий полезна периодическая сверка. Она должна сравнивать конкретные заказы и остатки, находить пропуски и передавать неразрешимые расхождения сотруднику. Одной надписи «обмен работает» недостаточно: нужны время последнего подтверждённого обновления, число ошибок и самая старая незавершённая операция.
Как внедрять платформу без замены всех систем
Первый релиз разумно ограничить одним переходом между каналами — например, покупкой на сайте с выдачей в нескольких магазинах. Для него понадобятся идентификация клиента, доступность по точкам, подтверждение резерва, уведомление о готовности и фиксация выдачи. Остальные сценарии можно добавлять после проверки этой цепочки.
Готовое решение стоит проверять на реальных исключениях: отмене оплаченного заказа, переносе выдачи, частичном получении и недоступности кассы. Собственный модуль имеет смысл обсуждать, когда эти операции не укладываются в штатные механизмы. Начинать с полной замены ERP только ради единого интерфейса необязательно.
До запуска стоит зафиксировать долю отмен из-за отсутствия товара, время подтверждения самовывоза и число ручных переносов заказов. После пилота сравнить показатели для сопоставимых точек и периодов. Такой результат полезнее количества подключённых API: он показывает, стал ли переход между каналами надёжнее.
У Qtim направление e-commerce и маркетплейсов включает интеграции с учётными системами, складами и платежами. Обсудить существующую схему и нужный покупательский сценарий можно в Telegram.
