Skip to content
allanninal.dev/build
Collaborate

Part 5 of 7 · Referral payout runner series ~5 min read

How a disputed payout gets resolved

Every referral programme generates disputes, and almost all of them are people asking a reasonable question in an annoyed tone because they could not find the answer themselves.

Key takeaways

  • A statement that shows pending and held items prevents most disputes entirely.
  • Three real dispute types remain: missing referral, wrong amount, and a contested hold.
  • The event log answers all three in minutes because nothing was overwritten.
  • When the system was wrong, pay and say so plainly. Do not explain the mechanism.
  • Track disputes by type; a spike in one of them is a bug report.

The statement does most of the work

What a monthly statement shows

  • Paid this run: each referral, the order date, the qualify date, the amount, and which rule version it was paid under.
  • Pending: each one, with the date it becomes payable.
  • Held: each one, with the reason in plain words and who to reply to.
  • Not qualifying: each one, with which condition it missed.
  • Carried over: the balance below the minimum, and how much more is needed.
  • Every line links to the referral’s history, so “why” is one click and not an email.

The fourth section is the one most programmes omit and the one that prevents the most arguments. A referral that did not qualify simply vanishes in most systems, so the referrer knows only that somebody they referred bought something and they were not paid, which is exactly the shape of a grievance.

The three that still arrive

Three kinds of referral dispute resolved from the event logThree boxes stacked on the left. My referral is missing, they ordered and I saw it, labelled most common. The amount is wrong, I expected twenty and got fifteen, labelled usually a rule change. Why is mine held, I did nothing wrong, labelled usually correct. All three converge on The event log, which holds every state change with its cause, and that leads down to Answered in minutes, with dates and reasons. A note says all three are answerable from the log because nothing in it was ever overwritten."My referral is missing"they ordered, I saw itmost common"The amount is wrong"I expected 20, got 15usually a rule change"Why is mine held?"I did nothing wrongusually correctThe event logevery state change,with its causeAnswered in minuteswith dates and reasonsAll three are answerable from the log because nothing in it was ever overwritten.
Fig 1. The three real dispute types and where they get resolved. The append-only log from Part 2 is what makes each of these a two-minute answer rather than an investigation.
  • Compute
  • Machine learning
  • Management

The missing referral

Usually one of three things: the person ordered without clicking the link, the attribution window had expired, or somebody else’s click came first. All three are visible in the log, and all three are explicable in a sentence.

The first is the awkward one, because the referrer genuinely did the work and the system genuinely cannot see it. A programme that never pays those loses referrers; a programme with a small discretionary budget for exactly this case keeps them, and the budget is smaller than the alternative.

The wrong amount

Almost always a rule change, and almost always the referrer remembering the older, better terms. The stamped version resolves it immediately: this referral was made on the third under version four and was paid under version four; the one you are thinking of was made on the twentieth, under version five.

Without the stamp this dispute is unresolvable, because the only available answer is “the current rules say fifteen”, which does not address what was asked.

When the system was wrong

What happens when a referral dispute reveals a system errorA horizontal row of five boxes. They were right: it was our bug. Pay it: immediately and off-cycle. Say so plainly: we got this wrong. No mechanism talk: they do not care. Find the others: the same bug hit more people. A note says the last box is the one people skip, and it is the one that matters most.WHEN THE ANSWER IS THAT WE WERE WRONGThey were rightit was our bugPay itimmediately, off-cycleSay so plainly'we got this wrong'No mechanism talkthey do not careFind the othersthe same bug hit moreThe last box is the one people skip, and it is the one that matters most.
Fig 2. The correction path. The fifth box turns one apology into a fixed problem, and it is easy because the event log makes the affected set queryable.
  • App integration
  • Security & identity
  • Analytics

The fourth box deserves a note. The instinct when a system was wrong is to explain the mechanism, partly to demonstrate that it was a reasonable failure. The person waiting to be paid does not want the mechanism; a short acknowledgement, the money, and a note that it is fixed lands considerably better.

Disputes as a signal

Categorise every dispute by type and count them monthly. A stable low rate is normal. A spike in “missing referral” is a tracking bug; a spike in “why is mine held” means a fraud rule was tightened and nobody weighed the orange bar; a spike in “wrong amount” means a rule change went out without being explained.

Each of those is a specific, actionable finding that arrives free with a support process that was happening anyway, and none of them are visible if disputes are handled individually and not counted.

Next: what all of this costs to run.

All posts