Коли 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 канал без планування?

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

Чи можна додати оптовий чи партнерський канал пізніше без перебудови всієї системи?

Іноді, якщо оригінальна система була побудована з реальною моделлю акаунту, інвентарем на основі розподілу, і гнучкою обробкою замовлень з самого початку. Якщо вона була побудована як єдиний роздрібний потік без розділення між цими шарами, додавання другого каналу пізніше зазвичай означає перебудову частин, що ніколи не були спроєктовані бути спільними з самого початку.