This is a composite, drawn from conversations with several people who run seller operations at marketplaces. The details have been changed and it is not one person's account, which is why there is no name on it.
The marketplace sells handmade ceramics. Around 430 active sellers across fourteen countries, most of them one person and a kiln. Payouts run on the fifth of every month.
On the sixth, the seller-operations lead opens an inbox with somewhere between thirty and fifty emails in it, and every one of them is a version of the same question.
Where is my money.
Why "let me check" takes three days
They cannot answer any of those emails from the inbox they are reading.
The payout run happened inside a system they have read access to, sometimes, if the finance lead is at their desk. Per-seller results live in a CSV that lands in a shared drive, sorted by internal payee ID rather than shop name, which means answering one seller's question involves finding that seller's ID first. There are 430 of them.
So the reply is "let me check and get back to you," written thirty times before lunch.Then a spreadsheet of names. Then a Slack message to an engineer who is mid-sprint and who will, kindly, run a query that afternoon or tomorrow. That query costs the engineer half a day and the seller-operations lead most of a week, and it produces information that was already sitting in a table. By the time an answer comes back, the seller has sent a second email, and some of them have posted in the seller forum, where the tone is worse and other sellers are now also wondering. The whole cycle then repeats on the sixth of the following month, with the same people, about a different set of invoices.
None of that work produced anything. The information existed the whole time.
What was actually wrong
Here is the breakdown from one of those months, which is the part that changed how they thought about it.
Twelve sellers had genuinely been held before the run, because their tax details were incomplete. All twelve had been sent an automated email about it eleven days earlier. None of the twelve had opened it, which is a fact about automated emails rather than about those sellers.
Six had bank details that bounced. They did not know, because nobody had told them, and the failure had been logged in a system none of them could see.
The other twenty-two had been paid. On time, correctly, on the fifth. They were writing in because the money had not appeared in their account yet and they had no way of knowing whether that was normal, and a payout that takes two working days to settle looks identical to a payout that never happened if you are watching a bank app.
Eighteen real problems. Twenty-two emails that were not problems at all.
What changed
Two things, and they are separate.
The first was giving sellers somewhere sellers can look without asking. Not a status page for the platform, a view of their own payout: what was sent, when, what state it is in, and whether anything is waiting on them. The twenty-something who had already been paid stopped writing in almost immediately. Not because they became more patient, but because the question they had was answerable and now it was answered.
The second was making the run itself report properly, so that status on each row of the run is visible to the person answering the email rather than to the person who ran the batch. "Let me check" became a sentence in the same reply instead of a promise about tomorrow. That mattered more for the eighteen genuine problems than for the twenty non-problems, because the twelve held sellers needed to be told something specific and actionable, and the six with bad account details needed to be told immediately rather than in four days.
The seller-ops lead described the change less as a time saving and more as no longer starting the week owing thirty people an answer they did not have.
What it does not fix
It does not reduce the number of failed payouts.
Bad account details still fail. Incomplete tax profiles still hold a payment before it moves. Nothing about better visibility makes a wrong IBAN correct, and any tool that claims otherwise is describing a different problem. What changes is who finds out, and when, and whether they are told something they can act on. Six people learning on the sixth that their bank details bounced is a much better month than six people learning it on the tenth, from someone who had to go and ask.
We are less certain how this holds up on a marketplace where selling is occasional. Some of these sellers ship every week and will happily check a portal. Someone who lists twice a year is not going to log in to look at anything, and for them the automated email that nobody opens is still the whole system. We do not have a good answer for that yet.
An earlier post on this blog is the same month from the other side of the wire, written by someone waiting for a payment that had, in fact, already been sent. Reading the two together is uncomfortable in a useful way.
Disclosure: we build payout infrastructure at Gruv, so we have a view on this. The story is a composite and the figures are illustrative.
If you run payouts for a marketplace: what fraction of your payout-day inbox is a real failure, and what fraction is someone who cannot see what happened? We would genuinely like to know whether eighteen out of forty is typical.
Top comments (0)