The dispute already happens inside your software.

Welcome to the first issue of The Resolution Letter. It’s about a problem that sits in almost every industry that runs on agreements and small payments: disputes that are too small for court and too numerous to write off. Most issues will be written for the software platforms those industries run on.

Follow a dispute through your product

Pick any vertical platform and trace what happens when a customer stops paying and says it isn’t fair.

• A tenant contests a move-out charge in property management software.
• A homeowner disputes a late fee on an assessment in HOA software.
• A storage customer challenges a lien fee in facility management software.
• A client refuses to pay the last invoice in accounting or billing software.

In every case the platform already holds almost everything that matters: the signed agreement, the ledger, the notices that went out, and the timestamps on each of them. And in almost every case the product’s involvement stops there. The balance is exported to a spreadsheet, handed to a collections agency, or quietly written off.

That’s the moment worth a product manager’s attention. The dispute doesn’t start outside your software. It leaves.

Why this is a platform problem, not an operator problem

An individual property manager or storage operator can’t build a dispute process. They don’t have the volume to justify it, and they don’t have the records in one place. A platform has both, across its entire customer base.

Platforms also carry the relationship. When an operator’s dispute leaves your product and goes to a third party, the experience your customer’s customer has, fair or not, is no longer something you shape. And the next time that operator compares software, the question of what happens when someone won’t pay is one your product can’t answer.

What adding resolution looks like

Stripped of any particular vendor, resolution as a feature has four parts:

• A trigger at the point of dispute, inside the workflow where the balance already lives, rather than an export.
• Notice to the other party, with a clear way to respond and a set window to do it.
• A record that pulls in what the platform already holds: the agreement, the ledger entries and the communications.
• An outcome that flows back into the ledger, so the operator sees it where they see everything else.

The design question most teams underestimate is fairness. A process built only to extract payment will be treated as collections by everyone involved. A process that gives the other party a genuine, easy way to be heard is the one operators can put their name on.

Four questions for your product team

• Where exactly does a disputed balance leave our product today, and what happens to it after?
• Which records do we already hold that a fair process would need?
• Would our operators want resolution under our brand, or kept at arm’s length?
• How would it be priced: included, per use, or shared with the operator?

What I’m working on

I run sales and business development at Arbitration.Inc, which builds an AI-assisted arbitration engine designed to be integrated into other platforms and offered under their brand. Most of my conversations right now are with platforms asking exactly the questions above. If you’re one of them, I’m glad to walk your team through how an integration would work on your own use case. I wrote the longer version of this argument in The Feature Your Platform Is Missing: Resolution.