Омниканал без точки правды: почему ритейлеры продолжают спорить с собственным CRM

Омниканал без точки правды: почему ритейлеры продолжают спорить с собственным CRM

За последние два года я пересмотрел десятки проектов по интеграции офлайна, сайта и приложения в единый контур. И почти в каждом — одна и та же трещина. Маркетинг, коммерция и ИТ честно пытаются договориться о «едином профиле клиента», но упираются в старый спор: чья база главнее — CRM (система управления отношениями с клиентами), DMP (платформа управления данными) или CDP (клиентская платформа, объединяющая данные из всех источников). В итоге омниканал существует на уровне концепции, а клиент продолжает видеть три разных истории о себе.

Ниже — разбор, почему это происходит и как компании, которые прошли этот путь, выстраивали связку на практике. Без магии и без «просто купите платформу».

**Раздел 1. Омниканал — это не интеграция, а право владеть клиентом**

Когда ритейлер говорит «у нас омниканал», чаще всего речь идёт о технической интеграции: обмен событиями между сайтом, мобильным приложением, розничным кассовым ПО и колл-центром. Это инфраструктурный слой, без него действительно ничего не работает. Но это лишь фундамент.

Настоящий омниканал начинается там, где компания отвечает себе на неудобный вопрос: кто в организации имеет право окончательно решать, что мы знаем о клиенте. Исторически эти права делятся между маркетингом (которому нужна сегментация для кампаний), коммерцией (у которой сделки и выручка) и ИТ (которое владеет инфраструктурой и хранением). Каждый тянет «золотую запись» клиента в свою сторону. Доходит до абсурда: маркетинг видит один e-mail, коммерция другой, колл-центр — третий, и все три системы при этом «правильные» с точки зрения своих владельцев.

Характерный пример — крупная федеральная сеть одежды, с которой я работал. Год ушёл на интеграцию онлайна и офлайна по событийной модели, и ещё полгода на то, чтобы согласовать, чей профиль клиента считать эталонным. Точкой перелома стала не технология, а решение CEO (генерального директора): «золотой» записью объявляется CDP, маркетинг получает инструменты влияния, коммерция — сохранённый доступ к своим сделкам, но без права перезаписи базовых атрибутов. До этого решения проект буксовал девять месяцев.

**Раздел 2. Single View (единая карточка клиента) перестал быть самоцелью**

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

Здесь важно различать два подхода. Первый — дедуктивный: компания заранее проектирует десятки атрибутов, прописывает правила слияния, строит витрины (структурированные представления данных для аналитиков и маркетинга). Подход красивый, но тяжёлый: к моменту запуска половина гипотез уже устарела. Второй — индуктивный: запускается базовая CDP, но команда заранее договаривается о пяти-семи ключевых сценариях, ради которых всё и строится. Например: триггерное предложение после покупки в офлайне, прогноз оттока, персонализация главной страницы приложения, сегментация для офлайн-рассылки, дашборд для коммерции по LTV (пожизненной ценности клиента). Атрибуты рождаются под сценарии, а не наоборот.

Пример: продуктовая сеть из регионов не стала сразу «строить 360». Взяли три сценария — реактивация «уснувших» клиентов через push в приложении после визита в офлайн, кросс-категорийный апсейл (предложение дополнительных товаров из смежных категорий) и оценка вклада офлайна в онлайн-выручку. Под эти сценарии настроили событийную модель, согласовали словари, связали CRM и CDP. Через четыре месяца получили измеримый эффект: реак

— @OmnichannelCraft