Every marketplace roadmap has disputes on it. Usually it sits near the bottom and stays there. Teams put it off because it is unglamorous, hard to specify, and only matters in the small percentage of cases where something has already gone wrong.
That makes it easy to treat disputes as a later problem. It is also the feature that decides whether anyone trusts the platform. A marketplace makes a promise: if this goes badly, someone reasonable will sort it out. Disputes are where that promise is kept or exposed.
We built one. This is what it actually requires.
Most disputes do not have one clearly wrong party
Product teams often design disputes around the clean cases. A freelancer delivered nothing. A client refused to pay for good work. Those cases exist, and they are easy.
The overwhelming majority are different. The typical dispute is two people who both behaved reasonably, based on what they understood. The problem is that they understood different things. The work delivered is what was asked for, and also not what was wanted.
A dispute system that assumes someone is at fault will produce decisions that feel arbitrary. It forces a binary decision onto a situation that does not contain one. The first design decision is accepting that partial outcomes are the normal case, rather than treating them as a compromise.
The agreement matters before the argument starts
The most valuable work in dispute resolution happens before any dispute. It happens at the moment two parties agree to work together.
Most marketplace agreements are a title, a price and a paragraph. That is enough to start work. It is nowhere near enough to adjudicate, meaning to decide the case, when a disagreement arrives. At that point there is nothing clear to compare reality against. The platform ends up judging vibes and reading messages.
Disputes become tractable when the agreement has structure from the start. The structure is simple:
- Deliverables as a list. Discrete items that are either present or absent, rather than a description of an outcome.
- Acceptance criteria per item. How each item will be judged. Even one sentence changes what can be argued later.
- Milestones for anything substantial. Money is released in stages against defined progress, so no dispute is ever about the whole engagement.
- An explicit revision allowance. How many rounds are included. This single field prevents a large share of disputes, because most of them are really arguments about scope creep in the revision phase.
None of that is glamorous. All of it is cheaper than adjudication.
More evidence can make decisions slower
When a dispute is raised, the platform needs a record. The obvious temptation is to collect everything: full message history, every file version, and timestamps on all of it.
More evidence stops improving decisions past a certain point. After that, it produces longer reviews and a false impression of rigour. A reviewer reading four hundred messages is slow, and their conclusion will rest on the handful of exchanges that happen to be memorable.
The evidence that actually decides cases is much narrower. It is the agreed deliverable list, what was submitted against each item, and any explicit acceptance or rejection with a reason. We ask both parties to state their position against that structure instead of telling the whole story. The story is where both sides are sincerely convinced, and neither version is verifiable.
The clock is the real mechanism
The most important component is the clock. Evidence and reviewers matter, but timers are what keep the system from stalling.
Disputes become enormously more expensive when they stay open. Money is frozen, both parties are frustrated, and the platform is carrying an unresolved liability. Almost every design decision should be aimed at bounding time.
Ours runs on four timers:
- The client has a fixed window to accept or reject after submission, and silence becomes acceptance.
- A rejection must carry a reason within a shorter window, or it lapses.
- The freelancer has a window to respond to a rejection.
- If the parties do not converge, the case escalates automatically rather than waiting for someone to give up.
The critical property is that every timer has a default outcome. A dispute where nothing happens must still resolve. Systems where inaction leaves money frozen indefinitely are the ones that generate support tickets and reputational damage. They are surprisingly common.
Defaults are policy, so people should know them in advance
What happens when someone stops responding is a policy decision. It is the platform declaring who it favours in ambiguity. That position should be stated openly, rather than discovered.
Our defaults are simple. Silence after delivery favours the freelancer, because the client holds the ability to reject and chose not to use it. Silence after a rejection favours the client, because the freelancer holds the ability to respond. In both cases, the party that could have acted and did not carries the consequence.
That is arguable. Someone else will design it differently and have good reasons. What matters is that the default is published in advance, so nobody discovers the platform’s position at the moment it costs them money.
Partial outcomes need arithmetic, not a winner
Because most disputes are mixed, the resolution has to support splitting funds. Awarding everything to one side gives a clean answer to a situation that is usually messier.
The mechanism is the deliverable list from the agreement. Each item is assessed individually: delivered, not delivered, or delivered inadequately. Funds are released per item.
A five-item engagement where three are clearly fine and two are contested resolves as sixty percent released and forty percent adjudicated. The adjudication is then a much smaller argument.
This is why milestones matter so much. An engagement structured as one payment forces a binary decision on a mixed reality. An engagement structured as five forces almost nothing to be decided at all.
Human adjudication is expensive, so the system must keep it rare
Eventually a person has to decide. There is no way around it. Platforms that pretend otherwise are making the default outcome do the work silently.
The economics are the hard part. Adjudication is expensive: a competent person, thirty to sixty minutes, on a case that may be worth less than their time. A platform charging fifteen percent can absorb this. One charging nothing has to make the volume small enough that general revenue covers it. That is why the design work above is required for us.
Our target is under half a percent of engagements reaching human adjudication. Everything upstream exists to protect that number: the structured agreement, the milestones, the revision allowance and the timers.
AI helps prepare a case, but a person decides it
This is the obvious question, given what we build. The answer is narrower than people expect.
AI is useful for preparation. It can summarise a long exchange against the deliverable list, flag which items are actually contested, and surface the specific messages where scope changed. That turns a forty-minute review into a fifteen-minute one, which materially changes the economics.
AI does not decide. The reason is accountability. A decision that takes someone’s money needs a person who can be asked to justify it. Automating that would create the clearest possible example of the accountability gap we argue against everywhere else. If we would not accept “the model decided” from a vendor, we cannot offer it to our own users.
The hardest disputes are caused by the platform itself
The dispute that breaks a marketplace is often caused by the platform’s own systems. It may look ordinary in the record, but the cause sits underneath the process.
A file failed to upload. A notification never arrived, so a client missed the acceptance window. A timezone bug closed a timer early. In each case, one party is genuinely wronged and the platform is the cause. The ordinary dispute flow will adjudicate against them because the record shows inaction.
The only defence is an override path with proper logging, and a culture of using it when the platform is at fault instead of hiding behind the process. We treat any dispute where our own delivery logs show a failure as an automatic reversal plus a written explanation. We count them separately, because that count is a quality metric rather than a support metric.
The same five dispute patterns keep appearing
After enough cases, the shapes repeat. Naming them is useful because each has a different upstream fix.
Scope drift
Scope drift is the largest category by a distance. Work expanded gradually through friendly messages, nobody repriced, and the freelancer eventually stopped. Both parties are baffled that the other is upset. The fix is upstream: an explicit revision allowance and a mechanism to price an addition in one click.
Quality expectation
In a quality expectation dispute, the deliverable matches the brief and disappoints. Usually the brief described what, rather than how good. The fix is acceptance criteria, even crude ones, at the point of agreement.
Communication collapse
In a communication collapse, someone went quiet. Illness, a family situation, another client, occasionally nothing at all. The work is half done and the other party has no information. The fix is timers with defaults, so silence resolves rather than freezing.
Late delivery with a moving cause
In a late delivery dispute with a moving cause, the freelancer was waiting on assets, the client was waiting on the freelancer, and both are certain the other caused it. The fix is recording dependencies as items, so a blocked state is visible rather than argued about afterwards.
Genuine bad faith
Genuine bad faith is rare. It is the only category the classic dispute imagination covers. It resolves quickly because the evidence is one-sided. It is also the category everyone designs for, which is why so many dispute systems handle the common cases badly.
We measure whether the dispute system stays fair
We review four numbers monthly. A dispute system that is not measured drifts toward whatever reduces support load, rather than whatever is fair.
Dispute rate
Dispute rate means cases opened as a share of completed engagements. Rising means something upstream broke, usually in how agreements are being written.
Auto-resolution share
Auto-resolution share means how many close on a timer or a mutual agreement without adjudication. This is the number that keeps the model viable at zero commission.
Time to resolution
Time to resolution is measured from raising to funds moving, not to a decision being made. The gap between those two is where trust is lost.
Reversal rate
Reversal rate means how often an adjudication is overturned on review. A rate near zero is not reassuring. It usually means nobody is reviewing.
We also track the platform-fault count separately, because it belongs in an engineering conversation rather than a support one.
Four design choices decide whether the system is fair
There are four things we would tell anyone building this, in order of how much they matter.
- Structure the agreement, because everything downstream depends on having something to compare against.
- Put timers on everything with an explicit default, because an open dispute is the expensive state.
- Support partial outcomes, because binary ones are lies about most disagreements.
- Publish the defaults, because a rule discovered at the worst moment is worse than an unfavourable rule known in advance.
The rest is operational detail. Those four decide whether the system is fair, and fairness is the only thing a trust machine is actually selling.
The state model behind ours is set out in the Open Lance case study, and the same argument about accountability sitting with a named person runs through how we work.
