Guide chapters
Moderation and operator decisions
The problem#
Moderation in a small marketplace is usually one person making a few decisions every couple of days. The problem is not scale, it is that those decisions have to be reconstructable later: who, when, on what grounds, and what happened to the seller listings at the time.
Minimum version#
- A report as an entity with a subject, a reason and a reporter.
- A decision with a reason, recorded on the subject of the report.
- Seller suspension that hides listings rather than deleting the account.
- A contextual view: decision history visible on the seller and on the product.
What not to build yet#
- A queue with assignment, deadlines and priorities.
- A central staff activity log with its own interface.
- Report categorisation with a tree of reasons.
- Automatic hiding of content after a number of reports.
Plan ahead#
The decision recorded on its subject#
Suspension on the seller, listing removal on the product, resolution on the report. It is the cheapest form of history and the one that best answers the questions actually asked.
A field for the decision author from the start#
One person decides today, so the field looks redundant. It costs one field, and added a year later it leaves a year of decisions with no author that can no longer be attributed.
Suspension reversible, deletion not#
Suspension should hide listings and stop sales while leaving the account, settlements and history untouched. If deletion is the only available action, every mistake is irreversible.
Triggers#
- a second person starts making decisions;
- a seller asks why their listing disappeared;
- the same report comes back a second time;
- the number of reports stops fitting into one daily review;
- the first mistaken decision that has to be undone.
Next stage#
After the first trigger: filling in the author field and simple filters. After the fourth: a queue with a simple state, no deadlines. A central activity log only once you need to reconstruct who did what and asking the team no longer suffices.
Common mistakes#
| Assumption | Why it costs |
|---|---|
| "Deleting the listing is enough." | No trace of the decision and no way to undo a mistake. |
| "We will add the author when there is a team." | A year of decisions with no author stays that way forever. |
| "Suspension and deletion are the same." | A mistaken suspension is reversible, a deletion is not. |
| "We will remember the reason." | When the seller asks a month later, nobody does. |
| "Let us build the audit trail now." | An interface for one person who already knows what they did. |
What works in practice#
Moderation decisions on my side are visible primarily in the context of the object they concern. The question that actually gets asked is "what happened with this seller", not "what did the operator do last week". Separate logs earn their place where compliance or accountability between several people requires them, not as the default way of recording every decision.
A reversible suspension that delists rather than deletes turned out to matter more than any moderation interface. It allows reacting quickly without the risk of a costly mistake.
Checklist#
- A report has a subject, a reason and a reporter.
- The decision is recorded on the subject, with its reason.
- There is a field for the decision author, even with one person today.
- Suspension is reversible and deletes nothing.
- Decision history is visible in the seller context.
I design multi-vendor platforms with onboarding, payments, moderation, and operational workflows.
Explore marketplace development