Розробка системи спорів та арбітра жу маркетплейсу
Система розв'язання спорів — це механізм, який повинен працювати рідко, але працювати безпомилково. Неправильно розв'язаний спір руйнує довіру або покупця, або продавця. Добре побудований процес забезпечує передбачуваність: всі сторони знають правила гри заздалегідь.
Коли виникає спір
Спір відкривається покупцем у випадках:
- Товар не прибув (протягом N днів після очікуваної дати доставки)
- Товар прийшов не той (пересортування, інша модель/розмір)
- Товар прибув пошкоджений
- Продавець не відповідає на запит повернення
- Опис суттєво не відповідає товару
Обмеження: спір можна відкрити не пізніше ніж через 30 днів після доставки (або очікуваної дати, якщо доставки не було).
Модель даних
disputes (
id, order_id, buyer_id, seller_id,
type: not_received | wrong_item | damaged | not_as_described | return_refused,
status: open | waiting_seller | waiting_buyer | escalated | resolved_buyer
| resolved_seller | resolved_partial | closed,
desired_resolution: full_refund | partial_refund | replacement | return_and_refund,
requested_amount (для partial_refund),
created_at, resolved_at, auto_close_at
)
dispute_messages (
id, dispute_id, sender_type: buyer | seller | admin,
sender_id, message, attachments (jsonb), created_at
)
dispute_evidence (
id, dispute_id, uploaded_by, type: photo | video | document,
file_url, description, created_at
)
Процес розв'язання
Етап 1: Прямий діалог (3–5 днів) Покупець створює спір, описує проблему, прикладає докази. Продавець отримує сповіщення та 48 годин на відповідь. Якщо сторони домовляються — спір закривається з вибраним рішенням.
Етап 2: Автоматичне рішення
Якщо продавець не відповів протягом 48 годин — автоматичне рішення на користь покупця (для очевидних випадків типу not_received). Цей механізм мотивує продавців реагувати швидко.
Етап 3: Ескалація до арбітра Якщо сторони не домовилися — спір ескалюється команді підтримки платформи. Арбітр вивчає переписку, докази, історію замовлення та виносить рішення. Рішення арбітра остаточне.
Інтерфейс арбітра
Робоче місце арбітра — окремий інтерфейс в admin-панелі:
- Хронологія спору: всі події з timestamps
- Зведення замовлення: товари, суми, статуси доставки, трек-номери
- Докази обох сторін (галерея фото, документи)
- Історія взаємодій покупця та продавця на платформі
- Кнопки рішення з пресетами та полем пояснення
- Шаблони сповіщень для інформування сторін
Метрики арбітра: середній час розв'язання, відсоток оспорених рішень, рейтинг якості арбітра жу.
Фінансові операції при рішенні
- Рішення на користь покупця (повний повернення): повернення повної суми + вартість доставки. Сума списується з балансу продавця.
- Часткове повернення: узгоджена сума. Залишок зараховується продавцю.
- Рішення на користь продавця: гроші з холду переводиться на доступний баланс продавця.
- Заміна товару: продавець відправляє новий. Гроші утримуються в холді до підтвердження отримання заміни.
Всі фінансові операції атомарні: зміна балансу та зміна статусу спору виконуються в одній транзакції БД.
Захист від зловживань
- Покупець може відкрити не більше 3 спорів на місяць (захист від професійних шахраїв)
- Історія спорів враховується при скорингу нових користувачів
- Продавець з високою часткою спорів (>5% замовлень) попадає під особливий контроль
- Докази зберігаються 180 днів після закриття спору
Сповіщення та дедлайни
Кожна зміна статусу генерує сповіщення (email + push). Автоматичні нагадування:
- Продавцю: 24 години до закінчення часу для відповіді
- Покупцю: 48 годин до автозакриття спору без активності
- Арбітру: якщо спір ескалюється та чекає рішення більше 72 годин
Аналітика спорів
Аналіз даних про спори допомагає покращити платформу:
- Топ причин спорів по категоріям → проблеми з описами товарів
- Продавці з аномально високим рівнем спорів → кандидати на перевірку
- Конверсія спорів на повернення → оцінка справедливості системи
Строк розробки: 6–8 тижнів для повної системи з арбітражним інтерфейсом, фінансовими операціями та аналітикою.