4 times the money stopped moving.

What it looked like from the outside

Tracking was fine. The sales fired, the sales arrived, the volume was there. So the obvious read was a resourcing problem in the approvals team - too many transactions, not enough people. The instinct in that situation is always the same: add bodies to the queue, or buy a tool.

What was actually happening

The break was on the other side of the chain entirely. Neither the merchant nor the affiliate network could attribute a tracked sale back to a live order on their own systems. A sale would land, correctly recorded, with no reliable way of saying which real customer order it belonged to.

So somebody had to work each one out by hand. That is not a queue you clear. It is a queue that grows.

The consequences stacked in order. Validation slowed. Approval slowed. And the member at the end of it waited 90 days for money they had already earned.

This is the exact stretch between transaction recorded and transaction approved. The transaction was recorded fine. It couldn't be approved because nothing could prove what it was.

What I changed

I added 1 field to the member's side of the tracked sale, asking them to enter their order ID, and fed that value through to the merchant and the network.

The member is the only person in the chain who definitely knows their own order number. They supply the missing key, and the matching that had been manual becomes automatic.

Worth noticing what this wasn't. Not a system rebuild. Not a new platform. Not a fraud control. It was a piece of information that existed the whole time and was never being asked for.

The result

• Matching went from manual to automatic
• Validation sped up, and stayed sped up
• The payout window went from 90 days to 60
• The partnership strengthened rather than strained - which is the bit that actually mattered commercially

The transferable pattern

When approvals are slow, work out whether you have a capacity problem or a missing key problem. From the outside they look identical, and they need opposite fixes. Throwing people at a missing key just gives you a bigger manual process.

Then find who in the chain already holds the information that's missing. It is very often the person waiting to be paid. Ask them for it at the point they're already there, not later in an exception process.

Automation follows the key. You cannot automate a match you cannot make.

This applies well beyond affiliate. Card-linked rewards live or die on matching a card transaction to a qualifying offer. Creator commerce has to attribute an order to a creator across several marketplaces with different rules. Receipt upload is the same move as asking for an order ID, done manually. Every one of them has a moment where something is recorded but can't be approved, because the key is missing.

The thing that looks like transparency and isn't

Every rewards platform faces the same question early on. How much of the truth do you show the customer?

The instinct is all of it. Show them the sale tracked. Show them when the merchant validates. Show them when the money arrives. It feels honest, it feels modern, and it should mean fewer people writing in to ask where their cashback is.

It is also one of the fastest ways to manufacture support tickets and lose trust at the same time. And the reason has nothing to do with design, and everything to do with what happens 3 companies away from you.

Why the truth moves

A cashback sale passes through a chain before it becomes money. The consumer buys. The affiliate network tracks it. The merchant validates it - confirming the sale was real, wasn't returned, wasn't cancelled, wasn't fraudulent. The network invoices. The merchant pays. The network pays the publisher. The publisher pays the member.

Every one of those steps has an owner, and only 2 of them are yours.

Now add the part most people outside this world have never heard of. Some networks auto-validate. If a merchant hasn't touched a batch of sales by the end of the validation window, the network validates them on the merchant's behalf and raises the invoice anyway.

There's a decent reason for it. Left alone, some merchants never touch their sales at all - not out of malice, but because nobody at that company has been made responsible for the programme and it quietly falls off the end of somebody's job. Without auto-validation those sales sit pending forever and the publisher never gets paid for work it has already done.

Then the merchant, who wasn't paying attention in the first place, receives an invoice they weren't expecting. They query it. They dispute it. And they ask the network to reverse the validation.

The status goes forward, and then it comes back.

The moment

We showed members the validated status. It came in from the network by API, and when a sale flipped to validated we showed it, because that's the honest thing to do.

Then a member would open the app the following day and find that the sale which said validated now said tracked again.

From where they were sitting, money had appeared and then vanished. They had not been told about validation windows, merchant queries, auto-validation or invoice disputes, and they should not have to be. All they knew was that a number had gone backwards.

Some of them wrote in. Some assumed a mistake. Some assumed something worse. And every one of those contacts cost somebody time, on a transaction that had generated a few pounds of commission at best.

We had shown them a status we could not honour.

The fix

We split the status in 2.

An internal status held the true position from the network - every change, every reversal, in full. That was the system of record and it never lied to us.

A member-facing status deliberately did not show everything. A sale stayed on tracked even after the network said validated. It only moved when the money had actually arrived and been applied to the account, at which point it became payable and the member could have it.

Nothing was hidden that mattered. The member could still see the sale, the amount, and that it was in progress. What they stopped seeing was the intermediate state that could go backwards.

The principle

Only show the customer a state you are prepared to honour.

It generalises well beyond cashback. Any business showing pending, processing, approved or confirmed is making a promise on the strength of information it received from somebody else. If that information can be revised, and the customer can see it, the revision becomes your problem rather than the revising party's.

The second half is architectural. Keep the system of record and the customer view as separate things. The moment they're the same thing, every upstream correction becomes a customer-facing event, and you have handed control of your support volume to a company you have no contract with.

Why this is a scale question

That fix reduced human workload without hiring a single person. That was a headcount decision made in the data layer.

When a business tells you its costs will grow more slowly than its volume, the interesting question is never how many people it plans to hire. It's what the existing people are currently doing, and how much of it exists because of a decision somebody once made about how information moves.

Support volume is not a fixed property of a business. A meaningful share of it is manufactured by the business itself, through choices about what to display, when, and whose data to trust. Those choices are usually made early, by someone solving a different problem, and almost never revisited.

The general pattern here is that the fix moves the problem, it doesn't remove it. Auto-validation was itself a fix - it solved money that was never collected, and created money people thought had been collected. Look for that shape everywhere: a control introduced upstream to solve one party's problem, landing as a new failure mode on a party who wasn't in the room when it was designed. Auto-validation practice varies by network and changes over time; it is described here generically, from experience.

The night it kicked off

Black Friday and Cyber Monday came over from America and we plugged straight into them. They became the 2 monster days of the year, serving 4,200 retailers.

One peak year it kicked off at midnight on the Friday. Sales skyrocketed, and 2 hours in we were pulling deals off the site - because merchants had already blown their entire marketing budgets. Not their day's budget. Their budget.

The office was electric. Up north we don't get that excited easily, but it was buzzing, mental, like something off Wall Street.

And then the site crashed

The tech team had worked through the night stress-testing the traffic. It still went down.

That's the moment it hits the fan. Panic causes chaos. The customer service team was inundated, and every one of those contacts arrived at exactly the point nobody had capacity to answer them. We got it back up, went again, and made an absolute fortune. But there was a window in the middle of the best day of the year where the business could not serve the customers it had spent all year acquiring.

Success is the ultimate stress test of your operations. When you win big, the back end is the thing that buckles.

Why this one is on the page

Because it didn't end tidily, and because it's the case that taught me the most.

Every part of that night was a consequence of doing well. The traffic was a marketing success. The blown merchant budgets were a conversion success. The support volume was a member-base success. Nothing failed because the business was bad at its job - it failed because the business was good at it, and the operations underneath had been built for a normal Tuesday.

This is what happens to successful businesses when they get hit by their own success. The spicy front end wins the day. The unglamorous back end decides whether you survive it.

I don't just believe platforms sink or swim on operations. I've watched it happen at full volume, with millions on the line, in real time.

No revenue figure is given here beyond "millions in a day", because that is the level at which it can be described accurately without disclosing a former employer's trading numbers. The operational detail is the point of the story.

The symptom

Validations slow down. Payments slow down. It happens across a handful of programmes that have nothing to do with each other - different sectors, different sizes, different account managers, no shared history.

The only thing they have in common is the network they sit on. And the obvious conclusion, the one everybody reaches for, is that the network has a problem.

What's usually actually going on

Sometimes there is a marketing agency sitting between the merchant and the affiliate network, managing the programme on the merchant's behalf.

The publisher is often never told. You're dealing with a merchant name on a dashboard and a set of terms, and the person actually making the decisions - approving sales, setting validation cadence, signing off invoices - works somewhere else entirely, for a company you have no relationship with and no contract with.

One agency will typically hold several merchant accounts on the same network. So when that agency gets busy, loses a person, changes process, or simply stops prioritising validation, every merchant they manage slows down at once.

Correlated delay across unrelated programmes on the same network implies a shared cause. When I have chased one down, the shared cause has been a person rather than a system.

The detection method

• Group your delayed programmes by network, then look for clusters that have no commercial logic to them.
• Check whether the delay started at roughly the same time across the cluster. A shared start date is a strong signal.
• Compare the cadence - if several programmes are all validating in the same weekly or monthly rhythm, that rhythm belongs to somebody's diary, not to the merchants.
• Then ask the network directly who manages the programme day to day. They usually know. They just don't volunteer it, because from their side it isn't a secret - it simply never came up.

Why it matters commercially

You cannot fix a relationship with a party you don't know exists. Every escalation goes to the wrong place. Every chase lands with a merchant contact who isn't the decision-maker. The delay gets logged internally as "the network being slow", which is both wrong and unfixable, and the same conversation happens again the following quarter.

And there's a forecasting consequence. If your payment timings are being set by an agency's workload rather than by your own merchants, then your working capital assumptions are built on a variable you have never identified, let alone modelled.

This is described from professional experience rather than a published source. Agency involvement varies enormously by merchant and by network, and the detection method above is a strong signal rather than a proof - correlated delay can also mean a genuine network-side issue. The point is that the third explanation is the one that rarely gets checked.