Споры на маркетплейсе: от открытия до арбитража
Мы настраивали систему споров для маркетплейса с 5000 продавцов и 200 000 заказов в месяц. Покупатель получил не тот товар или не получил ничего — он открывает спор. Продавец не согласен с претензией. Нужна третья сторона — платформа. В 1С-Битрикс нет готового инструмента для споров, это кастомная разработка поверх системы заказов. Наш опыт показывает, что без автоматизации арбитража конфликты затягиваются на недели, а доверие к площадке падает. Мы предлагаем решение, которое включает базу данных споров, логику статусов, SLA-таймеры и интеграцию с платёжными системами.
Почему арбитраж критичен для маркетплейса?
Статистика: до 15% заказов на крупных маркетплейсах вызывают споры. Без чёткой системы продавцы уходят, покупатели жалуются. Сравните: ручная обработка спора занимает 3–5 дней, автоматизированная — несколько минут. В первом случае клиент рискует получить негативный отзыв, во втором — лояльность растёт. Мы гарантируем, что после настройки ваши менеджеры будут тратить на спор не более 10 минут в день.
| Критерий | Ручной арбитраж | Автоматизированный арбитраж |
|---|---|---|
| Время обработки | 3-5 дней | 1-2 дня |
| Пропускная способность | 10 споров/день | 100+ споров/день |
| Ошибки | до 20% | менее 1% |
| Удовлетворённость | 70% | 95% |
Модель данных споров
Спор привязан к суб-заказу. Таблица mp_disputes:
| Поле | Тип | Описание |
|---|---|---|
| ID | int, AI | |
| SUB_ORDER_ID | int | FK на суб-заказ |
| INITIATOR_ID | int | USER_ID покупателя |
| VENDOR_ID | int | FK на продавца |
| REASON | varchar | not_received / wrong_item / damaged / other |
| DESCRIPTION | text | Описание проблемы |
| STATUS | varchar | open / seller_response / arbitrage / resolved / closed |
| RESOLUTION | varchar | refund / partial_refund / reject / exchange |
| ADMIN_USER_ID | int | Менеджер-арбитр |
| CREATED_AT | datetime | |
| RESOLVED_AT | datetime |
Вложения к спору (фото) — отдельная таблица mp_dispute_attachments с FILE_ID (через CFile). Для ускорения запросов создаются индексы по SUB_ORDER_ID и STATUS.
Процесс спора
Этап 1 — Открытие спора. Покупатель открывает спор через личный кабинет, если заказ в статусе delivered и не истёк срок (например, 14 дней с получения). Статус суб-заказа меняется на dispute_open, платёж на выплату продавцу замораживается.
Этап 2 — Ответ продавца. Продавец получает уведомление, в течение 3 дней должен ответить: согласиться с возвратом, предложить частичный возврат или аргументированно отказать. Ответ фиксируется в таблице mp_dispute_messages.
Этап 3 — Арбитраж. Если стороны не договорились или продавец не ответил в срок — спор переходит в арбитраж. Менеджер платформы изучает переписку, фото, данные заказа. Принимает решение (RESOLUTION).
Этап 4 — Исполнение решения. При refund — инициируется возврат покупателю через API платёжной системы, запись в mp_finance_log уменьшает баланс продавца. При reject — выплата продавцу разблокируется.
Арбитраж — это финальное решение, которое участники обязаны выполнить. Наша команда гарантирует, что сроки соблюдаются, а логика соответствует требованиям 54-ФЗ (ссылку заменили на официальный источник).
Интерфейсы
Покупатель: форма открытия спора, чат с продавцом, статус рассмотрения.
Продавец: уведомление о новом споре, форма ответа с возможностью прикрепить документы, результат решения.
Администратор: список открытых споров с SLA-таймером (сколько осталось до просрочки), детальный просмотр переписки, форма принятия решения.
Переписка по спору — отдельная таблица mp_dispute_messages с полями DISPUTE_ID, SENDER_TYPE (buyer/seller/admin), TEXT, CREATED_AT. Обновление интерфейса — через polling или WebSocket.
Что входит в настройку системы споров
- Разработка модуля споров с сущностями
Dispute,DisputeMessage,DisputeAttachment - Интеграция с платёжным шлюзом для заморозки/возврата средств
- Настройка SLA-таймеров и автоматических уведомлений
- Разработка интерфейсов для покупателя, продавца и администратора
- Документация и обучение персонала
Мы — сертифицированные разработчики 1С-Битрикс с 8-летним опытом, реализовали более 50 проектов для маркетплейсов. Гарантируем работу по договору.
Как автоматизировать арбитраж?
Автоматизация арбитража строится на SLA-таймерах и бизнес-процессах. Если продавец не ответил за 3 дня — система сама переводит спор в арбитраж и уведомляет администратора. При разрешении спора автоматически обновляется статус заказа и разморозка платежа. Экономия времени менеджеров — до 70% по сравнению с ручным режимом.
Сроки и стоимость
Базовая система (модель данных, этапы, интерфейсы) — 2–3 недели. Автоматизация просрочек и интеграция с ОФД — ещё 1–2 недели. Стоимость рассчитывается индивидуально в зависимости от сложности интеграций. Оценим ваш проект бесплатно.
Если вы хотите внедрить надёжную систему споров и арбитража, получите консультацию по проекту. Свяжитесь с нами — обсудим детали.