Seller Requests on a Marketplace: Brands, Categories, and Exceptions

A marketplace brand approval process is one of the four requests a seller files – brand access, opening a category, an exception to a rule, and restoring an account – and each of them is a policy question whose answer outlives the conversation that produced it.

A request to add a brand, to open a category, to get a lower rate. Each looks like an operational detail, and each is the opening sentence of a policy you never wrote.

A year later you have three hundred precedents instead of one rule.

This article breaks down:

• Which 4 types of seller requests arrive?
• What does a request policy need in advance?
• How do you cap exceptions before they rewrite the grid?
• What do seller requests cost in headcount?

Key insights

• The four types of seller request are brand access, opening a category, an exception to a rule, and restoring an account, and they differ in who may settle them, what the decision rests on, and what it leaves behind.
• A request policy needs three things in advance for every type: a criterion, a named decision-maker, and a default answer, because at 400 sellers you refuse roughly 96% of category requests and every refusal without a default is a discretionary decision somebody has to defend.
• You cap exceptions by counting them: set the limit as a share of your base, such as no more than 5% of active sellers on non-standard terms, because twelve quiet cuts of three points on the rate add up to €432,000 a year that nobody ever saw in one place.
• Seller requests cost about 55 hours a month at 400 sellers and 273 hours at 2,000, which is 2.2 full-time people, and the bottleneck is not headcount but the 280 decisions a month that sit outside the operator's mandate.

Why is every seller request a policy question?

A request from a seller is not a task to tick off. It is a question whose answer outlives the conversation.

You answer once and forget. The seller saves the answer and forwards it to their accountant, their integrator, and a colleague in the trade.

Three months later that colleague files the same request and quotes what the first one got.

The asymmetry of memory is the whole mechanism here. You handle a hundred and fifty requests a month.

The seller files one a year and remembers it exactly. Your team turns over, the inbox gets archived, and sellers talk to each other more often than you assume.

Three different answers to the same question are not three slips. They are proof that you have no policy.

Which gives the one sentence from this article worth repeating to the board: having no policy does not mean having no decision; it means the policy gets written by whoever happened to answer the email. Usually the most junior person on the team, under pressure from a seller threatening to leave.

Which 4 types of seller requests arrive in one inbox?

Requests look identical because they arrive through the same channel. They differ in everything else: who has the right to settle them, what the decision rests on, and what is left behind once you say yes.

Brand access is really two different requests, glued into one all the time. The first: "your list does not have my brand, please add it." That is catalog hygiene, and the decision is cheap.

The second: "I want to sell a brand you have restricted." That is distribution policy, and the decision is expensive and hard to enforce. Maintaining a list of authorized sellers at the individual product level does not hold up in practice: with a million items and thousands of accounts, nobody can police it.

The workable form is a policy at brand or category level, and exclusivity itself can be politically awkward in an open multi-category catalog, because a brand lives in several categories at once.

Opening a category is a decision about risk and about work rather than about consent. Consent is the cheapest part.

After that you have to add a branch to the tree, settle the required attributes, think through search and SEO, update the seller terms and give every seller advance notice of the change. Practitioners describe a path measured in weeks that passes through several people.

An exception to a rule is a financial decision in operational disguise. It can be an exception to a rate, a deadline, a threshold or a cap.

This is where the weight of the whole article sits.

Restoring an account is a quality decision with a chapter of its own: reinstatement and the probation period carries the criteria and the probation period.

The last two rows are an example rather than a measurement. The proportion in them holds anyway: most requests concern the cheapest matter, while the most expensive decisions stand in the same queue and wait just as long.

What does a request policy need before the first request?

The operating rule is short. Before launch, every type of request has three things: a criterion, a named decision-maker, and a default answer.

The third is most often left out and needed most, because it settles every case nobody gets back to. Internal control standards say the same outright: a policy names the unit responsible for the process and gets reviewed periodically.

Without a named decision-maker, a policy is an intention rather than a control.

Here is how it works on numbers. With four hundred active sellers and an average of 0.4 requests per seller per month, you get 160 requests a month, about 16 of them asking to open a category.

Realistically, you open two categories a quarter, so against 48 requests a quarter, you say "no" or "not now" in 96 percent of cases. With no default answer, each of those 46 refusals is a separate discretionary decision somebody has to justify in a conversation.

Today this work lives in an inbox, a spreadsheet, and a decision reached in a meeting. The channel itself is covered by the rules on decisions about sellers, and the problem here is a different one: if there is nothing in the system to approve, there is nothing to count either.

You cannot answer how many times this year somebody asked for a lower rate and how many times you agreed.

How do you stop exceptions from rewriting your commission grid?

The strongest mechanism in this chapter costs one column in a report. For every type of exception, count how many times you granted it and set a cap in advance.

Above the cap, you have two legitimate answers and no third: either you write the condition into the terms for everyone, or you stop granting it.

Watch how fast it compounds. The canonical example of this series: a cart of €1,000, a commission of 12%, and €880 landing with the seller.

You cut one seller's rate to 9%. They now take €910; you take €90 instead of €120, which is €30 less on every thousand of turnover.

At their turnover of €200,000 a month, that is 200 carts, so €6,000 a month and €72,000 a year for one conversation with no document behind it. Grant the same exception over a year to twelve sellers at half that scale (€3,000 a month each), and you are at €36,000 a month and €432,000 a year.

Nobody approved that amount, because nobody ever saw it in one place.

So set the cap as a percentage of your base rather than as an amount: no more than 5% of active sellers on non-standard terms. At four hundred accounts, that is twenty exceptions and a hard edge to the conversation.

The pattern is proven outside commerce. Credit supervision requires a written justification for every departure from policy, a report listing all departures, and their combined value reaching the board on a cycle and staying under an agreed limit.

A single departure is a known risk. The sum of departures is often a risk nobody knows about.

Requests that change financial terms have one more property: you cannot settle them once and be done. Agreeing to 9% is a commitment for future periods, so it has to enter the system as a version of the terms with a date it takes effect and a date it expires, rather than as an overwritten field.

Without that, the first reconciliation of rates against the published document shows a gap nobody can explain.

Which 7 fields turn a seller request into an object?

To count any of this, a request has to be a record rather than a message. Seven fields: type, seller, justification, evidence, decision-maker, deadline, outcome with a reason from a closed list.

The last one is the condition for any report at all: if the reason for a refusal is free text, a year later you cannot count what you refuse most often, and that is exactly your list of candidates for a rule. Evidence is not decoration.

On brand access, it is the only thing separating an authorized distributor from somebody betting that nobody will check.

The second specific is operational, and almost nobody asks a vendor about it. The state of a request has to be per item and per owner rather than "read" per inbox.

In a shared inbox, the first click hides the request from everyone else. The team quietly stops working in parallel, while the report's count of handled requests still adds up.

Systems built for queue work solved this differently: the task sits on a list of candidates until somebody claims it, and only then does it get a named owner and drop off everyone else's list. One difference decides the whole thing: it disappears because somebody took it rather than because somebody opened it.

The queue as a team's working tool gets a fuller treatment in the approval queue.

What do seller requests cost in headcount?

Do the math once, in the open: the number of active sellers × requests per seller per month × handling time.

At 400 sellers and 160 requests a month, with the times from the table, you get 880 + 480 + 1,200 + 720 minutes, which is 3,280 minutes, or about 55 hours a month. That is less than half a full-time person, which is why nobody sees a problem at this scale.

At 2,000 sellers, the same proportions give 800 requests and 16,400 minutes, or 273 hours. At 126 realistically effective hours per person per month, that comes to 2.2 full-time people on handling alone.

Headcount is not the bottleneck, though. Escalations are.

At 2,000 sellers, 80 category requests and 200 financial exception requests come to 280 decisions a month outside the operator's mandate, which is fourteen a day for somebody who has another job. You do not fix that with staffing.

From this scale-up, you buy policy instead of people, because a policy answers without a meeting.

Work out the waiting time from the standard queueing theory identity: the number of cases in the system equals the rate of arrivals times the average time in the system. Turn it around, and you get the answer the seller will ask for first.

Thirty requests in the queue while you close eight a day is 3.75 days of waiting. If your terms promised 48 hours, the promise is already broken.

What do seller requests change about the rest of your build?

1. The data model needs a "request" object separate from a "decision" object

A request comes in from the seller and carries a clock. A decision goes out from you and carries a reason, delivery, and a trail.

Glued together, they give you an inbox you cannot build a report from.

2. Every financial exception propagates into settlement

A dated version of the terms, per seller and per category, is the condition for reconciling commission against the published document: the documents you sign with a seller and the rules on decisions about sellers.

3. Brand and category requests propagate into the catalog

A free-text brand field zeroes out the request queue and produces catalog debt (offer matching and catalog debt). A new branch of the tree is the work in the category tree.

4. Some of the exceptions you promise a seller are not in your hands

In rollouts we know of, switching on the mechanism that restricts sales of a brand, or raising a cap, required a ticket to the platform vendor. Your promise then carries a dependency the seller knows nothing about.

How do you check the request queue with a vendor?

Five questions, and each needs to be shown on screen:

1. Show me the list of requests from sellers broken down by type, with a deadline and an outcome. If the answer is "it comes in by email", count this work into the scope of the rollout.
2. Who owns a request, and what do other operators see when one of them opens it? An answer of "we have read and unread" means there is no assignment.
3. Show me a rate exception as a version of the terms with a start date and an end date, and then an order from last week and the rate the system treated as in force for it.
4. How many times this year have you granted an exception of type X? If that number is not in the system, there is no cap either, and a cap is the only defense against a quiet change to your grid.
5. Which of these things require a ticket to you as the vendor, and which can we do ourselves from the panel?

Three things to count on your own side: requests per seller per month, the share of requests that need a decision outside the operator's mandate, and the number of exceptions to the standard rate in force today. The third one is usually higher than the board assumes.

Which mistakes do operators make about seller requests?

1. The first answer given with no policy behind it

It sets the precedent for everything that follows, and it gets made at the worst moment: with the seller you badly want to keep.

2. An exception with no expiry date

A condition granted "to get you started" is still in force four years later, because nobody scheduled a review. Taking it away at that point is a change of terms, and it looks like a punishment.

3. One queue for four types of requests

The cheapest type sets the pace, and financial decisions get settled by whoever was on shift. Nothing in the queue tells them it is not their mandate.

4. A financial agreement recorded outside the grid

Reconciling rates against the document shows a gap, and you cannot reconstruct who agreed to 9% or when.

5. A shared queue with no owner on the item

Some requests get handled twice, some not at all, and the report agrees with itself. It leaves no trace in the numbers, so the person who finds it is the seller writing in again after three weeks.

What do you still have to settle about your own request policy?

This article does not cover grievances. A request asks for something you do not have yet.

A grievance objects to a decision you have already made. Grievances have a different bar and a procedure of their own.

This article does not settle the matters run by neighboring chapters. A dispute between two sellers over product data is disputes over product data.

Permits in regulated categories and gating on a permit: restricted and prohibited products.

"How do I do this" questions and the whole support layer: seller support and education, and those are not requests and do not belong in this queue.

This article does not say what deadlines and what forms bind you when you refuse, or when you change terms. That depends on the regime you operate under.

Check with a lawyer the family of regulations on transparency between a platform and its sellers, known in the trade as P2B, and settle two things: what you have to deliver when you refuse, and how much notice a change of terms requires, including when the change is the withdrawal of an exception.

All the numbers above are openly hypothetical. The arithmetic travels, the values do not.

Substitute your own number of sellers, your own mix of request types and your own handling time.

Summary: What turns seller requests into a policy?

A criterion, a named decision-maker, and a default answer, written down before the first request arrives.

Four kinds of requests come through one channel and differ in everything else: adding a brand is catalog hygiene, opening a category is weeks of work across several people, an exception to a rule is a financial decision in operational clothing, and restoring an account is a quality decision with its own chapter.

The one that compounds is the exception, which is why it needs a counter and a cap expressed as a share of your base. And the queue itself has to hold a request as a record with an owner, because a shared inbox where the first click hides the item produces a report that agrees with itself and a seller writing in again after three weeks.

Ask a vendor to show you a rate exception as a dated version of the terms, then an order from last week and the rate the system treated as in force. Building a marketplace where a seller request is an object with a deadline, an owner, and a reason from a closed list?

Talk to us about the build.

Frequently asked questions on seller requests

What is a brand approval process on a marketplace?

A brand approval process on a marketplace covers two requests that look the same and are not. One is catalog hygiene: the brand is missing from your list, and somebody wants it added.

The other is distribution policy: a seller wants to list a brand you have restricted. The first is cheap to settle; the second is expensive to enforce, which is why the workable form of a restriction lives at brand or category level rather than per item.

How should a marketplace handle exception requests from sellers?

A marketplace should handle exception requests by counting them against a cap it set in advance. Above the cap, there are two honest answers and no third: write the condition into the terms for everyone, or stop granting it.

Each exception also has to enter the system as a dated version of the terms with an expiry, because a rate agreed in a conversation and typed over a field cannot be reconciled a year later.

How long should a seller wait for a decision on a request?

A seller waits exactly as long as your queue makes them wait, and that number is arithmetic rather than policy. Thirty requests in the queue with eight closed a day is 3.75 days.

If your terms promised 48 hours, the promise is already broken, and no amount of prioritising inside the inbox will fix it.