Appearance
Dispute Resolution and Support
Designing fair, efficient systems that resolve conflicts between marketplace participants while preserving trust on both sides of the transaction.
Why This Matters
- 🏢 Owner: Every unresolved dispute is a churned user — often two churned users. Your dispute resolution system directly impacts retention, lifetime value, and word-of-mouth reputation. Get it wrong and you lose both sides of the marketplace.
- 💻 Dev: You will build the ticketing systems, automated triage logic, refund workflows, and communication tools that power dispute resolution. The technical challenge is routing the right case to the right agent with the right context at the right time.
- 📋 PM: You define the policies that determine outcomes — who gets a refund, when credits are issued, what constitutes a valid dispute. These policies must be fair, consistent, and operationally feasible at scale.
- 🎨 Designer: Dispute resolution is a high-emotion moment. Users are frustrated, confused, or angry. The interfaces you design must guide them through a structured process that feels fair, transparent, and responsive even when the outcome is not what they hoped for.
The Concept (Simple)
Imagine a farmers' market where a customer buys a basket of strawberries and finds half of them are moldy when they get home. They return to the market. What happens next depends entirely on the market's dispute system:
- No system: The customer confronts the vendor. Voices are raised. Other shoppers watch uncomfortably. The customer never returns.
- Basic system: The customer goes to the market office. A manager listens, checks the receipt, and issues a refund. The vendor is notified.
- Good system: The customer goes to the market office. The manager reviews the complaint, contacts the vendor for their side, reviews the vendor's history, makes a fair ruling, issues a refund, and flags the vendor for a quality check. Both parties are informed of the reasoning.
A marketplace dispute resolution system is the digital equivalent of that market office. It must be easy to find, fair in its process, and clear in its outcomes. Most importantly, it must serve both sides — the customer who got moldy strawberries and the vendor who ships hundreds of good baskets every week.
The hardest part is not refunding money. The hardest part is making both parties feel heard and keeping both of them on the platform.
How It Works (Detailed)
Two-Sided Support Architecture
Traditional customer support is one-sided: the business supports its customer. Marketplace support is fundamentally different because every dispute has two customers — the buyer and the seller — and the platform sits in the middle.
┌──────────────────────────────────────────────────────────────┐
│ TWO-SIDED SUPPORT ARCHITECTURE │
├──────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ BUYER │ │ SELLER │ │
│ │ │ │ │ │
│ │ Wants: │ │ Wants: │ │
│ │ - Refund │ │ - Payment│ │
│ │ - Fix │ │ - Fair │ │
│ │ - Answer │ │ review │ │
│ └─────┬────┘ └────┬─────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────────────────────────────────────┐ │
│ │ MARKETPLACE PLATFORM │ │
│ │ │ │
│ │ ┌────────────┐ ┌───────────┐ ┌─────────┐ │ │
│ │ │ Self-Serve │ │ Agents │ │ Escal. │ │ │
│ │ │ Tools │ │ (Tier 1) │ │ (Tier 2)│ │ │
│ │ └────────────┘ └───────────┘ └─────────┘ │ │
│ │ │ │
│ │ ┌──────────────────────────────────────┐ │ │
│ │ │ Policy Engine + Decision Framework │ │ │
│ │ └──────────────────────────────────────┘ │ │
│ └──────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘Key differences from one-sided support:
| Dimension | Traditional Support | Marketplace Support |
|---|---|---|
| Customer | One party | Two parties with opposing needs |
| Resolution | Satisfy the customer | Find a fair outcome for both |
| Information | Company has full context | Platform has partial context |
| Liability | Company is responsible | Liability varies by situation |
| Agent skill | Product knowledge | Mediation and judgment |
| Success metric | Customer satisfaction | Both-party retention |
The Dispute Resolution Workflow
A well-designed dispute workflow moves cases through structured phases, with automation handling routine cases and humans handling complex ones.
┌──────────────────────────────────────────────────────────────────┐
│ DISPUTE RESOLUTION WORKFLOW: REPORT TO RESOLUTION │
├──────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ │
│ │ 1. REPORT │ User files a dispute via app/web │
│ │ - Select issue │ Structured form captures: │
│ │ - Add evidence │ - Issue category │
│ │ - State outcome │ - Photos/screenshots │
│ └────────┬────────┘ - Desired resolution │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 2. AUTO-TRIAGE │ System evaluates: │
│ │ - Categorize │ - Dispute category and severity │
│ │ - Score urgency │ - User history (both parties) │
│ │ - Route │ - Transaction value │
│ └────────┬────────┘ - Fraud risk signals │
│ │ │
│ ┌─────┴──────┐ │
│ ▼ ▼ │
│ ┌────────┐ ┌────────────┐ │
│ │ AUTO- │ │ AGENT │ │
│ │ RESOLVE│ │ QUEUE │ │
│ │ │ │ │ │
│ │Instant │ │┌──────────┐│ │
│ │refund, │ ││ 3. REVIEW││ Agent reviews evidence, │
│ │credit, │ ││ - Context││ contacts both parties, │
│ │or FAQ │ ││ - History││ gathers additional info │
│ └───┬────┘ │└────┬─────┘│ │
│ │ │ │ │ │
│ │ │ ▼ │ │
│ │ │┌──────────┐│ │
│ │ ││4. MEDIATE││ Agent facilitates │
│ │ ││ - Propose││ communication, │
│ │ ││ - Negotiate│ proposes solutions │
│ │ │└────┬─────┘│ │
│ │ │ │ │ │
│ │ │ ▼ │ │
│ │ │┌──────────┐│ │
│ │ ││5. DECIDE ││ Apply policy, │
│ │ ││ - Rule ││ document reasoning, │
│ │ ││ - Enforce││ execute resolution │
│ │ │└────┬─────┘│ │
│ │ └─────┼──────┘ │
│ │ │ │
│ └──────┬──────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 6. RESOLVE │ Outcome communicated to both parties │
│ │ - Notify both │ Refund/credit/adjustment processed │
│ │ - Process funds │ Case documented for future reference │
│ │ - Log outcome │ Appeal option provided if applicable │
│ └────────┬────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 7. FOLLOW UP │ Satisfaction survey (both parties) │
│ │ - Survey │ Pattern analysis for prevention │
│ │ - Analyze │ Policy refinement │
│ │ - Improve │ │
│ └─────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────────┘Automated Triage and Routing
Not every dispute needs a human. Effective triage separates routine cases from complex ones.
┌──────────────────────────────────────────────────────────┐
│ TRIAGE DECISION MATRIX │
├──────────────┬───────────────┬───────────────────────────┤
│ Category │ Auto-Resolve │ Route to Agent │
├──────────────┼───────────────┼───────────────────────────┤
│ Item not │ Under $25: │ Over $25 or │
│ received │ auto-refund │ repeat claim │
├──────────────┼───────────────┼───────────────────────────┤
│ Not as │ Clear photo │ Ambiguous evidence, │
│ described │ evidence: │ high value, or │
│ │ instant credit│ seller disputes │
├──────────────┼───────────────┼───────────────────────────┤
│ Cancellation │ Within cancel │ Outside window or │
│ │ window: auto │ partial completion │
├──────────────┼───────────────┼───────────────────────────┤
│ Safety │ Never │ Always — immediate │
│ concern │ auto-resolve │ priority routing │
├──────────────┼───────────────┼───────────────────────────┤
│ Payment │ System error: │ Disputed charges, │
│ issue │ auto-correct │ chargeback claims │
└──────────────┴───────────────┴───────────────────────────┘Airbnb auto-resolves approximately 60% of support contacts through self-service tools and automated workflows. The remaining 40% are routed to specialized support teams based on issue category and severity.
Refund Policies
Refund policy design is one of the most consequential decisions in marketplace operations. The core question: who pays when something goes wrong?
| Model | How It Works | Example |
|---|---|---|
| Buyer-funded | Refund from buyer's payment only | Most peer-to-peer |
| Seller-funded | Seller absorbs the cost | Return shipping costs |
| Platform-funded | Marketplace absorbs the loss | Goodwill credits |
| Insurance-funded | Third-party insurance covers the claim | Airbnb AirCover |
| Shared | Split between parties or platform | Partial refunds |
Refund Decision Framework
┌──────────────────────────────────────────────────────────┐
│ REFUND DECISION FRAMEWORK │
├──────────────────────────────────────────────────────────┤
│ │
│ Who is at fault? │
│ │ │
│ ┌────┴──────────────────┬─────────────────┐ │
│ ▼ ▼ ▼ │
│ SELLER UNCLEAR BUYER │
│ - Full refund - Partial refund - No refund │
│ - Seller pays - Platform may - Buyer │
│ - Seller penalty │ absorb cost │ absorbs │
│ - Listing removed │ │ loss │
│ │ │ │
│ Is buyer a │ │ Is buyer │
│ repeat claimant? ───────┘ │ acting in │
│ │ │ bad faith? │
│ ┌────┴────┐ │ │
│ ▼ ▼ ┌────┴────┐ │
│ YES NO ▼ ▼ │
│ Flag for Standard YES NO │
│ review process Flag Standard │
│ account decline │
│ │
└──────────────────────────────────────────────────────────┘Credits vs. Cash Refunds
| Factor | Cash Refund | Platform Credit |
|---|---|---|
| User preference | Strongly preferred | Acceptable for small |
| Cost to platform | Higher (processing) | Lower (retains spend) |
| Retention impact | Neutral to negative | Positive (forces reuse) |
| Legal requirements | Often required by law | May not satisfy regs |
| Best for | Clear fault, high value | Goodwill, minor issues |
eBay's Money Back Guarantee defaults to cash refunds for items not received or not as described. The seller is responsible for return shipping in most cases. eBay advances the refund to the buyer and collects from the seller, reducing buyer risk.
SLAs for Response and Resolution
Service level agreements set expectations and drive operational discipline.
┌──────────────────────────────────────────────────────────┐
│ SLA FRAMEWORK │
├────────────┬──────────────────┬───────────────────────────┤
│ Priority │ Response Time │ Resolution Time │
├────────────┼──────────────────┼───────────────────────────┤
│ P0 │ < 15 minutes │ < 4 hours │
│ Safety │ │ 24/7 coverage │
│ Emergency │ │ │
├────────────┼──────────────────┼───────────────────────────┤
│ P1 │ < 1 hour │ < 24 hours │
│ Active │ │ Business hours + weekend │
│ Fraud │ │ │
├────────────┼──────────────────┼───────────────────────────┤
│ P2 │ < 4 hours │ < 48 hours │
│ Standard │ │ Business hours │
│ Dispute │ │ │
├────────────┼──────────────────┼───────────────────────────┤
│ P3 │ < 24 hours │ < 5 business days │
│ General │ │ Business hours │
│ Inquiry │ │ │
└────────────┴──────────────────┴───────────────────────────┘Escalation Paths
Not every dispute can be resolved at the first level. A clear escalation path prevents cases from falling through cracks.
┌──────────────────────────────────────────────────────────┐
│ ESCALATION PATH │
├──────────────────────────────────────────────────────────┤
│ │
│ TIER 0: Self-Service │
│ ┌──────────────────────────────────┐ │
│ │ Help center, FAQ, chatbot, │ │
│ │ automated refund for eligible │ Resolves ~50% │
│ │ cases │ │
│ └──────────────┬───────────────────┘ │
│ │ Unresolved │
│ ▼ │
│ TIER 1: Frontline Support │
│ ┌──────────────────────────────────┐ │
│ │ Trained agents with standard │ │
│ │ resolution authority (refund up │ Resolves ~35% │
│ │ to $X, credits, warnings) │ │
│ └──────────────┬───────────────────┘ │
│ │ Complex / High-value │
│ ▼ │
│ TIER 2: Specialist Team │
│ ┌──────────────────────────────────┐ │
│ │ Senior agents, domain experts, │ │
│ │ higher authority (account │ Resolves ~12% │
│ │ actions, large refunds) │ │
│ └──────────────┬───────────────────┘ │
│ │ Policy exception / Legal │
│ ▼ │
│ TIER 3: Management / Legal │
│ ┌──────────────────────────────────┐ │
│ │ Trust & safety leads, legal │ │
│ │ team, executive escalation │ Resolves ~3% │
│ │ for extreme cases │ │
│ └──────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘Key Metrics for Dispute Resolution
| Metric | Target | Why It Matters |
|---|---|---|
| First response time | < SLA target | Sets user expectations |
| Resolution time | < SLA target | Limits user frustration |
| First-contact resolution rate | > 70% | Efficiency and user satisfaction |
| Dispute rate (% of transactions) | < 2% | Overall marketplace health |
| CSAT (post-resolution) | > 4.0/5.0 | Quality of resolution experience |
| Both-party retention (30-day) | > 80% | Did both users stay after the dispute? |
| Escalation rate | < 15% | Frontline effectiveness |
| Cost per resolution | Declining trend | Operational efficiency |
In Practice
Real-World Examples
Airbnb Resolution Center
Airbnb's Resolution Center is a dedicated interface where hosts and guests can resolve issues directly or request platform intervention.
How it works:
- Either party opens a resolution request in the app
- They describe the issue, attach photos, and specify a requested amount
- The other party has 72 hours to respond — they can accept, decline, or counter
- If the parties cannot agree, either can involve Airbnb as mediator
- An Airbnb agent reviews evidence from both sides and makes a binding decision
- Funds are transferred or refunded based on the ruling
Key design decisions:
- Encourages peer-to-peer resolution first (reduces support volume by ~40%)
- Structured request format prevents emotional back-and-forth
- Time limits prevent cases from lingering indefinitely
- Platform intervention is a backstop, not the first option
eBay Money Back Guarantee
eBay's guarantee program is one of the most mature dispute resolution systems in marketplace history.
The process:
- Buyer reports an issue (item not received, not as described, or defective)
- eBay encourages buyer to contact seller first via messaging
- If unresolved after 3 business days, buyer can escalate to eBay
- eBay reviews the case, including tracking data, listing details, and message history
- Decision is made — typically within 48 hours
- If buyer wins, full refund is issued. eBay collects from seller if needed
What makes it work:
- Clear eligibility criteria published in advance
- Seller performance metrics create accountability (defect rate impacts search ranking)
- eBay advances refunds to buyers, removing payment risk
- Appeal process available for sellers who disagree with the ruling
Uber In-App Support
Uber handles millions of support interactions per week with a primarily automated system.
The flow:
- After a trip, rider can report an issue through trip history
- Predefined issue categories guide the report (wrong route, car condition, driver behavior)
- Most issues are auto-resolved: fare adjustment for wrong route, credit for car condition
- Complex issues (safety, discrimination, accidents) route to specialized teams
- Driver-side disputes (rider behavior, cleaning fees) follow a parallel process
Uber's innovation: using trip data (GPS, timestamps, fare calculation) to auto-adjudicate many disputes without needing a human. If GPS shows the driver took a longer route, a fare adjustment is issued automatically.
Anti-Patterns
Buyer-always-wins policies: Refunding buyers without investigation trains fraudulent buyers to exploit the system and drives honest sellers off the platform. Amazon faced this criticism with its A-to-Z Guarantee, eventually adding more seller protections.
Black-box decisions: Issuing a ruling without explaining the reasoning. Both parties need to understand why a decision was made, even if they disagree with it.
Support ping-pong: Routing users between departments or asking them to repeat their story. Every handoff increases frustration and cost.
Hiding the dispute button: Making it hard to file a dispute reduces reported disputes but increases chargebacks, negative reviews, and churn. Accessible dispute filing is better than suppressed dispute filing.
Ignoring seller disputes: Building robust buyer protection but giving sellers no recourse for buyer fraud, false claims, or policy abuse.
Common Mistakes
- Setting SLAs without staffing to meet them consistently
- Not tracking both-party retention as a success metric (only tracking the claimant)
- Failing to distinguish between first-time disputes and serial disputants
- Using CSAT alone without measuring actual resolution fairness
- Not providing agents with enough authority to resolve cases at first contact
- Designing dispute flows for desktop only when most users are on mobile
- Forgetting to close the feedback loop — users who file disputes should see platform improvements
Key Takeaways
- Marketplace support is fundamentally two-sided. Every dispute has two customers, and the goal is to retain both of them.
- Automate routine cases aggressively. Low-value, clear-cut disputes should resolve instantly without human intervention.
- Design for peer-to-peer resolution first. Let parties try to work it out before the platform intervenes — this reduces support volume and often produces better outcomes.
- Refund policy design determines who bears the cost of marketplace friction. Be intentional about when the buyer, seller, or platform absorbs losses.
- SLAs must be set, tracked, and staffed. An SLA you cannot meet is worse than no SLA at all.
- Escalation paths should be clear and documented. Every agent should know exactly when and how to escalate.
- Track both-party retention after disputes. If winners stay but losers churn, your dispute system is destroying your marketplace.
- Invest in agent tooling. An agent who can see the full transaction context, both parties' history, and relevant policy in one screen resolves cases faster and better.
Action Items
🏢 Owner:
- ☐ Define and publish dispute resolution policies for all major dispute categories
- ☐ Set SLAs for response time and resolution time by priority level
- ☐ Establish a dispute cost budget and track cost-per-resolution monthly
- ☐ Review both-party retention metrics after disputes quarterly
💻 Dev:
- ☐ Build a dispute intake flow with structured issue categories and evidence upload
- ☐ Implement automated triage logic that routes cases by category, value, and risk
- ☐ Create an agent dashboard showing full transaction context, user history, and policy guidelines
- ☐ Build auto-resolution workflows for common, clear-cut dispute types
📋 PM:
- ☐ Document resolution policies for each dispute category with decision trees
- ☐ Design the peer-to-peer resolution flow (direct negotiation before platform involvement)
- ☐ Define escalation criteria and authority levels for each support tier
- ☐ Establish a feedback loop from dispute trends to product and policy improvements
🎨 Designer:
- ☐ Design a mobile-first dispute filing flow that captures structured information without overwhelming the user
- ☐ Create a resolution center where both parties can track case status and communicate
- ☐ Design outcome communication templates that explain the decision and reasoning
- ☐ Build satisfaction survey touchpoints for both parties after resolution