AI support for marketplaces, side-aware across the two queues.

Pull the last quarter of tickets from a typical two-sided marketplace doing twenty to a hundred million GMV and the queue split is the first thing the export shows. Roughly forty to fifty percent of inbound is supply-side tickets (sellers asking about payouts, listing rejections, KYC document status, dispute outcomes, Stripe Connect onboarding errors, vendor finance reconciliation). Roughly forty to fifty percent is demand-side tickets (buyers asking about order status, refund requests, account recovery, payment failures, escrow release timing). The remaining ten percent is the disputes between the two sides where both queues collide and somebody at the platform has to make a judgement call. Three queues, two policy stacks, one support team that is structurally too small to cover any of them well.

The reason staffing this is hard is that supply and demand support do not look alike. Supply-side tickets are higher-context, lower-volume, longer-resolution. A seller asking about a payout split needs the agent to know the payout history, the current Stripe Connect transfer state, the take rate exposure, the chargeback ledger, and any holds on the account. The reply that lands has to be specific to that vendor and that payout cycle, in the vendor language, with the right next-step action. Demand-side tickets are lower-context, higher-volume, shorter-resolution. A buyer asking about order status needs the agent to know the order, the seller fulfilment status, the carrier tracking, and the escrow release timing. Same ticket on each side requires a completely different context window and a completely different policy stack, and a generic help-desk team handling both ends up doing both badly.

The other complication is the dispute queue between the two sides. A seller claiming a buyer refused delivery to extract a refund. A buyer claiming the seller shipped a counterfeit. A KYC verification failing because the document the seller uploaded does not match the registered business name. A payout held because the platform fraud system flagged a chargeback pattern. Each of these tickets has both sides as stakeholders, both sides expecting communication in their own language, and both sides watching the response time to decide whether the platform protects them. We covered the structural shape of the duplicated functions problem in AI for Marketplaces. The support function is the part of that doubling where the trust signal compounds fastest in either direction.

The engineering of side-aware routing is the part most marketplace support stacks get wrong. A generic help desk reads every ticket against one policy library and one escalation tree. Marketplace support needs two of each, plus a third surface for the disputes that touch both. The fractional model encodes the side detection at the agent layer. The moment the ticket lands, the agent identifies which side the requester is on (seller, buyer, or both in the case of a dispute), pulls the right account context (seller dashboard, payout history, KYC status for supply, or buyer order history, refund policy, escrow state for demand), and applies the right policy stack to the reply.

The escalation routing is the moat. A supply-side payout dispute escalates to the platform finance team with the payout ledger, the Stripe Connect transfer state, and the chargeback context attached. A demand-side refund request that the agent cannot resolve escalates to the trust and safety team with the buyer history, the seller policy, and the escrow state attached. A KYC document failure escalates to the compliance team with the document parse, the registered business data, and the verification provider response attached. A cross-side dispute escalates to the team responsible for that dispute class with both sides briefed and the policy lookup already done. Every escalation is a one-screen handoff with the context the human team needs to make a judgement call, not a transcript to read from scratch.

The economic argument for this is structural. A marketplace at twenty to fifty headcount cannot afford two full support teams, one per side, each staffed for twenty-four hour coverage in every market language. The fractional model gives both queues twenty-four hour coverage in twelve plus languages at a retainer line that is smaller than two part-time reps per side. The cost ceiling is machine time, not headcount. The support function scales with GMV without the support headcount scaling with GMV, which is the only configuration where two-sided marketplace unit economics actually work past Series B. The AI Support Department page covers the engine in more depth. The marketplace version doubles the queue surface and the policy complexity, and the engine scales to it without doubling the cost.

2am, Singapore: a Southeast Asia seller files a supply-side ticket asking why the latest payout did not include three transactions from last week. The agent identifies the side (supply), pulls the Stripe Connect transfer ledger for the vendor, sees that the three transactions are on a 72-hour escrow hold pending dispute resolution from the buyer side, cross-references the dispute ledger, sees the disputes are still open, and writes a reply in Bahasa explaining that the three transactions are held pending the dispute outcomes with the expected release timing for each. Reply lands in forty-three seconds. The seller understands the hold and stops emailing the team daily about the payout.

4am, Berlin: a buyer files a demand-side refund request on an item that arrived damaged. The agent identifies the side (demand), pulls the order, the seller policy, the EU distance-selling rules that apply to this transaction, the escrow state (released to seller four days ago), and the photo evidence the buyer uploaded. The reply in German offers a full refund per the seller damaged-on-arrival policy with the prepaid return label and confirms the refund timeline. The seller side gets a parallel notification that a damaged-item refund was issued under their published policy with the photo evidence attached. Both sides handled in under a minute.

11am, your timezone: the trust and safety lead opens the queue. Six escalations need her judgement. One is a cross-side dispute on a high-value transaction where the seller claims the buyer received the item and is filing a chargeback to extract a refund. The agent has briefed both sides: seller history (clean, five hundred transactions, zero disputes), buyer history (three disputes in the last two months, two resolved against the buyer), the carrier delivery confirmation with signature, and the relevant terms-of-service clause. She approves the dispute resolution against the buyer in twenty seconds with the carrier evidence attached. The seller gets the funds released the same day. The buyer gets the rejection with the evidence cited. The dispute closes inside thirty-six hours instead of two weeks.

11pm, your timezone: eighty-seven tickets came in since 6pm across both sides. Sixty-eight are closed end to end on the right side with the right policy. Twelve are queued for human review with one-screen briefs attached. Four are KYC compliance escalations from the supply side. Three are cross-side disputes with both sides briefed. The founder is asleep. The supply community is calm. The buyer community is calm. The trust signal on both sides is moving in the right direction.

Marketplaces are trust businesses. Network effects compound when both sides believe the platform protects them. Network effects unravel when one side starts telling the other that the platform does not have their back. The mechanism for that unraveling is the support queue, and the marketplaces that lose this most often are the ones that staffed the demand side and outsourced the supply side, or staffed the supply side and let the buyer queue go to a generic help desk. Sellers find a Slack community within a week of joining, and the first thing they share is which platforms answer payout questions in under an hour and which ones make them wait three days. Buyers find a subreddit, and the first thing they share is which platforms process refund disputes in twenty-four hours and which ones bury the request. The trust signal travels faster than the marketing.

On a marketplace doing twenty to a hundred million GMV, a one-point reduction in supply attrition and a one-point lift in buyer repeat-purchase rate compound across the network in a way that is structural to the take rate. Most marketplaces running a single-queue support configuration are leaking three to five points of supply attrition on payout latency they have not traced to support response time, and two to four points of buyer repeat-purchase rate on refund cycle times they did not measure. Closing both gaps pays for the AI Support Department several times over before counting the dispute resolution acceleration.

The dispute queue is the place where the math gets sharp. A marketplace that sits on cross-side disputes for two weeks is teaching both sides that the platform does not protect them, which is the network effect signal in reverse. A marketplace that resolves disputes inside seventy-two hours with both sides briefed in their own language is teaching both sides that the platform does protect them, which is the network effect signal compounding in the right direction. The structural argument for the full marketplace stack is in AI for Marketplaces. The reconciliation side runs through AI Ops for Marketplaces where the payout ledger and the dispute ledger close on a live pipeline. The pattern from the single-sided e-commerce version is in AI for E-commerce. The marketplace version doubles the surface and the engine scales.