Disputes are the product

A peer-to-peer marketplace works well right up to the moment something comes back damaged. Then the platform has to decide between two parties it does not employ, both of whom have money at stake and each of whom is certain.

Whether it can decide well is settled long before the dispute is raised. By then, either the evidence exists or it does not, and no amount of process compensates for its absence.

Evidence has to be a by-product, not a step

The instinct is to add a condition-report screen at handover and require photographs. It works in testing and erodes immediately in the field, because the people involved are standing in a car park in the rain and want to get on with it.

What survives contact with reality is capture that is unavoidable rather than diligent: a handover that cannot complete without images, the number of images fixed and small, prompts naming what to photograph, and the whole thing taking well under a minute. Anything optional is skipped exactly when it matters, because the transactions that end in dispute are disproportionately the rushed ones.

The metadata matters as much as the images. When it was taken, by which account, attached to which booking, and — critically — that it was taken before the booking started rather than uploaded afterwards. Photographs without provenance are two claims rather than one resolution.

The asymmetry between the two sides

The owner has a high-value asset and transacts repeatedly. The renter transacts once and may never return.

That asymmetry biases everything if left alone. The owner knows the process, has the vocabulary and will escalate. The renter often does not realise a decision is being made until it has been made against them, which is how platforms acquire a reputation for siding with supply.

Practical countermeasures: tell both sides a dispute is open and what the deadline is, show each what the other submitted, and make the decision cite the specific evidence it relied on. A decision that can be read back is a decision that survives being challenged publicly.

Deposits are not the same as payment

Holding a deposit is an authorisation, not a capture, and authorisations expire — frequently before a dispute concludes.

That timing is where systems get caught. The hold lapses while the case is open, the funds are gone, and the platform is now pursuing an individual for money it thought it had secured. The lifetime of the hold has to be understood, surfaced to whoever is deciding, and factored into how long a dispute may stay open.

Insurance adds a party, not a solution

Once a policy is involved there are three parties with different thresholds. Small damage sits under the excess and is settled between the two users. Larger damage goes to the insurer, on their timeline and requiring their evidence format.

The platform now needs to know which regime a claim falls under before deciding anything, and must not settle a claim in a way that prejudices a later insurance position. This is a domain where the product decision — where the threshold sits, who pays the excess — has to be made explicitly and encoded, because the default is that whoever complains most effectively wins.

Finality

A dispute process without an end state stays open forever and consumes the operations team.

There has to be a decision, a stated basis, one appeal route with a deadline, and then closure. Users tolerate an unfavourable decision far better than an indefinite one, and an operations function that cannot close cases scales linearly with volume — which is the point at which a marketplace's unit economics quietly stop working.

Why this is the product

It is tempting to treat disputes as an edge case and build the booking flow first. They are a small fraction of transactions and none of them are why anyone signs up.

But the willingness of an owner to hand a valuable asset to a stranger rests entirely on what happens when it goes wrong. That confidence is the actual product; the booking flow is how it is delivered. A marketplace that handles disputes badly does not lose the disputed transactions — it loses the supply side, one owner at a time, and each of them tells the others why.