Когда e-commerce становится бизнес-системой

Розница, опт и партнёрские каналы в одной архитектуре.

Момент, когда одна витрина начинает обслуживать розничных клиентов, оптовых покупателей и dropshipping или реселлер-партнёров одновременно, она начинает вести себя как три бизнеса, что просто делят каталог. Большинство реальной инженерной сложности в этом переходе не имеет ничего общего с добавлением страницы опта или логина партнёра. Она в частях, которых никто не видит на витрине: логика ценообразования, распределение инвентаря, маршрутизация заказов, и кого CRM реально считает клиентом.

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

ВИТРИНА НЕ СИСТЕМА

Витрина больше не система

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

ТРИ МОДЕЛИ ТРАНЗАКЦИЙ

Три канала, три модели транзакций

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

Естественный инстинкт, это прикрутить оптовый раздел к существующему розничному магазину, отдельная страница, поле минимального количества заказа, защищённый паролем просмотр каталога. Это решает видимую проблему и создаёт три невидимые. Движок ценообразования теперь должен знать, какая цена применяется к какому посетителю, не только какая цена на товаре. Система инвентаря должна резервировать или распределять сток по-разному в зависимости от того, какой канал из него тянет. И система управления заказами должна маршрутизировать выполнение по-разному, отправлять со склада для розницы, генерировать заказ на закупку для поставщика dropship-партнёра, применять условия нетто-30 для оптового аккаунта, всё из того, что выглядит как та же кнопка «оформить заказ» для клиента.

ЦЕНООБРАЗОВАНИЕ ЛОГИКА

Ценообразование, это логика аккаунта, не скидка

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

РАСПРЕДЕЛЕНИЕ ИНВЕНТАРЯ

Инвентарь, это модель распределения, не число

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

РАЗНЫЕ ФОРМЫ ЗАКАЗОВ

Заказам нужны разные формы

Каждая строка в этой таблице, это фактически другой тип заказа, и система, что имеет лишь одну концепцию «заказа», будет продолжать заталкивать все три в ту же форму, пока что-то не сломается, обычно оптовый счёт без способа представить условия оплаты, или dropship-заказ без поля, какому партнёру он принадлежит.

КЛИЕНТ НЕ ЛОГИН

Клиент больше не просто логин

Как только существует несколько каналов, модель аккаунта должна представлять нечто сложнее одного человека с одной почтой. Розничный аккаунт обычно всё ещё прямые отношения человек-аккаунт. Оптовый аккаунт часто компания, с несколькими пользователями, что делят кредитную линию и коммерческие условия, что принадлежат аккаунту, не любому отдельному покупателю внутри него. Реселлер или партнёрский аккаунт добавляет ещё один слой, партнёрская сущность с собственными пользователями, собственным ценовым соглашением, и собственными отношениями выполнения с бизнесом. Реальный вопрос под всем этим, и тот, что стоит задать до того, как что-то из этого построено, простой для формулировки и лёгкий для ошибки: что именно является «клиентом» в этой системе, и меняется ли ответ по каналу. Именно этот паттерн разобран со стороны систем в кастомной CRM против ERP, как только e-commerce охватывает несколько каналов, CRM и витрина должны согласовать общую, согласованную модель того, чем реально является аккаунт, или бизнес закончит с тремя несовместимыми определениями «клиента», что живут в трёх разных местах.

ОДИН КАТАЛОГ МНОГО ЛИЦ

Один каталог, много лиц

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

Каталог должен иметь один источник правды и много лиц, не много источников правды, что носят тот же логотип.

ПАРТНЁРСКИЙ СЛОЙ ПРОДУКТ

Партнёрский слой, это собственный продукт

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

КОГДА ЧТО-ТО НЕ ТАК

Что происходит, когда что-то идёт не так

Исключения, это где незрелая мультиканальная архитектура становится видимой быстрее, чем где-либо. Розничный возврат обычно простой, вернуть средства на карту, пополнить запас товара. Оптовый возврат редко такой чистый, это может быть частичный возврат против большего заказа, кредит, применённый к будущему счёту вместо немедленного возврата средств, или согласованная плата за пополнение запаса, которой поток возврата розницы вообще не имеет концепции. Dropship-спор другой снова, бизнес мог никогда физически не держать товар, поэтому возврат должен маршрутизироваться через оригинального поставщика, и реселлер сидит посередине разговора, что логика возврата витрины никогда не была построена представлять. Система, спроектированная только вокруг чистого розничного случая, обычно не имеет реального ответа ни на что из этого, и исключения имеют свойство появляться точно тогда, когда бизнес меньше всего может позволить себе решать их вручную.

ОДНА СИСТЕМА ИНТЕРФЕЙСЫ

Одна система, несколько интерфейсов

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

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

ЧТО ЛОМАЕТСЯ ПЕРВЫМ

Что ломается первым

Типичная последовательность провала выглядит так. Ценообразование часто ломается первым, обычно как вручную поддерживаемая таблица исключений, которой никто полностью не доверяет. Инвентарь имеет тенденцию ломаться следующим, как только два канала перепродают тот же сток той же недели. Управление заказами часто ломается третьим, когда оптовый счёт или dropship-заказ не вписывается в форму, что ожидает система, и кто-то должен обработать это вручную. И отчётность имеет тенденцию ломаться последней, и часто остаётся сломанной дольше всего, потому что к моменту, когда бизнес пытается сравнить реальную маржу по каналу, данные уже разделены между системами, что никогда не были спроектированы для сравнения друг с другом.

ЧТО ЭТО СТОИТ

Что это реально стоит, и почему

Мультиканальная e-commerce архитектура стоит значительно больше одноканального магазина, и честная причина не в видимой витрине, она во всём описанном выше: логика ценообразования на уровне аккаунта, канало-осознанное распределение инвентаря, система заказов, что может представить три реально разных типа транзакций, и CRM, построенная моделировать реальные отношения аккаунтов, не отдельные логины. Бизнесы, что оценивают стоимость лишь сравнивая функции витрины против одноканального предложения, обычно сравнивают совсем не то. Витрина, самая дешёвая часть этой системы для постройки. Что определяет и стоимость, и долгосрочную стабильность, это относится ли бизнес, и команда, что это строит, правильно определяют заранее, что это одна система с тремя лицами, не три магазина, что просто продают те же товары.

Реальный вопрос

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

Какая самая большая архитектурная ошибка в мультиканальном e-commerce?

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

Когда витрине нужна интеграция с CRM или ERP?

Как только аккаунт представляет больше одного человека, компанию с несколькими пользователями, общими коммерческими условиями, или партнёрские отношения вместо отдельного логина. Большинство нативных систем аккаунтов e-commerce были построены вокруг одного розничного клиента и не моделируют эту сложность хорошо сами по себе.

Нужны ли нам три отдельных сайта для розницы, опта, и партнёров?

Обычно нет, и постройка трёх отдельных витрин обычно создаёт больше долгосрочной стоимости поддержки, чем экономит заранее. Одна система с канало-специфичной логикой и презентацией, что делится одним каталогом и одной правдой инвентаря, обычно стабильнее и значительно дешевле поддерживать со временем.

Чем оптовое ценообразование реально отличается от розничного кода скидки?

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

Чем реально отличаются возвраты и исключения по каналам?

Розничный возврат обычно возврат средств и пополнение запаса. Оптовый возврат часто частичный кредит против будущего счёта вместо немедленного возврата средств. Dropship-спор может вообще никогда не касаться собственного инвентаря бизнеса и должен маршрутизироваться через оригинального поставщика. Поток возврата, построенный только под розницу, обычно не имеет реального ответа на другие два.

Что обычно ломается первым, когда бизнес добавляет оптовый или dropship канал без планирования?

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

Можно ли добавить оптовый или партнёрский канал позже без перестройки всей системы?

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