Catalog the exceptions before you automate the marketplace.
Operators know a marketplace by the cases that don't fit. A listing missing an attribute, a payment captured for an order that can't ship, a dispute after the deadline. Automate only the clean sale and that pile just grows faster.

Marketplaces fail in recurring exception shapes: payment, listing, fulfillment, and dispute. Catalog those shapes with owner, evidence, and recovery before wiring the happy path. Design the exception into the product; do not leave it in someone's inbox.
The happy path is not the product
Buyers experience a marketplace as availability, price, payment, and delivery. Operators experience it as the cases that do not fit: a listing missing a required attribute, a payment captured while fulfillment cannot proceed, a dispute that arrives after a shipper's deadline.
If you automate only the clean booking or sale, you accelerate ordinary volume and quietly enlarge the pile that still needs human coordination. Name the exception library first—then decide what may be automated. A marketplace is a set of promises; exceptions are where those promises are tested. Write the operating facts down where the next person can find them. Spoken agreements about authority, waiting, and recovery evaporate under load. Field Notes like this one exist to make those facts reusable without pretending they are universal statistics.
The TWIMCO exception catalog (anonymized)
Use these categories as shelves. Each entry needs: trigger signal, owner role, evidence packet, buyer/seller communication rule, recovery to a known state, and an automate-now / design-first / never-auto label.
Payment
- Captured payment, unfulfillable item → finance + ops owners; evidence includes payment id, listing snapshot, constraint; recovery may be cancel+refund or delay with explicit consent.
- Partial capture / mismatched currency or tax → do not "fix quietly"; design reconciliation states.
- Chargeback opened after ship → preserve timeline of listing claims vs shipment events.
Listing
- Required attribute missing only at checkout → treat as listing defect, not checkout bug alone.
- Availability diverges from supplier truth → define which system is authoritative and how long a stale offer may live.
- Policy-violating media or claims → human review path with freeze states.
Fulfillment
- Carrier exception after sale → buyer messaging must share the same event history ops sees.
- Split shipment / partial cancel → explicit states; avoid a single "processing" label.
- Address correction mid-route → attributed override, not an invisible edit.
Dispute
- "Item not as described" → evidence from listing snapshot at purchase time, not today's edited listing.
- Two-sided blame with incomplete logs → stop automated goodwill gestures until the packet is complete.
- Repeated dispute pattern on one seller → ops playbook beyond single-ticket refunds.
These entries are patterns shaped by marketplace delivery, not confidential Paddle8 or Spin:Market incident detail. Do not read them as telemetry from a named client.
Exception libraries age. Schedule a monthly prune: merge duplicates, split overloaded shelves, and delete rows that never appear in the wild. A catalog that only grows will train people to ignore it. The useful library is the one operators recognize in their Tuesday cases.
When AI enters marketplace operations, point models at catalogued exceptions with clear packets—not at the entire inbox. An agent that "handles disputes" without a shelf, owner, and evidence standard will invent goodwill the balance sheet cannot afford. Design the shelf first; then decide what may draft, what may file, and what must wait for a person.
How the work moves
Shelve an exception before you code it
- Trigger
What signal opens the case.
- Packet
Evidence the owner needs.
- Owner
Role that can resolve or escalate.
- Recovery
Return to a known state.
- Label
Automate-now, design-first, or never-auto.
A marketplace is a set of promises—exceptions are where those promises are tested.
Design-before-automate notes
For each catalog row, force a label:
- Automate-now — Rules are crisp; failure is detectable; recovery is safe to retry or clearly halted.
- Design-first — Owner or evidence still tribal; automation would hide the pile.
- Never-auto — Judgment, legal posture, or irreversible customer impact requires a person.
Most marketplace harm comes from treating Design-first rows as Automate-now because a demo looked clean. The storefront can smile while ops rebuilds the truth in a side channel. If the exception has nowhere to land, you did not finish the product—you finished the screenshot.
Decision guide
Automate-now vs design-first
| Consideration | Automate-now | Design-first |
|---|---|---|
| Rules | Crisp and shared. | Still argued between teams. |
| Evidence | Travels with the case. | Rebuilt from chat. |
| Failure | Visible halt or safe retry. | Silent skip to "done." |
| Customer promise | States match ops truth. | Storefront invents reassurance. |
What public case studies teach—without over-claiming
TWIMCO built Paddle8's fine-art auction and marketplace platform, connecting real-time bidding with shipping knowledge after a sale—including turning route spreadsheets into a shipping API. That public story is about carrying the transaction into the operation. It does not publish private exception rates, and this library does not invent them.
Spin:Market shows another marketplace-shaped surface: commercial entertainment operations spanning software, hardware, and agent control. Use it when exceptions involve devices and schedules—not as a source of fabricated dispute statistics.
The shared lesson is modest and durable: design for what happens after the click, and keep exceptions inspectable.
How to run the library for one week
- Pull twenty recent awkward cases.
- Shelve them into payment / listing / fulfillment / dispute.
- Fill owner, evidence, recovery, and automate label.
- Pick one Design-first row and make it visible in product (queue, state, packet)—before adding model calls.
- Only then automate a row that already has a home for failure.
Keep the twenty cases. They become regression stories later when someone proposes a shortcut that would erase a recovered edge.
Put this into practice
If you are building or repairing a marketplace, bring the catalog—not only the storefront screens—to Marketplaces. Start from the promise after checkout as well as the moment of purchase. Exceptions are where trust is won or quietly spent. A partner who only demos the happy path is volunteering you for the inbox work that remains.
Exception libraries age. Schedule a monthly prune: merge duplicates, split overloaded shelves, and delete rows that never appear in the wild. A catalog that only grows will train people to ignore it. The useful library is the one operators recognize in their Tuesday cases.
Marketplace operators sometimes treat exceptions as a support problem rather than a product surface. Support can close tickets; product has to decide which states exist, which packets travel with a case, and which promises the storefront is allowed to make while an exception is open. If those decisions stay informal, every new channel—chatbot, agent, partner API—inherits the same ambiguity at higher speed.
When you add AI to marketplace operations, point it at catalogued exceptions with clear packets—not at an undifferentiated inbox. An agent that "handles disputes" without a shelf, owner, and evidence standard will invent goodwill the balance sheet cannot afford. Design the shelf first; then decide what may draft, what may file, and what must wait for a person. The unreproducible value of this Field Note is the catalog shape itself: shelves, labels, and design-before-automate notes you can fill with your own cases without copying anyone else's confidential incidents.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.