Setting up a dispute and arbitration system for a 1C-Bitrix marketplace

What breaks without a marketplace dispute system

While a buyer-seller dispute is handled manually, the order sits in an intermediate status: the manager checks payment history, invoices, correspondence in email and messengers, and separately requests confirmation from the warehouse.

One such review takes days, and meanwhile a queue builds up — no one escalates stalled claims, because there are no deadlines, no owner, and no change log for the case.

Marketplace product returns are the worst arranged. The buyer's money is frozen in reserve, the seller does not receive payment for the shipped order, and both parties simultaneously write to support, each in their own channel.

Without a single dispute card with statuses, attachments, and decisions, each request grows duplicates, and the verdict is made anew — often opposite to the previous one for the same type of case.

Then the scale effect kicks in: as the number of orders grows, the flow of complaints against the seller grows, and support has to be expanded proportionally to turnover.

Sellers whose payouts regularly "stall" simply leave the platform, and a buyer who does not receive a response leaves a review and never returns.

We explain how this is closed: which statuses, deadlines, roles, and automated scenarios replace manual dispute resolution with a reproducible process with history and a predictable outcome.

What managed arbitration provides: effect on deadlines and rejections

Managed arbitration is not a "resolve dispute" button, but a set of rules by which a claim goes from request to decision.

The effect is visible in four metrics: resolution time, share of decisions without an operator, class of moderation errors, and volume of repeat requests.

• Claim resolution time for typical scenarios — goods not delivered, wrong goods, damage in delivery — is reduced from days to hours. The system itself requests photos, tracking number, and order status from the parties, and the operator gets involved only when the accounts differ.
• Share of automatic dispute decisions — most requests are closed based on formal criteria: deadlines, delivery statuses, correspondence history. The rest goes to manual review with an already assembled dossier.
• Marketplace support load stops growing with turnover: requests per thousand orders stay at the same level, because some issues are extinguished before a claim is created — by hints in the order card.
• Class of moderation errors disappears: identical situations receive identical answers, "different decisions on the same matter" and complaints about bias disappear.
• Repeat requests for the same order fall: a dispute has one identifier, correspondence and attachments are in one place, and a status change notifies both parties.

Rules are set by configuration in 1C-Bitrix: which evidence is mandatory, how much time is given for a response, what counts as automatic closure.

We verify the effect against the dispute log — resolution time, share of decisions without an operator, share of appeals before and after setup.

Marketplace arbitration options: comparison of modes

A dispute resolution mode is not a single setting, but a set of rules: who makes the decision, on what basis, and what both parties see.

In 1C-Bitrix, such a marketplace dispute system is assembled from order statuses, user roles, and event handlers — so different schemes can be enabled under one interface. Below are four options that are actually chosen between during implementation.

The choice is determined by the flow and the share of non-standard cases.

Where a rule can be formulated formally, automatic arbitration relieves the support load; anything that requires reading correspondence is cheaper to route straight to escalation, bypassing manual moderation.

A hybrid resolution scheme gives the best balance, but requires a decision log — it shows which thresholds are due for revision.

How we implement arbitration: stages of work

We start implementation not with module setup, but with analyzing how returns and claims are currently arranged: where requests are lost, who makes the decision, how much time passes between the buyer's request and the seller's response.

An audit of the returns process shows failure points — approval by email, lack of change history, decisions bypassing the rules. Then comes configuration.

1. Audit of the returns process. We analyze the rules, roles of the seller, buyer, and platform administrator, response deadlines, and reasons for rejections. The result is a process map with failure points and a list of rules that need to be formalized.
2. Dispute status scheme. We describe the lifecycle: open, under review by the parties, arbitrator required, accepted, rejected, closed by deadline. For each transition, we record the initiator, mandatory attachments, and what the other party sees.
3. Arbitration setup on 1C-Bitrix. We link statuses with orders, payments, and returns, set deadlines, automatic transitions, notifications, and access rights. We separately check partial returns and disputes over multiple items.
4. Regulations and roles. We define when the seller closes a dispute themselves, and when the platform arbitrator gets involved, and which evidence is considered sufficient.
5. Test dispute scenarios. We run typical and edge cases: seller silence, rejection without justification, request after the deadline, repeat claim.
6. Handover to the team. We train employees, provide regulations with statuses and rights, monitor the first disputes, and adjust the rules based on actual data.

Set of settings and documentation after implementation

Implementation ends not with launch, but with handover: the client's team should retain artifacts by which disputes can be developed and supported without us. Below is the set that we hand over together with the working marketplace configuration.

• Dispute status scheme — all transitions from claim to closure and appeal, indicating who and under what condition moves the dispute forward, and where it closes automatically.
• Auto-decision rules — under what conditions a dispute is resolved without human involvement: the seller's response deadline has expired, a complete set of evidence is attached, the value fell within a specified threshold.
• Arbitration rights matrix — a table of roles: buyer, seller, moderator, senior arbitrator. It shows who can do what, and separately — who is allowed to override an auto-decision manually.
• Dispute access policies — who sees correspondence, attachments, and decision history, and how access is differentiated between seller segments and support employees.
• Claim review regulations — processing deadlines at each status, escalation procedure for overdue cases, notification templates for the parties.
• Seller instructions — how to file an objection, what evidence to attach, by what deadline, and what happens if the seller stays silent.
• Dispute reporting — an export by resolution time, share of auto-decisions, and overturned decisions: it shows where the rules work and where they need clarification.

Documentation is stored next to the configuration and versioned together with it: a change to auto-decision rules or role composition goes as one change with an updated description.

Thus, the discrepancy between how a dispute is resolved in practice and what is recorded is detected immediately, rather than during incident review.

Case: how stalled disputes and returns were reduced

What it was before

A marketplace on 1C-Bitrix with several thousand sellers: disputes were opened in the account, but the decision on each was made manually by a manager — corresponding with the parties by email and putting evidence into a separate folder.

The average resolution time reached six days, and for 22% of requests it exceeded two weeks: during that time, the buyer managed to pursue a return, and some sellers opened the dispute again.

What was changed

We gathered dispute scenarios in one place: the request is linked to the order, items, and correspondence, attachments go into the card, and the change history cannot be edited.

Typical grounds — wrong goods, missed deadline, damage in delivery — were moved to automatic review with strict status logic. The rest goes to the arbitrator, but with an already prepared data set and a timer for each party's response.

Metrics before and after

The reduction in returns came not from prohibitions, but from speed: while a dispute is pending, the buyer files a return through the payment service, and the seller loses both the goods and time.

When a decision comes within a day or two, the share of such cases falls, and the first support line is relieved — the dispute status is visible in the account without contacting an operator.

How an order dispute differs from a return and a claim

The three entities solve different tasks and live in different status models. A product return is an order operation: the item is returned, the seller confirms receipt, the order is closed.

A buyer claim is a recorded demand regarding quality, completeness, or deadlines, and a return is not mandatory for it. An order dispute is a conflict that the parties did not close themselves and that goes to an arbitrator.

The difference shows up in timers. A return has procedural windows: how long we wait for the goods, how long we hold the request before auto-cancellation.

A claim has response deadlines for the parties, primarily the seller: silence within the window moves the demand to the next step. A dispute has timers for both parties plus a separate window for the arbitrator's decision.

If everything is merged into one entity, an auto-decision on a return will start closing claims, and a dispute will get the status "resolved" before the arbitrator has seen it.

Roles diverge in the same way: a return is confirmed by the seller's operator, a claim only by an authorized role, and a dispute decision is made by an arbitrator, not a participant.

In 1C-Bitrix, marketplace logic is built on order statuses and event handlers, so in the platform regulations we assign each scenario its own set of transitions and its own log.

Otherwise, in the order history a conflict and a routine return look the same, and review turns into reading correspondence.

At the data model level, this is a separate request type: its own mandatory fields — item number, reason, attachments — its own response deadlines for the parties, and its own set of auto-decisions.

Then reporting is calculated separately: how many returns were closed without support, how many claims went overdue, how many disputes reached the arbitrator. The rules stop overwriting each other, and the regulations remain predictable as the number of sellers grows.

Contested situations in arbitration: questions and answers

A marketplace dispute is not a chat correspondence, but a regulation: who records the claim, at what moment the timer starts, by what rule the decision is made, and by what document it is closed in accounting.

Below are four technical questions that most often come up before starting work on a dispute and arbitration system on 1C-Bitrix, and our substantive answers.

How is the seller's response deadline controlled?

The timer starts from the moment the notification is delivered, not from dispute creation, and is recorded in the history. Then escalation works: a reminder, then transfer to the arbitrator, then a default decision.

The deadline depends on the product category and claim type and is set by policy — it changes without code edits.

What to do with auto-decision errors?

Automation closes only formally verifiable cases: cancellation after the shipment deadline, return without a receipt mark. Everything with evidence and correspondence goes to a human.

Each auto-decision is saved together with the rule version, so the decision can be reviewed, not "rewritten" retroactively.

How is arbitration linked to accounting?

An arbitration decision is an event with fixed parties and amount: return, withholding, compensation. Documents and adjustments to settlements with the seller are generated from it.

When a dispute is reviewed, past movements are reversed, not deleted — reconciliation remains consistent.

Let's discuss your arbitration scheme and prepare a plan

So that the time estimate is based on your scheme and not on an average template, it is enough to send a few artifacts to prepare for the start.

Arbitration implementation breaks not on code, but on discrepancies in the regulations: who is considered an arbitrator, what response deadlines the seller has, what happens to the order while the dispute is open. The more precise the snapshot, the fewer clarifying iterations after the start.

On your side, send:

• a map of roles and rights: buyer, seller, support, arbitrator — who makes a decision at which step and what they can cancel;
• a list of dispute reasons and the current regulations: response deadlines for the parties, automatic closure, escalation rules;
• the order and return statuses already in use, and transitions that must not be broken;
• anonymized examples of real requests — correspondence and the final decision on each;
• integration points: 1С, payments, delivery, warehouse, notifications in email and personal account;
• constraints: what must not be touched, who approves the regulations, by what date the working contour is needed.

In response, we will return a staged work plan: a process scheme with dispute states and transition rules, a list of modifications to arbitration logic and notifications, a time estimate for each stage, risks, and rollback points. Describe your task — we will come back with an estimate and a plan.