Why does one chatbot fail on a marketplace?
I build the integrations and actions that let eesel's agents read from other systems, so most of my week goes into one question: what does the AI need to see, and what is it allowed to change? On a single-brand store the answer is simple. On a marketplace it splits in two, because the person writing in might be the buyer or the seller of the same order, and they are owed different answers.
Take a parcel marked delivered that the buyer says never arrived. The buyer wants a refund. The seller wants their payout. A bot trained on one help center will either quote the buyer policy to the seller or the seller policy to the buyer, and both are bad. eBay's own Money Back Guarantee shows how much structure sits behind that one case: the seller has 3 business days to respond, either side can ask eBay to step in between 3 and 21 business days, and orders of $750 or more need signature confirmation as proof of delivery.
I have seen this from the inside. In May 2026 a large food-delivery marketplace asked us for two separate knowledge bases inside one Zendesk help center, one for customers and one for restaurants. That request is the whole problem in a sentence. We have also spent years putting AI agents on live support queues and watching confident-sounding bots give wrong answers, which is why every eesel rollout is now simulated against historical tickets first. On a marketplace, a wrong answer can cost you on both sides of the same order.
Which marketplace tickets can AI handle, and which need a person?
I sort marketplace tickets by one test: is there a single right answer sitting in a system somewhere? If yes, AI can answer alone. If the answer depends on judging who is right, a person decides and AI does the prep. That is the core of good ticket routing on a two-sided platform.
| Ticket | Who asks | What AI does | Who decides |
|---|---|---|---|
| Where is my order? | Buyer | Looks up the order and tracking, replies with the status | Nobody, unless tracking has stalled |
| Refund status | Buyer | Reads the refund record and gives the date | Nobody |
| Payout status | Seller | Reads the payout record (pending, in transit, paid) | Nobody |
| Fee breakdown | Seller | Pulls the order's fees and commission and explains each line | Nobody |
| Verification hold | Seller | Lists what is missing and sends the update link | The payment provider's checks |
| Payout failed | Seller | Explains the failure and sends a bank details update link | A person if fraud is suspected |
| Simple refund within policy | Buyer | Drafts the refund and the note to both sides | A person approves the money |
| Item not as described | Buyer | Collects photos, listing snapshot and messages into one pack | A person picks the outcome |
| Card chargeback | Finance or seller | Builds the evidence pack against the deadline | A person submits once |
| Scam or fake listing report | Either | Acknowledges, preserves evidence, flags as priority | Trust and safety team |
| Account suspension appeal | Seller | Summarizes the case history | A person, always |
The top four rows are the volume. They are also where most marketplace bots fall short, because they answer from the help center instead of the order system. "Payouts usually arrive in 2 to 3 days" is not an answer to "where is my payout?" The real answer is a status and a date, and it lives in your payments provider. The bottom half of the table is where a human-in-the-loop step stays, permanently.
How do you split buyers, sellers and trust and safety into lanes?
Three lanes cover almost everything. The buyer lane handles orders, delivery and refunds. The seller lane handles payouts, fees, listings and verification. The trust and safety lane handles scams, fake listings and account takeovers, and it jumps the queue.
Each lane needs three things of its own: a knowledge set, a set of allowed actions, and a person or team who picks up what the AI hands off. The knowledge split matters most. Your buyer refund policy and your seller reimbursement policy will contradict each other on purpose, and an AI that reads both will blend them. This is the same problem as multi-brand customer support, just with two audiences instead of two stores.
Your helpdesk can probably do the split already, though the plan you are on matters:
| Helpdesk | Feature for two audiences | Plan, per the vendor | Watch for |
|---|---|---|---|
| Zendesk | Multibrand, each brand with its own help center and email | Suite Growth and up; 5 brands on Growth and Professional, 300 on Enterprise | End users can't be segmented by brand, so a person who buys and sells is one record |
| Zendesk | User segments to show articles to one audience | Suite Growth and up | 200 segments per account |
| Freshdesk | Multiple Products, each with its own portal and mailbox | Pro (5 products) and Enterprise (unlimited) | Agents see every product's tickets unless automation rules separate them |
| Gorgias | Multiple stores plus rules | All plans | A "store" is a Shopify, BigCommerce or Magento 2 connection, so a seller audience has to be split by channel and rules |
| HubSpot | Help desk channels, each with its own pipeline and team | Service Hub Professional and Enterprise | Each team email connects to one channel only |
On Zendesk, the cheapest way I have seen to model buyers and sellers is a seller brand plus user segments, with seller records stored as custom objects related to tickets. If agents should only see their own lane, that is a separate permission question, which my notes on support agent access control cover.
smava is the clearest example I can point to of keeping two audiences apart inside one helpdesk. smava and Finanzcheck share one Zendesk, and eesel works about 27,000 tickets a month across both, drafting from about 820 macros and help center articles that are kept apart by brand. A seller lane and a buyer lane work the same way: one helpdesk, two knowledge sets that never mix.
Which lane does this ticket go to?
Here is the lane logic as something you can click through. Pick a ticket and it shows the lane, what the AI is allowed to do, and who finishes the job.
Pick a ticket to see its lane, what the AI may do, and who finishes it. This is my starting point for a marketplace queue; your policy team sets the final rules.
How do you connect the AI to live order and payout data?
The lookups in the buyer and seller lanes only work if the AI can read your systems in real time. Answering "where is my payout?" from the help center gets you a generic schedule. Answering it from the payments API gets you "your $412 payout is in transit and should arrive Thursday." The second one closes the ticket, which is the whole point of order tracking support and WISMO automation.
Payouts are where the seller lane lives or dies, and Stripe's Connect docs explain why the tickets land on you. If a seller is not seeing expected funds, Stripe says they "need to contact the platform they work with," because the platform controls payout settings and schedules. So every payout question is your ticket, not Stripe's. The same page lists the payout statuses an AI should read out loud: pending, in transit, paid, failed and canceled.
Failed payouts are a good example of a ticket the AI can mostly handle. When a payout fails, Stripe errors that bank account and pauses scheduled payouts to it, and the platform can generate a link for the seller to update their own bank details. That is a lookup plus a link, which AI does well. The same page notes the platform can block a bank account across the whole platform for fraud, and that action belongs to a person.
Verification holds work the same way. Stripe's verification docs say it "typically disables payouts" if required information isn't received by the deadline, and each requirement comes with a plain-language error the seller can act on. Adyen runs a similar clock: per its verification overview, sellers get 30 days to fix problems before payouts stop and 60 days before they can no longer take payments. An AI that reads the outstanding requirements and tells the seller exactly what to upload saves a back-and-forth on every one of these.
Here is the plumbing, from the engineering side. You want four reads and almost no writes:
- Orders: status, items, tracking events, from your marketplace database or Shopify.
- Refunds: issued or not, amount, date.
- Payouts: status, arrival date, failure code, per seller account.
- Account requirements: what verification is outstanding and by when.
Webhooks keep it fresh. Stripe's Connect webhooks page says every Connect integration should listen for events, and the ones a support team cares about are account.updated, payout.failed and charge.dispute.created. I like to have the payout failure webhook open a seller-lane ticket before the seller even writes in. A proactive "your payout failed, here is the link to fix it" beats a confused email three days later.
For writes, the rule I follow is simple: anything that moves money or changes an account waits for a person. That covers refunds, payout releases, fee reversals and account blocks. If you want a template for who approves what, my refund approval matrix lays one out, and support exception management covers the edge cases.
How should AI handle buyer-seller disputes?
This is where the competing interests are sharpest, and where I would never let the AI pick a side. Both parties are your customers. What AI can do is make the person deciding much faster and much more consistent.
The consistency part matters more than people expect. Here is a host describing what dispute support felt like on a big rental marketplace:
"... The side you wins is the side you can say the magic words that specific agent wants to hear."
When the outcome depends on which agent you get, both sides lose trust. The fix is a standard evidence pack that looks the same every time, built before a person ever opens the case.
My evidence pack has five parts: the order record, carrier tracking, the full buyer-seller message thread, a snapshot of the listing as it was at purchase, and both parties' refund and dispute history. The AI collects them, flags gaps ("seller has not responded in 3 business days"), and drafts a note to each side once the person decides. That last part is easy to skip, and it shouldn't be. The losing side deserves a clear explanation, written in the language of their lane.
The timelines differ a lot by marketplace type, so encode yours instead of copying someone else's. A physical goods marketplace leans on tracking and delivery proof: eBay asks sellers to respond within 3 business days, and Etsy's case process lets buyers open a case once the delivery estimate has passed and 48 hours after messaging the seller. A services marketplace has no tracking number, so it leans on milestones and messages. Upwork gives freelancers 7 calendar days to file a fixed-price dispute, and Fiverr's Resolution Center auto-accepts a request that isn't answered within 48 hours. If you run a services platform, your evidence pack swaps tracking for delivered files and the agreed scope.
Who pays matters too, and it decides how the AI should word things. On Sharetribe, "only marketplace operators can cancel a transaction and initiate a refund" by default, and a disputed order cancels with a full refund after 60 days if nobody acts. A timer like that is exactly what the AI should surface in the evidence pack, so nothing expires quietly.
How are chargebacks different from buyer-seller disputes?
A chargeback can come from the very same order, but it is a different process with a different judge. In a buyer-seller dispute, you decide under your own policy. In a chargeback, the buyer's card issuer decides, and you are on the network's clock.
The Stripe rules are worth knowing in detail, because they are strict:
- The deadline is short. Stripe's dispute response guide says the window is usually 7 to 21 days depending on the card network, and missing it is an automatic loss.
- You get one shot. "You've only one opportunity to submit your response," per the same page. No edits, no links, no audio or video, and a 4.5 MB cap on combined evidence.
- Support history is evidence. Stripe tells merchants to keep a record of all communication with the customer, because it becomes part of the case. Your helpdesk is a dispute archive whether you planned it or not.
- It costs money either way. In the US, Stripe charges $15 when a dispute arrives and another $15 if you counter it, with the second fee returned if you win.
Who absorbs the loss depends on how your payments are set up. Stripe's Connect disputes page says that on destination charges and separate charges and transfers, "Stripe debits dispute amounts and fees from your platform account," and you can then reverse the transfer to recover it from the seller. On direct charges, the seller's balance is debited. Adyen's default is similar: the platform pays first and can pass the cost to the seller or split it per payment.
So the AI's job in a chargeback is narrow: spot the charge.dispute.created event, open a ticket with the due date in the subject line, and assemble the evidence from the order, the delivery proof and the support thread. A person in finance reviews and submits. If you want the support-side detail, my guides to AI for payment disputes and chargeback inquiries go deeper.
What controls does the trust and safety lane need?
Scam and fake-listing reports are the tickets where speed and restraint both matter. The reporter needs to feel heard right away, and the AI must not tip off or punish anyone on its own. Getting it wrong in the other direction is just as bad, as this Facebook Marketplace user found:
"Last year, I reported a number of people, who were trying to scam me (via Messenger messages related to Marketplace listings). Not only did Facebook did not see anything wrong with the accounts and scammy messages, I was flagged for sending useless reports."
Here are the five controls I set up for this lane:
- Priority routing. Reports skip the normal queue and land with the trust and safety team. Skills-based routing in your helpdesk handles this; the AI's job is tagging the ticket correctly the first time.
- Evidence preservation. The AI saves the listing, the messages and the account details at the moment of the report, because scammers edit or delete fast.
- Restricted actions. The AI can acknowledge and tag. It can't block, suspend, refund or message the reported account. Those are AI guardrails you set once and never loosen.
- Impersonation awareness. Sellers get scam messages pretending to be your support team. One former Etsy seller described "20+ daily messages from scammers pretending to be buyers or Etsy support." Your AI should never ask for passwords or payment details, and it should say so in its replies.
- Appeals and an audit trail. Every action on an account gets logged with who approved it. When a seller appeals a suspension, the person reviewing it can see the full history in one place.
Account takeovers deserve their own rule. If a seller writes "someone changed my bank details," treat it as urgent and route it to a person immediately. Stripe's payout tooling lets a platform block a bank account platform-wide or reject an account for takeover, but those are decisions for your team, not the AI. For the broader pattern of clean handoffs, see my notes on AI escalation management.
How would I roll this out?
I would start with the lookups, not the disputes, and I would test before anything goes live. A sequence I have seen work:
- Week 0: map and connect. Pull 300 recent tickets and sort them into the three lanes. Connect read access to orders, refunds, payouts and account requirements. Write the restricted-actions list.
- Weeks 1 to 2: simulate. Run the AI against historical tickets for each lane and compare its answers to what your team actually sent. My pre-launch testing guide and pilot scorecard cover how to score it.
- Weeks 3 to 4: lookups live. Order status, refund status, payout status and fee questions go out without a person. Everything else is draft-only.
- Weeks 5 to 8: evidence packs. The AI starts assembling dispute and chargeback packs. People still decide every one.
- Ongoing: trust and safety tagging. Turn on priority tagging for reports, with zero account actions for the AI, ever.
The simulation step is where marketplaces find their surprises. A typical one: the AI gives a seller the buyer return policy because a seller asked "how do returns work?" That is a knowledge-split problem, and you want to find it in a replay of past tickets, not in a live seller's inbox. My AI support pilot guide has the four-week version of this plan.
What should you measure on a two-sided platform?
Deflection rate is the wrong headline number for a marketplace. A buyer who gets a bot reply and gives up counts as deflected, and so does a seller who goes quiet and lists elsewhere. I measure every metric twice, once per side.
| Metric | Buyer side | Seller side | Why it matters |
|---|---|---|---|
| Verified resolution rate | Order and refund questions closed with no reopen | Payout and fee questions closed with no reopen | Shows real answers, not bot replies |
| Repeat contact within 7 days | Same buyer, same order | Same seller, same payout | Catches answers that sounded right but were not |
| CSAT | Buyer survey after close | Seller survey after close | One side can be happy while the other quietly leaves |
| Escalation accuracy | Disputes routed with a full evidence pack | Verification and takeover cases routed to the right team | Tells you if the lanes work |
| Money error rate | Wrong refund amounts or dates quoted | Wrong payout amounts or dates quoted | The fastest way to lose trust on either side |
| Dispute decision time | Case opened to outcome | Case opened to outcome | Evidence packs should shrink this |
Splitting CSAT by side is the one I push hardest. Sellers are often a smaller group with much higher lifetime value, and a seller lane that quietly degrades will not show up in a blended score. For definitions, my breakdowns of CX AI metrics and repeat tickets go through each one.
Sellers will tell you when the seller lane is broken, usually in public. Here is one small business owner on a payout hold:
"We are affected by this as Etsy is currently holding about 4000 of our Euros... The worst thing about it is that we raised a support request for this, for which you have to jump through really stupid hoops, and have not even heard back from them in weeks. Not even a boilerplate response."
A payout hold may be the right call for risk reasons. Weeks of silence is never the right call. An AI that reads the hold reason and replies the same day, even with "your funds are held for a verification check, here is what we need," turns that post into a ticket that never gets written.
How does eesel fit a marketplace support team?
eesel is an AI teammate that joins the helpdesk you already run, including Zendesk, Freshdesk and Gorgias, as well as HubSpot. It learns from your help center and past tickets, and you can run a separate agent per lane, each with its own knowledge and instructions.
The live-data part is the piece I work on most. eesel's Network Access setting lets an agent call your own APIs, so it can look up live orders, refunds or payouts. You allow a domain and set the auth header, and the credentials are attached to each request by eesel, so the AI never sees them. Shopify order data connects through the Shopify integration. Action permissions let you set each action to run on its own, ask for approval, or stay off, which is how refunds and account changes stay behind a person.
If your engineers prefer working from a terminal, the eesel CLI runs the same teammate and workspace from the command line. You can review pending approvals, read the activity log of every run, and edit the agent's standing instructions, and coding agents like Claude Code can drive it too. For a marketplace that already runs its order and payout systems as code, that keeps the support agent's rules next to everything else.
Two customer stories show the lanes in practice. SamCart, a platform more than 75,000 businesses sell through, runs eesel on its seller support: one agent replies to Freshdesk tickets and another runs the website chat, both answering from about 280 help center articles. The agent replies only while no teammate is assigned, and when a seller asks for a person, the ticket is tagged for handoff and the agent stops. Rúngne shows the buyer side: eesel handled about 2,100 Gorgias tickets in a month, answering where-is-my-order and stock questions from Shopify data, while cancellations, damaged items, lost parcels and customs disputes go to people.
The honest limits: eesel does not decide disputes or submit chargeback responses for you, and I would not want it to. Its SOC 2 Type II audit is in progress, with the observation period starting 1 October 2026. Pricing is on the pricing page: a free plan with 100 credits, and Teammate plans from $299 a month for 500 credits, where a ticket or a chat is one credit. If you are weighing a separate AI layer against your helpdesk's built-in AI, I compared the two in my AI layer comparison.
Try eesel for your marketplace queue
If your buyers and sellers are getting the same canned answers, eesel can give each side its own lane inside the helpdesk you already use: live order and payout lookups for the easy tickets, evidence packs for disputes, and every money decision left with your team. Every rollout starts with a simulation on your historical tickets, so you see how it answers buyers and sellers before anyone else does.
Try eesel free with 100 credits, or book a demo and bring a sample of buyer and seller tickets so we can map your lanes together.