Как мы проектировали омниканальную программу для ВинЛаб
Омниканальность в крупной розничной сети — это не просто сайт, мобильное приложение и магазины. Это способность компании управлять клиентским опытом, ценами, акциями, остатками, купонами, персональными предложениями и коммуникациями как единой системой. Для ВинЛаб задача особенно сложная из-за масштаба бизнеса. Сеть включает более 2100 магазинов, одновременно может действовать более 80 различных акций, при этом промо-механики отличаются по регионам, магазинам, клиентским сегментам, категориям товаров, каналам коммуникации и условиям применения. В такой модели нельзя рассматривать eCommerce, магазины, кассы, мобильное приложение, CDP, программу лояльности и маркетинг как отдельные системы. Они должны работать в едином контуре. Главная цель программы омниканальности — сделать так, чтобы клиент видел корректную цену, актуальную скидку, доступный купон, реальные остатки по магазину и персональное предложение, а бизнес при этом понимал, какая акция сработала, какой канал привёл к покупке, как изменилась частота покупок, средний чек и клиентская база.
В чём была ключевая проблема При масштабе 2100+ магазинов и десятках параллельных промо-механик возникает не одна проблема, а целый набор связанных между собой рисков. Клиент может увидеть товар в мобильном приложении, получить персональный купон, выбрать магазин, проверить остаток, прийти в точку продаж и ожидать, что на кассе применится та же цена и скидка, которые были показаны в цифровом канале. Но чтобы этот сценарий работал, должны синхронно отработать сразу несколько систем:
каталог товаров; цены; акции; промокоды; купоны; программа лояльности; остатки по магазинам; резерв товара; кассовое ПО; мобильное приложение; CDP; маркетинговая автоматизация; аналитика; прогноз продаж https://contrend.ru/
Если эти контуры не связаны, клиентский опыт начинает ломаться. В приложении может быть одна цена, на кассе другая. Купон может быть показан клиенту, но не примениться при покупке. Акция может быть активна в маркетинговой коммуникации, но не поддержана остатками в конкретном магазине. Товар может быть показан как доступный, хотя фактически он уже продан или зарезервирован. Для клиента это выглядит как плохой сервис. Для бизнеса — как потерянная продажа, рост обращений, неэффективная скидка и невозможность точно оценить результат промо. 3. Целевая архитектура решения Целевую архитектуру мы разделили на несколько слоёв. Каналы продаж и сервиса В этот слой входят сайт ВинЛаб, мобильное приложение, магазины, POS/кассы, контакт-центр, маркетинговые каналы и партнёрские каналы. Это точки, где клиент видит предложение, выбирает товар, использует купон, оформляет заказ, забирает покупку или обращается за поддержкой. API / Edge Этот слой отвечает за безопасный и управляемый доступ к backend-сервисам. В него входят:
WAF/CDN; API Gateway; BFF Web; BFF Mobile; IAM/Auth; Consent Service.
API Gateway управляет маршрутизацией, авторизацией и лимитами. BFF Web и BFF Mobile собирают данные под конкретный клиентский интерфейс, чтобы сайт и приложение не обращались напрямую к десяткам внутренних систем. Микросервисы ВинЛаб Это слой собственной разработки, где находится уникальная бизнес-логика eCommerce и омниканальности.
Роль CDP в программе омниканальности CDP — это не просто маркетинговая база. Для ВинЛаб CDP становится центром клиентского контекста. CDP собирает данные из разных источников:
сайт; мобильное приложение; кассы; магазины; программа лояльности; купоны; акции; заказы; резервы; контакт-центр; маркетинговые коммуникации; DWH; Kafka/Event Bus.