Product Approval on a Marketplace: Manual, Automatic, or Both?

Product approval on a marketplace is the discretionary gate a new or edited product page passes before it sells, and its throughput is the ceiling on how fast your catalog can grow.

Product approval protects you from junk in the catalog and at the same time caps how fast the catalog grows. Everyone counts the first effect.

Almost nobody counts the second, until the day sellers start writing in that their offers have been sitting for a week.

This article breaks down:

• What does product approval protect a marketplace from?
• What does full manual review cost in people?
• Which 3 approval regimes can you run?
• What happens when a seller edits an approved page?

Why is the approval queue a speed limit on your marketplace?

Either you know its throughput, or it knows yours.

The approval queue is production capacity. One number describes it: how many items a day your team looks at and decides.

An example that shows the mechanism. Inflow is 400 new items a day, and your team's throughput is 300.

The queue grows by 100 a day, so after thirty days you have a backlog of 3,000, which at 300 a day means ten days of waiting for every new offer. If you promised sellers a decision within 48 hours, the promise breaks around day six and drifts further apart in a straight line.

Nothing ever raises an alarm. Every day on its own looks like an ordinary backlog.

And the seller waiting ten days on their first fifty products has not made a single sale yet and already knows your real response time.

That is why this is a board decision. Queue throughput limits supply just as much as the number of sellers you recruit.

It just never appears in the growth deck.

What does product approval protect a marketplace from?

Approval defends you against four things, and only they justify its cost:

1. A product in the wrong category. Rain boots listed under umbrellas. The damage shows up in search and in pricing.
2. A missing required field. The identifier, the brand, an attribute mandatory in the category, a field required by law.
3. An obvious policy breach. Goods you do not sell on your platform, banned content, a category that requires a permit (restricted and prohibited products).
4. A seller testing the limits. The first upload from a new account is the most informative sample you will get.

What even the best team does not give you: truthful data (nobody will weigh the parcel), text quality (that is what the requirements in what you can enforce on content are for), or any assurance that the goods exist.

This is risk sampling. Most of the disappointment comes from mixing up those two.

Manufacturing inspection says it plainly: a sampling plan is a probabilistic process distributing risk between two parties. Calling it by its right name changes the question from "do we approve" to "what risk do we accept and what sample covers it", and the second has a numerical answer.

What does full manual product approval cost in people?

Do the math out in the open, once, on paper.

An inflow of 3,000 new offers a day at two minutes per item is 6,000 minutes, or 100 hours of work every day. Divide that by an eight-hour shift, and you get 12.5 people (on the fiction that a human clicks eight hours straight, with no breaks, meetings, or vacation).

At a realistic six effective hours, that is seventeen people on clicking alone. Two minutes is optimistic too for an item with a photo gallery and thirty attributes.

Turn it around, and you have your threshold. Two people dedicated to nothing but the queue give you 720 minutes a day, which is 360 items.

Above that line, "we approve everything manually" is a declaration. Practitioners from large rollouts say plainly what happens next: the reviewer stops looking and approves in bulk, ticking everything on the page.

You end up with automation that nobody calls automation, and you pay headcount for it. The full cost of control, without the control.

The line to carry into the committee meeting: at our inflow, full manual approval costs seventeen full-time people, and that is the price of this policy.

Which 3 product approval regimes can you run?

1. Full manual review, as a pilot in one category

The point then is raw material. Two weeks of looking at real submissions tells you which errors arrive and in what proportions, the only sensible input for rules.

2. Automation plus risk sampling

The rule lets through everything that meets the conditions, and only what is risky by name reaches a human queue: a new seller and their first N products, a sensitive category, an item above a price threshold, a change to a key field on an approved page, plus a small random sample of the rest. Run that on the same inflow of 3,000.

The first fifty products from five new sellers a week come to roughly 36 items a day; sensitive categories (4% of inflow) 120, items above the price threshold (1%) 30, edits to key fields 60, and a 1% random sample 30. Together, that is 276 items, which comes to 9 hours a day and two people instead of seventeen.

3. Trust with an audit after the fact

They publish immediately, you check a random sample, and you have a written condition for withdrawing that trust. It is the only regime that scales without adding headcount, and the only one where a bad product sits on the storefront until the sample catches it.

The rules from catalog rules shrink the queue instead of policing it. That is the right order to think in.

A condition you can write down ("no identifier", "description shorter than X characters") should never create a task for a human. A discretionary gate is for the things you cannot express as a condition.

What happens when a seller edits an approved product page?

You approve the product page. The next day, the seller swaps the main photo and the title.

If an edit does not go back into the queue, you protect the first version only. The buyer is looking at the third, which nobody ever reviewed.

The market has not settled this, which makes it a question for your vendor. Some products cannot send an approved page back for review at all: edits go live immediately, and the review is post hoc.

You get a list of recently changed items, limited to fields switched on for monitoring in advance and to a window of a few dozen days. Some products can: a change to a key field moves the page into a "pending review" state and holds up sales until someone decides.

The gap between those two worlds is wider than the one between manual and automatic approval.

Count the cost of this gate too. At 200 edits a day on approved pages, if 30% touch the title, photo, or category, 60 items come back into the queue.

That is two hours of work. A cheap gate, and the one most often skipped.

Three questions for your vendor:

1. Can an edit to an approved page come back into the queue, and can I choose which fields trigger that?
2. Is an item awaiting a fresh decision taken off the storefront, or does it keep selling in the meantime? Both answers are defensible, but you have to know which one you have.
3. Can I see the value before and after the change, or only the fact that something changed?

What does an approval queue need to be a working tool?

Assignment and "read" status have to be per operator. In a shared inbox, the first click hides the item from everyone else, and practitioners call that the moment a team quietly stops working in parallel.

One person opens a submission; the rest see it as handled. The worst part: none of this shows up in any report.

The count of processed items adds up, while the submissions nobody touched disappear.

A rejection reason has to come from a closed list, and it needs two strengths. A fixable rejection ("changes required") goes back to the seller with specifics and a way back; a permanent one closes the subject, because you do not want that item on your platform.

If the reason is a free-text box, a year later you cannot count what you reject and why, and without that statistic you will never turn the most frequent reason into a rule. A rule of thumb: a reason appearing more than a few dozen times a month is a candidate for becoming a rule.

The path to fix and resubmit is part of the process. Without it, a rejection ends in an email to the account manager, which is your second queue.

It is the one you do not measure. Check that it works at scale: a seller whose 300 items you rejected has to be able to fix them in a file.

A rejection also needs a reason, delivery, and a trail. The rules on decisions about sellers cover that.

Compare the review time you promised with the real one, before a seller does it for you. If your terms say 48 hours, that is an obligation, and it breaks on its own once inflow exceeds throughput.

Watch out too for a deadline with a destructive default: some products purge unreviewed items after somewhere between a few days and a couple of weeks, together with the linked offer drafts. With a backlog of 3,000 and throughput of 300 a day, items at the bottom of the queue drop out on the very day you meant to look at them.

In the reports, it reads as "the seller never listed anything".

What does the approval queue change about the rest of your marketplace?

1. Queue throughput belongs in the supply plan

If you recruit twenty sellers a quarter and each brings in a few thousand items, that is a number to put next to your headcount before you sign the plan.

2. Rules are cheaper than headcount

A good rule takes a task off the queue that should never have landed in it.

3. Approval works at the entrance only

Items that got in before the gate existed bypass it forever. That is a separate problem with a separate budget, and catalog debt takes it up.

4. Edit rights decide how many decisions are left

Data ownership is field ownership. A dispute between two sellers over the same value is "When Two Marketplace Sellers Disagree About Product Data".

5. Money enters here through time

An offer waiting in the queue does not sell: on a €1,000 cart at a 12% commission, an order that never happens is €120 you do not have and €880 the seller does not have. They do that math faster than you do.

How do you set up product approval without extra headcount?

1. Measure two numbers for a week: items arriving per day and the real handling time per item. Multiply them for the hours you need; divide them for your throughput.
2. Cost out full manual review. If it comes to more than two full-time people, the decision is already made.
3. List the gates from the highest risk down and calculate each one's share of inflow. The target: a human sees 5 to 15% of items. Above twenty percent, you are back to clicking in bulk.
4. Set up a closed list of rejection reasons with two types. Eight to twelve is enough to start with; a longer list does not get used.
5. Turn on re-review after an edit for three to five fields. Main photo, title, category, and a price threshold carry most of the risk for a small share of the queue.
6. Track one number every week: time in queue in percentiles. Systems measurement practice is unambiguous here: an average hides the tail of the distribution, and the tail is what people complain about. A median of 4 hours and a ninetieth percentile of 9 days are the same queue. The first number describes your typical seller; the second, the one who will write in.
7. Set one alarm threshold: the queue grows three days in a row. That means either the gate is too wide or the inflow has changed.

Three more questions for your vendor: assignment of an item to an operator and a separate "read" state per user · rejection reasons as a configurable list with a type and a resubmission path, including a bulk one · time in queue in percentiles, per seller and category.

Which mistakes do operators make about product approval?

1. Approval introduced without anyone counting throughput

The policy exists; the number does not. The consequence: the queue becomes your supply limit, and you hear about it from a seller.

2. Manual approval kept above the threshold

The reviewer stops looking and approves in bulk. You pay the full cost of control and have no control, and in the metrics it looks better than before, because the number of processed items goes up.

3. A gate at the entrance only

You protect the first version of the page while the third one sells. One swapped photo cancels the whole investment in approving that item.

4. A shared queue with no per-operator state

Some submissions get done twice, some not at all, and the report agrees with itself. The mistake leaves no trace in the numbers, so it is the hardest one to find.

5. A free text box as the rejection reason

The seller gets "fix the description," and a year later you do not know what you reject most often. Rejections stop being data.

What do you still have to settle about approving products?

It does not say what to require from content ("Product Data Quality on a Marketplace: What You Can Enforce") or how to write a rule and what it should do to an already published catalog ("Catalog Rules on a Marketplace: Validation Before and After Publication"). Those are separate decisions, and they change the size of the queue.

Nor is it an org design: how many people and in which department belong to the chapter on staffing.

It does not settle whether rejecting an offer requires a justification from you in a set form and within a set deadline. That depends on your contract with sellers and on the regime you operate under.

It does not settle which fields are mandatory for you because of the law, or which categories require a permit.

All the numbers here are openly hypothetical. The arithmetic travels; the values do not: substitute your own inflow and handling time per item, because every conclusion above depends on them.

Summary: What decides your product approval regime?

Two numbers you can measure in a week: how many items arrive a day, and how long one really takes to decide. Multiply them for the hours you need and divide them for your throughput, and the choice of regime makes itself.

Above about two people's worth of work, full manual review turns into bulk approval that costs the same and catches nothing. Below that, the useful question stops being whether to approve and becomes which risks are worth a human: a new seller's first products, a sensitive category, a price above a threshold, an edit to a key field, and a small random sample of everything else.

Measure your daily inflow and your real handling time for one week, then cost out full manual review. Building a marketplace where only the risky 5 to 15% of submissions reach a person?

Talk to us about the build.

Frequently asked questions on marketplace product approval

Should a marketplace approve every product manually?

Only as a pilot in one category, and only to learn which errors arrive and in what proportions. Past roughly 360 items a day, the reviewer stops looking and approves in bulk, so you pay for control and get none of it. After the pilot, rules carry the deterministic checks and a human sees the risky remainder.

What does product approval catch?

Four things: a product in the wrong category, a missing required field, an obvious policy breach, and a new seller testing the limits. It gives you no assurance that the data is true, that the text is good, or that the goods exist. Treat it as risk sampling rather than quality control.

Does an edit to an approved product page need reviewing again?

Yes, for the few fields that carry the risk: main photo, title, category, and a price threshold. Some platforms cannot send an approved page back for review at all, which leaves you protecting the first version while the third one sells.