Join.To.IT створює ПЗ для операторів маркетплейсів, які стоять між багатьма продавцями й багатьма покупцями. Це онбординг, контроль оголошень, комісії, розділені виплати, довіра й безпека — а не каталог одного бренду з темою оформлення.
Маркетплейс — це тристороння операція. Потрібні заявки продавців, які можна схвалити чи відхилити, оголошення, які можна зняти, гроші, що розділяються між сторонами, і спосіб працювати з шахрайством і спорами так, щоб офіс не жив у таблицях.
Хостингові вітрини створені для продавця, якому належить увесь каталог. Ми будуємо шар оператора: хто може продавати, що можна розміщувати, як рахуються комісії, коли вивільняються кошти і як покупці й продавці ескалюють проблему.
Почніть з онбордингу й виплат — саме там маркетплейси втрачають довіру, — а далі розширюйте систему модерацією та спорами.
Заявка, перевірка й статуси акаунта, щоб нові продавці не зʼявлялися на маркетплейсі, доки не відповідають вашим правилам.
Товари від продавців із правилами оператора щодо категорій, обовʼязкових атрибутів і того, що потрапляє в продаж.
Логіка зборів, яка залежить від категорії, рівня продавця, акції чи способу доставки, — а не один відсоток на кожне замовлення.
Гроші за замовлення розподіляються між продавцями, маркетплейсом та іншими сторонами, з утриманням до доставки або до кінця строку на спір.
Інструменти для команди, яка перевіряє продавців, оголошення й замовлення, коли щось виглядає підозріло.
Чіткий шлях, яким покупці й продавці порушують питання, обмінюються доказами та отримують рішення.
Маркетплейс генерує більше оголошень і повідомлень, ніж здатна прочитати невелика команда. ШІ корисний на вході, у перевірці правил і в первинних підсумках спорів — але рішення, що впливає на заробіток продавця, ухвалює людина.
Команда ШІ-розробки Join.To.IT підключає ці можливості до даних продавців, оголошень та історії спорів.
Позначає заборонені категорії, відсутні атрибути й тексти, скопійовані в іншого продавця, ще до публікації.
Показує команді довіри незвично високі повернення, невдалі виплати чи різкий ріст каталогу.
Перетворює листування й події замовлення на короткий бриф, щоб оператор вирішував швидше й не втрачав контексту.
Готує відповіді на основі правил маркетплейсу й статусу замовлення, а нестандартні випадки передає людині.
Знаходить майже однакові товари різних продавців, щоб каталогом було зручно користуватися, а не тонути в копіях.
Ми інтегруємо платіжних провайдерів, що підтримують розділення платежів для маркетплейсів, перевірки особи й документів (якщо вони вам потрібні), розрахунок податків, перевізників чи 3PL, коли доставку веде маркетплейс, а також канали повідомлень для спорів.
Join.To.IT створює ПЗ маркетплейсу. Регульований рух коштів забезпечує платіжний провайдер. Ми не працюємо як банк чи платіжна установа.
Хостинговий магазин виходить із того, що один продавець володіє товаром і приймає оплату. Правила маркетплейсу — хто може продавати, як працюють збори, коли вивільняються кошти — це комерційні рішення. Індивідуальне ПЗ виправдане, коли саме ці правила і є продуктом.
Онбординг, права й блокування потребують власного життєвого циклу, а не другого входу в адмінку брендового магазину.
Комісії, плата за розміщення й акційні збори рідко вміщуються в одне поле знижки стандартного кошика.
Утримання, розділення й невдалі перекази потребують журналу, за яким оператор може пояснити все продавцеві.
Черги модерації й спори — не плагін «на потім», а те, завдяки чому маркетплейсом можна користуватися.
Пошук, ранжування й правила мають працювати, коли жоден бренд не володіє всіма товарами.
Той самий процес Join.To.IT, застосований до онбордингу продавців, комісій, виплат і процесів довіри.
Описуємо, як продавці зараз подають заявки, розміщують товари, доставляють, отримують гроші й відкривають спори, — і хто ухвалює рішення щодо кожного винятку.
Визначаємо модель даних для продавців, оголошень, замовлень, зборів і виплат, а також інтеграції з платіжним провайдером і перевіркою особи.
Проєктуємо інтерфейси продавця, покупця й оператора так, щоб черги модерації й виписки були повноцінними функціями, а не залишками адмінки.
Спершу робимо онбординг і контроль оголошень, далі — комісії, розділені виплати й спори релізами, з якими оператор може працювати.
Тестуємо шляхи схвалення, розрахунок зборів, утримання виплат і дедлайни спорів на реалістичних замовленнях від кількох продавців.
Запускаємо з обмеженою групою продавців, потім відкриваємо онбординг і налаштовуємо правила модерації та календарі виплат.
Обираємо технології з огляду на кількість продавців, швидкість появи оголошень, частоту виплат і те, яку частину доставки ведете ви, а яку — продавці.
Практичні відповіді для засновників, операторів і продуктових керівників маркетплейсів.
