Marketplace Customer Service: Who Answers the Buyer, You or the Seller?

Marketplace customer service is the decision about who answers the buyer first, you or the seller, and because somebody else's turnover generates contacts at the same rate as your own sales, the answer comes out of an arithmetic of staffing rather than a statement about service quality.

This is the one after-sales decision you take once and cannot really undo. The buyer remembers who wrote back, and sellers build their processes around your choice.

What settles it is the arithmetic of staffing rather than a declaration about service quality.

This article breaks down:

• Which 3 support models can you run?
• When should you take a case over?
• What does one more language cost?
• Who owns the pre-sales queue?

Key insights

• The three support models are seller-first, operator-first, and a mixed setup with a threshold, and on 1,600 contacts a month they cost 109, 240, and 162 hours of your team's time, which is €0.52, €1.14, and €0.77 per order.
• Taking a case over should run off a list of events rather than off the word difficult: a second reading of somebody else's thread costs 14 minutes against 9, so any category that comes back more than half the time is cheaper to take at once.
• One more language costs coverage rather than handling time: 128 contacts a month is 19 hours of work against 168 hours of declared availability, so utilization lands at 11% and nine tenths of that staffing is bought as readiness.
• The pre-sales queue has no order number, so it has no seller and usually no owner, and it scales with traffic: 400,000 sessions at half a percent is 2,000 tickets, more than every after-sales contact put together.

Why does third-party turnover cost as much to support as your own?

Customer support is the only place where somebody else's sales generate your cost in a straight line. Selling by third parties brings you no trade margin, only a commission.

The share of orders where somebody writes in or picks up the phone is the same as on your own sales. It does not depend on whose goods were in the box.

Work it out on a single ticket. A support role costing €12,000 a month against 126 genuinely effective hours comes to about €95 for an hour of work, which is €14 for a nine-minute contact.

On a €1,000 cart at a 12% commission, you make €120 on that order, so one ticket eats close to 12% of the commission. The same sale on your own account at a 25% margin would give you €250, and the ticket would cost 5.7% of the margin.

Identical work, twice the share of what is left.

On a low cart, it turns dramatic. A €150 cart is €18 of commission, and one ticket at €14 takes 79% of it.

Then there is scale. A hundred thousand orders a year, eight percent of them generating a contact and nine minutes per contact, comes to 8,000 tickets and 1,200 hours.

That is close to ten months of work for one person. It is worth putting that number next to the growth forecast, because nobody ever puts it there.

Which 3 support models can a marketplace run?

Work on one example. 20,000 sellers order a month, 8% of them generating a contact, so 1,600 contacts.

Three handling times: 2 minutes to read a case and route it, 9 minutes to settle it yourself, 14 minutes to take a case over from a seller. That last one is longer because you read somebody else's thread from the start.

1. Seller-first

The buyer writes to the seller through your channel, you see the thread, and you step in once the threshold is crossed.

Your team touches every message anyway, because somebody has to route it. 1,600 × 2 minutes is 53 hours, plus 15% of cases taken over: 240 × 14 minutes is 56 hours.

Together, 109 hours, which is 0.87 FTE.

2. Operator-first

You answer everything and the seller is your back office.

1,600 × 9 minutes is 240 hours, which is 1.9 FTE. That is more than twice as much.

In exchange, you get one tone of voice and one place where you know what was promised.

3. A mixed setup with a handover threshold

The seller answers by default, but the cases you listed, category by category, you take straight away.

At 35% of cases taken on the spot and 10% of the rest coming back: 53 + 84 + 24 hours, which is 162 hours and about 1.3 FTE.

The conclusion that surprises people the first time they count: seller-first is cheaper by more than half rather than free. The rest cannot be handed over.

When should you take a case over from a seller?

The handover threshold is what separates the mixed model from chaos, and it has to be a list of events rather than an adjective. "When the case is difficult" is not a threshold: every agent sets it in a different place, and six months later you cannot count how many cases you really took over.

Events that work as a threshold:

• no reply from the seller within the window you announced yourself
• a second round on the same case
• a case about money already taken
• a case about the safety of the goods (product safety and recalls)
• a seller under suspension (seller quality thresholds)

Taking a case over costs more than handling it from the start, because you are paying for a second reading. In the example above, that is 14 minutes instead of 9.

Per case, it is 56% more expensive. Hence the practical rule: if some category of cases comes back to you more often than half the time, it is cheaper to take it straight away than to raise the threshold.

Deciding a disputed case, the taxonomy of reasons, and holding a payout are separate mechanisms. That is set out in the chapter on who decides a disputed case.

Here the only question is who picks up the phone, and out of whose headcount.

What should your agent see inside a seller's panel?

Your agent needs two different things. The first is visibility: shipping address, tracking number, status of a return, message history.

The second is acting inside the seller's panel, which is impersonation.

Impersonation is a question of least privilege rather than of convenience. The principle says that every party gets the minimum resources it needs to perform its function.

So the question is not "can the agent get into the seller's account" but "what will they not see once they are in". A bank account number and an integration key are fields a support team never needs, and they sit in plain view once you are inside somebody else's account.

The market is split. Some products restrict seller mode field by field. Banking details and keys stay invisible, and every entry lands in the history. Others give full access to everything the seller sees, with no trace in the logs.

And the biggest trap of all: impersonation makes a poor plan for a silent seller. Where seller mode is built sensibly, it blocks writing messages and marking them as read.

Those are exactly what you wanted to go in there for. And where it does not block them, you have just answered a buyer as somebody else, which is behaving as the seller in the sense of whether you are an intermediary or a seller.

What runs underneath a marketplace support channel?

The conversation on an order looks like a chat, and underneath it is usually email: the buyer gets a masked address, the seller writes to it, and the message drops into the thread. Masking as a data protection regime is explained in the chapter on who controls the personal data.

What counts here is that this is the infrastructure of your support channel rather than a privacy setting.

Three things to settle before the first message goes out.

Whether a reply to a notification comes back into the thread. In the default setup of many implementations, notifications are one-way.

The buyer hits "reply" and writes into nowhere. Nothing bounces back, so they wait.

Who technically owns the sending address? Mail authentication and domain reputation are the conditions for a message arriving at all.

The guidelines of large mailbox providers require bulk senders to hold a full set of authentication records, and warn against a sudden jump in volume from a domain with no history.

The warning that weighs most in this chapter: changing the sending domain cuts the threads that are already running, in both directions at once. Both sides then go quiet, because each believes it is waiting for the other.

The seller assumes the buyer gave up. The buyer assumes the seller is ignoring them.

Practitioners describe such a change, made outside the support team, as an outage of the whole messaging channel. So the sending address belongs to the support model rather than to the marketing backlog.

What does one more language of support cost?

Adding a language goes beyond translating the interface. It is staffing a queue with a person who will write back in that language, in the hours you announced.

The text layer costs something too. In implementations we know, the list of keys for message and document templates runs into hundreds of entries per language.

But that is a one-time cost. Staffing is monthly.

Count a market that gives you 8% of your volume: 128 contacts at nine minutes each is 19 hours of work a month. Declaring that you are there on working days for eight hours is 168 hours of coverage, which is 1.33 FTE.

Utilization comes to 11%, so almost nine-tenths of that staffing you buy as readiness rather than as work.

Three conclusions follow. The smallest unit of coverage is a person rather than an hour.

A channel that cannot be deferred costs you coverage rather than handling time. A phone has to be picked up at the moment it rings.

And every combination of language × channel × band of hours is a separate commitment, so three languages on two channels are six promises to staff.

Who owns the pre-sales question queue?

An after-sales ticket has an order number, so it has a seller. A pre-sales question has neither.

That is why it usually has no owner and no budget either.

This queue scales with traffic rather than with orders, so it can be bigger than the after-sales one. 400,000 sessions a month and half a percent of them asking a question is 2,000 tickets.

That is more than all 1,600 after-sales contacts put together. At five minutes each, that is 167 hours, which is 1.3 FTE on a queue that appears in nobody's plan.

Two things are worth knowing. In typical implementations, neither the operator nor the seller can open a thread on an offer.

Only the buyer can, so this stream exists whether or not you planned for it. And it is not only a cost: an answer before the purchase moves sales, so the queue you cut first is the only one that earns.

What does the support model change about the rest of your build?

1. The support model is an integration decision rather than a headcount decision

If you answer yourself, your ticketing system has to get the order, the seller, and the status of the return in one object. Practitioners describe a specific gap here: a message about an order and a complaint ticket land in one bucket, with no type given when the thread is opened.

Without a type, you cannot route a case to the right team, and you cannot count how many of each you have.

2. The choice of model switches a whole quality metric on or off

The seller's response time to a buyer's message is a ready-made criterion in market implementations, but it counts only while the conversation runs through the platform channel. Under operator-first, it measures nobody but you.

Thresholds and sanctions are the subject of seller quality thresholds, and the effect of support on ratings is covered in the chapter on reviews and ratings.

3. Changing the model after a year changes the terms of the arrangement

A seller who hired a person to answer messages does not have the same costs as one who never had to. The manner, the notice and the delivery of such a change are set out in the chapter on the rules on decisions about sellers.

4. The money leaves through separate doors

Four separate mechanisms: who pays for a refund, the commission on a refund, the buyer's payment claim, and corrections to documents, each with a chapter of its own. The queue for seller support has a different unit and a different budget.

That is explained in the chapter on seller support and education.

How do you choose a marketplace support model?

1. Measure the share of orders that generate a contact on your own sales, over a month. That number cannot be borrowed, and it feeds all three calculations.
2. Run the three variants on your own volume and give the result in euros per order rather than in FTE. FTE are easier to vote down.
3. Set the cost per order against the commission from that order. Separately for a typical cart and for your cheapest category. The second number decides whether you want that category at all.
4. Write the handover threshold out as a list of events and count how many cases a month pass through it.
5. Count the pre-sales queue separately and give it an owner.

Five questions for the vendor, each to be shown on screen:

1. Does a thread get a type at the moment it is opened, and can routing to two different teams be built on it?
2. Is the operator a participant in the conversation between buyer and seller, or only a reader of it? And who can start it.
3. What will an agent not see and not do in seller mode, and does entering leave an event in the history?
4. Does a reply to an email notification come back into the thread, or is it lost?
5. How many text keys per language, and who maintains them on our side?

Which mistakes do operators make about marketplace support?

1. A model picked by declaration instead of by calculation

"We keep service quality in-house" means operator-first, and it costs twice as much as the variant the board had in mind. The consequence: headcount added quarter after quarter with no decision behind it.

2. A handover threshold described with an adjective

The consequence: every agent has their own threshold, the share of cases taken over cannot be counted, and you do not know which model you are running.

3. Impersonation as the plan for a silent seller

The consequence: either the feature does not allow it and the plan does not exist, or it does, and you have just answered a buyer under somebody else's name.

4. A language added without staffing the coverage

The consequence: the promise of being there breaks in the first week one person takes off.

5. A sending address changed outside the support team

The consequence: both sides of the conversation go quiet, and both blame the other.

What do you still have to settle about your own support model?

This article does not settle a disputed case. Who decides what the taxonomy of reasons looks like and what happens to the payout while a case runs: who decides a disputed case.

This article stops at who picks up the phone.

This article does not settle whose voice a message speaks in. The sender, the signature, and where a reply leads: showing who the seller is.

Masking contact details as a data protection regime: who controls the personal data.

This article does not settle the legal layer, and it deliberately gives no deadlines and no thresholds. Which contact channel you have to open to the buyer and what you have to disclose before the purchase: who delivers the buyer's rights.

When taking support over changes your role toward the goods: whether you are an intermediary or a seller. The reasons for a decision toward a seller and its delivery: the rules on decisions about sellers.

Categories that need special handling: restricted and prohibited products.

The families of regulation to ask a lawyer about before you set the channel up:

• consumer protection, in the part about information duties and means of contact
• transparency in the relationship between platform and sellers, hence the procedure for handling a seller's complaint
• the liability of intermediary services, hence the requirement for a trace on reports
• the protection of personal data in the messaging channel and in call recording
• out-of-court resolution of consumer disputes (ADR), because it changes where a case you did not close ends up

Every number above is openly hypothetical. The arithmetic transfers: substitute your own share of orders that generate a contact, your own handling time and your own cost of a role.

Summary: Who should answer the buyer?

The seller first, with a written list of the cases you take on the spot. That answer comes out of arithmetic rather than out of a view about service quality.

Somebody else's turnover generates contacts at the same rate as your own sales while leaving you a commission instead of a margin, so one ticket at €14 eats 12% of the commission on a €1,000 cart and 79% of it on a €150 one. Seller-first is cheaper by more than half, and the part you cannot hand over is the reading: somebody has to open the message to know whose it is.

Around that sit three decisions nobody budgets for, and all three are staffing rather than configuration. Which cases cross the handover threshold.

What your agent may see inside a seller's panel. And who answers the questions that arrive before anybody has bought anything.

Ask a vendor whether a thread gets a type the moment it opens, and what an agent cannot see in seller mode. Building a marketplace where the support model is costed per order before it is announced?

Talk to us about the build.

Frequently asked questions on marketplace customer service

Who should handle customer service on a marketplace?

Customer service on a marketplace should start with the seller and escalate to you on named events. Answering everything yourself costs more than twice as much at the same volume, and handing everything to sellers is impossible, because your team still reads every message to route it.

The threshold is what separates the two models from chaos.

What does marketplace customer service cost per order?

Marketplace customer service costs between €0.52 and €1.14 per order at the same volume, and the model picks the number. On 20,000 orders a month with 8% generating a contact, seller-first comes to 109 hours, a mixed model to 162, and operator-first to 240.

Set that figure against the commission on your cheapest category before you choose.

Should an operator answer on behalf of a seller?

An operator can answer on behalf of a seller, and impersonation makes a poor plan for a silent one. Where seller mode is built carefully, it blocks writing messages, which is the reason you went in.

Where it does not block them, you have answered a buyer under somebody else's name, and that is one of the things weighed when your role toward the goods is assessed.