Продажи разъехались по каналам, а инфраструктура осталась прежней

Сайт давно перестал быть единственной точкой продаж. Рядом маркетплейсы, мобильное приложение, Telegram, соцсети. Покупатель свободно ходит между ними: смотрит товар на площадке, спрашивает в мессенджере, оформляет на сайте.

А инфраструктура под этим осталась в логике одного канала. Каталог живёт в CMS, клиенты — в CRM, аналитика собирается отдельно, остатки лежат в учётной системе. Каждый сервис по отдельности работает нормально. Ломается то, что между ними.

Стоимость прячется не в лицензиях, а в стыках

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

  • Поддержка интеграций: каждая пара систем — отдельный обмен, который ломается при обновлении любой из сторон.
  • Ручные операции там, где обмена нет: выгрузки, сверки, перезаливка остатков руками.
  • Расхождения данных: цена обновилась на сайте и не доехала до площадки, заказ есть в CRM и отсутствует в учёте.
  • Время на выяснение, какая система права, когда цифры не сошлись.

Эти статьи не попадают в смету на старте, но именно они определяют стоимость владения через год-два. И растут они не линейно: каждый новый канал добавляет не одну связь, а несколько.

Скорость проверки гипотез упирается в ту же архитектуру

Современная розница живёт экспериментами: комплект к выходным, кэшбэк на категорию, бонус за второй заказ. Ценность такой механики — в скорости запуска, пока гипотеза актуальна.

В разрозненном стеке простая акция превращается в проект: настроить в одной системе, продублировать в другой, проверить, что лояльность посчиталась, убедиться, что на витрине отобразилась верная цена. Между идеей и запуском встают недели и подрядчики.

Архитектура перестаёт быть внутренним техническим вопросом в тот момент, когда она начинает определять, сколько гипотез бизнес успевает проверить за квартал.

Что означает «единый контур данных» на практике

Формулировка звучит абстрактно, поэтому переведём её в конкретные свойства системы. Единый контур — это когда выполняются четыре вещи.

  • У каталога один источник правды. Товар заводится один раз, а каналы получают его со своими ценами, описанием и видимостью — не копией карточки, а публикацией из общей модели.
  • Заказ из любого канала попадает в один список с общими статусами, оплатой и доставкой.
  • Клиент остаётся одним человеком, а не четырьмя записями: история покупок, баллы и сегменты считаются по всем каналам сразу.
  • Акции и лояльность настраиваются в одном месте и действуют там, где вы указали, — включая правило «на этой витрине действует, на той нет».

Так устроен Skuby: PIM в основании, каналы поверх него, заказы, промо, лояльность и аналитика в той же модели данных. Маркетплейсы подключаются при внедрении как ещё один тип канала — не отдельным коннектором сбоку, а через тот же механизм публикации.

Единый контур — условие для ИИ, а не следствие

Про ИИ в рознице говорят так, будто это надстройка, которую можно докупить. На деле ассистент бесполезен без доступа к актуальному каталогу, остаткам, истории клиента и действующим акциям. Если данные размазаны по пяти системам, сначала придётся построить интеграционный слой, и только потом появится предмет для разговора.

Поэтому порядок обратный привычному: сначала общий контур данных, потом ИИ поверх него. В Skuby этот шаг уже сделан на уровне доступа — административный API целиком опубликован по протоколу MCP, то есть систему можно подключить к тому ИИ-ассистенту, которым вы пользуетесь. Готового агента-продавца мы при этом не продаём и сроков по нему не называем.

С чего начать, если переезжать прямо сейчас не готовы

Полная миграция — не единственный вариант. Есть три шага, которые окупаются независимо от того, на какой системе вы в итоге останетесь.

  • Определите единый источник правды для каталога и зафиксируйте, кто и где меняет товарные данные.
  • Уберите ручные операции из критичного пути: остатки, цены и статусы заказов не должны переноситься копипастом.
  • Начните собирать цельный профиль клиента, даже если пока в отдельной системе, — потом его будет чем наполнять.

Это та работа, которую всё равно придётся сделать. Разница только в том, делаете вы её один раз при переходе на единую платформу или каждый раз заново при добавлении очередного сервиса.