Маркетплейс для партнерів: хто насправді володіє клієнтом
Коротко
Хочеш підключити субдистриб’юторів у свій додаток і дати клієнту вибирати продавця? Це мінімум $20 000 доробок і бомба уповільненої дії: партнери, які бачать, звідки прийшло замовлення, за рік можуть купити собі окрему платформу й піти без тебе. Правильна архітектура — клієнт нічого не обирає, система сама розподіляє замовлення між складами, а платформа лишає собі ~20% з кожного платежу.
На груповому розборі «Клуб підприємців» до Андрія звернувся власник B2B-бізнесу професійної косметики й пептидів для косметологів (не B2C, а B2B — так він сам це назвав). Він уже планував додати в свій застосунок субдистриб’юторів інших брендів: не закуповувати товар самому, а дати партнерам продавати через його додаток.
Яку ідею приніс власник — і чому вона коштує $20 000
Задум був зроблений під франшизну логіку: клієнт спершу обирає конкретного партнера-франшизу і бачить лише його товар, локально, за принципом «найближчий склад».
«Зараз ми плануємо додати субдистриб’юторів інших брендів на наші приложі, самі не закуповуватися, а їм дати можливість продати через приложення.» — з розбору, 17:23
«Ти нажимаєш, і тобі пропонується, наприклад, де найближчий товар, у якого постачальника є зараз на складі… Якщо я вибираю інший товар, він є у другого постачальника — він натискає вибір товару, показує, в якому місті він є, і виходить купує у того постачальника.» — з розбору, 18:08
Відповідь на цю ідею була прямою:
«Що я вам пропоную? Те, що ви розказали, це доробки на нашій стороні мінімум на 20 тисяч доларів. Мінімум. Просто так навскідку, я навіть не заглиблював цю історію.» — з розбору, 21:28
І це — ціна лише за функціонал «повноцінний маркетплейс з вибором постачальника». Ціна за архітектурний ризик, який ця схема створює, — окрема розмова.
Чому клієнт не повинен сам обирати продавця
Замість франшизної логіки Андрій запропонував інший принцип: клієнт узагалі не бачить, у кого купує. Він лише вказує, куди доставити, — а система сама вирішує, з якого складу відправити товар.
«Ви в нашій системі отримуєте заказ, відповідно по заказу ви бачите вже, куди доставити чоловіку товар. І ваша система внутри сама рішає, з якого складу відправить. Чоловік взагалі нічого не вибирає, він указує доставити мені туди-то. І ваша система автоматично вибирає того партнера, від якого відправити.» — з розбору, 21:57
Це не технічна дрібниця — це різниця між «клієнт мій» і «клієнт спільний із партнером, який завтра може стати конкурентом».
Хто приймає платіж і скільки лишає собі
Другий елемент архітектури — гроші. Платіж іде через платіжну систему платформи, яка лишає собі частину суми, а решту одразу переказує постачальнику.
«Платіжна система: оставляти собі 20 процентів, ви собі залишаєте, а остальні гроші поступають одразу на щита, кому ви їх відправляєте.» — з розбору, 23:45
Це рішення закриває одразу два питання — і бухгалтерське, і податкове:
| Питання | Рішення |
|---|---|
| Хто приймає оплату від клієнта | Платформа (єдина точка входу) |
| Скільки лишає собі платформа | ~20% з кожного платежу |
| Решта суми | одразу постачальнику через договір |
| Податок | лише з тієї суми, яку платформа лишає собі |
«Тоді ви податки платите тільки за цю суму, яку ви собі залишаєте. П’ять відсотків, двадцять відсотків — в залежності від оподаткування. Але це правильно треба зробити конкретними договорами.» — з розбору, 24:10
Чому продавці не мають знати, звідки прийшло замовлення
Це головний пункт безпеки бізнесу — можливо, найважливіший у всій розмові. Коли партнери не бачать джерела замовлень, вони не можуть побудувати власний канал в обхід тебе.
«Ви стаєте тоді для них охеренним ринком збуту, з якого вони, продавці ваші, ніколи не зіскочать і будуть платити вам за їхні замовлення.» — з розбору, 26:04
Той самий принцип — база належить платформі, а не продавцям, які через неї продають, — детальніше розібраний у матеріалі про безпеку клієнтської бази як головного активу. Тут же головне — не архітектура заради архітектури, а страховка від сценарію, коли партнер, підключений тобою ж, за рік каже собі: «А чому б не купити цю платформу окремо і не піти самому».
Андрій прямо описав цей ризик протилежного підходу — коли власник віддає партнерам відправку і прийом платежів, щоб самому нічого не робити: за рік система розкручується, а партнери вже й самі не розуміють, навіщо їм посередник, і тихо йдуть будувати щось своє. Той, хто на старті віддав контроль над відправкою й платежами, у цей момент розуміє, що прогавив момент ще на етапі архітектури.
Навіщо взагалі так ускладнювати — бізнес, який можна продати
Останній аргумент — не про безпеку сьогодні, а про вартість завтра.
«Коли ви захочете його продавати — ваш бізнес, а бізнес треба вести так, щоб ви могли продати його в будь-який день. І коли ви захочете продавати, ви будете продавати платформу, на якій будуть десятки тисяч користувачів і сотня продавців. І вона буде коштувати набагато більше, ніж уся ця незрозуміла структура, яка хтозна як працює.» — з розбору, 27:08
Цікаво, що франшизна логіка, яку власник хотів застосувати до онлайн-маркетплейсу, у SalesBox взагалі створювалась не під це:
«Франшиза в нас створювалася спеціально для таких магазинів, які локально, в офлайні, в різних точках міста.» — з розбору, 28:17
Тобто механіка «обери партнера й купи в нього» — це рішення для фізичного ретейлу, куди клієнт фізично приїжджає забрати товар, а не для онлайн-маркетплейсу з десятками субдистриб’юторів.
Головна думка
Якщо будуєш маркетплейс із власних партнерів чи субдистриб’юторів — не копіюй логіку «клієнт обирає продавця». Клієнт не повинен знати, у кого він купує; система сама розподіляє замовлення. Платіж проходить через тебе, ти лишаєш собі ~20%, решта — постачальнику за договором. Партнер не бачить джерела замовлень — і тому ніколи не зіскочить із твоєї платформи. Це не параноя, а архітектура бізнесу, який можна продати в будь-який день.
→ Безкоштовний розбір вашого бізнесу
Про автора. Андрій Стахов — засновник SalesBox. Щотижня розбирає реальні бізнеси в прямих ефірах: прямий канал, безпека бази, юніт-економіка. Усі розбори →
Читайте також
Джерело матеріалу: Бізнес-розбір «Клуб підприємців: безпека бази, маркетплейс із додатку, фінансова рада», 2026-06-11