Support when both people emailing you are your customers
Marketplace support has a structural problem no other support inbox has: both people in the argument are your customers, both have read the same policy differently, and anything you say to one can be forwarded to the other. Automating it requires being clear about which parts are facts and which are judgements.
4 min read
Facts, then judgements
Almost every marketplace inquiry decomposes into these two, and the split is where the automation boundary sits.
Facts come from your systems and are safe: when the order was placed, what was paid, when it shipped, what the tracking says, what the policy states, when the dispute window closes. Both sides can be told the same facts without anyone deciding anything.
Judgements are who is right, whether a refund applies to this case, whether the item matched its description, and whether someone is acting in bad faith. Those are decisions with money attached, and the agent's job is to gather cleanly and hand over, never to rule.
The failure mode to avoid is an agent that restates the policy in a way that reads as a decision. "Our policy allows returns within 14 days" is a fact. "So you should be covered" is a ruling, and the seller reading the forwarded screenshot will treat it as one.
Each side gets its own thread
A buyer and a seller in the same conversation is a design decision, and mostly the wrong one. Separate threads mean each side can be told the same facts without the other's words being quoted at them, and it removes the accidental disclosure that comes from adding a recipient to a live thread, per when an agent and a person are on the same thread.
It also protects information asymmetries you actually want: a seller's cost, a buyer's address history, and anything about a previous dispute belong on their side only.
Where you want both parties talking, do it deliberately in a channel built for it, not by merging inboxes.
| Message | Handled |
|---|---|
| Where is my order, what does tracking say | Agent, from live carrier data |
| What is the policy on returns | Agent, quoting policy without applying it |
| How do I contact the other party | Agent, per your rules |
| My item arrived damaged | Gather evidence, then a person |
| The buyer is lying | Person, always |
| Payout timing and fees | Agent for facts, person for exceptions |
| Suspected fraud on either side | Person, immediately, and quietly |
Evidence gathering is the real win
Disputes are resolved by whoever has the photographs, the tracking record, and the message history. Gathering that costs an agent nothing and takes a support person twenty minutes per case.
An agent that responds to a damage claim by asking for photographs, the order number, and the packaging condition, then attaches everything to the case before a human opens it, turns a twenty minute investigation into a two minute decision. The attachment handling behind that is in attachments.
That is the shape of the return here: the agent does not decide, it prepares.
Fraud has its own handling
Two rules, both structural.
Never confirm or deny a suspicion in writing. An agent telling one party that the other is under review is a disclosure with legal and safety consequences. Suspected fraud escalates silently, and the reply to the sender stays neutral.
Never act on a request to change payout details. It is the oldest attack in marketplaces, and the answer is always escalation with out-of-band verification, per the same rule in chasing quotes and vendors.
Volume, and the seasonal spike
Marketplace support is bursty in the same shape as retail: a promotion, a delivery failure at a carrier, a policy change, and volume triples for two days. The concurrency mechanics matter here more than most, because a duplicate reply in a dispute is not just untidy, it can contradict the previous one, per what happens when forty messages arrive at once.
Set a per-thread lock, deduplicate on the message id, and make sure the agent reads the current case state rather than the state it saw an hour ago.
Two agents, one platform
Buyer support and seller support have different tones, different data access, and different escalation paths. Two identities keeps them separate and lets you turn one off without touching the other, per running several email agents in one workspace.
It also gives you a cleaner audit answer when someone asks what was said to whom, which in a dispute is exactly the question that gets asked.
Questions
- Can an AI agent handle marketplace support?
- For facts: order state, tracking, policy text, payout timing, and evidence gathering. Not for judgements about who is right, which side gets a refund, or whether someone acted in bad faith.
- Should buyer and seller be in the same thread?
- No. Separate threads per side, so the same facts can be given to both without either party's words being quoted at the other, and without accidental disclosure.
- What is the biggest time saving?
- Evidence gathering. Photographs, order details, and message history collected before a human opens the case turns a twenty minute investigation into a two minute decision.
- How should it handle a suspected fraud report?
- Escalate silently, reply neutrally, and never confirm or deny a suspicion in writing. Requests to change payout details are always escalated with out-of-band verification.
- Can it quote the policy?
- Yes, as text. What it must not do is apply the policy to the case, since a sentence that reads as a ruling will be treated as one by the other party.
- Should buyer and seller support be one agent?
- Two, with different data access and escalation paths. It also makes "what was said to whom" answerable, which is the question every dispute eventually raises.
Give your agent an address it can answer from.
Create an inbox