The seller onboarding queue: tiles for open applications and approvals, a table of applicants with pass, pending and fail marks for ID, company register, bank account and sample listings, and a side panel for one ceramics seller with a model note and Approve, Request info and Reject buttons.
Seller onboarding. Every check in one row, a person approves.

Why this sample

A marketplace lives on its back office. Every new seller needs checks, every listing needs rules, and every order splits money between the seller and the marketplace. When this runs on spreadsheets and email, payouts slip and disputes drag on. Building it properly is Platform-tier work: many roles, money flows, and a portal for people outside the company.

This is a sample build. There is no client, and nothing here is a result from a real company.

What it does

  • Takes seller applications and runs ID, company and bank account checks.
  • Imports listings by file or API and checks them against category rules.
  • Splits each order by seller and tracks shipping per seller.
  • Calculates payouts after fees, refunds and held amounts, with two finance approvers per run.
  • Runs disputes and returns with deadlines, evidence and a clear decision.
  • Gives operators, finance, support and sellers their own roles, and logs every action.
A payout run page: five tiles from gross sales to the amount to pay out, a table of sellers with gross, fee, refunds, held and payout columns, and an Approve run button showing one of two approvals.
Payouts. Plain arithmetic, two approvers. Sample data.

The AI part

The model does three narrow jobs. It reads each new listing against the category rules and flags possible banned items or bold health claims. It summarises long dispute threads for the operator, both sides in neutral words. And it reads uploaded company documents into fields that a person checks.

It never approves a seller, never decides a dispute and never touches money. Payout amounts are plain arithmetic in code. We would test the listing checks on a hand-labelled set of listings, including tricky ones, and look at missed flags first, since a miss costs more than a false alarm.

A dispute page for an item not as described: a message thread between buyer and seller with photos, a reply deadline, a model summary of both sides marked as a draft for the operator, and Refund buyer, Partial refund and Side with seller buttons.
Disputes. The model summarises, the operator decides.

Where it stops

No shop front, no search ranking and no seller ads. The back office connects to an existing shop front through its API. Tax reports per country are a separate scoping job.

Timeline

When What happened
Weeks 1 and 2 Roles and permissions, seller accounts, audit log, data model for listings and orders.
Weeks 3 and 4 Seller onboarding with ID and company checks, document upload, the operator review queue.
Weeks 5 and 6 Catalog import by CSV and API, listing review, category rules.
Weeks 7 and 8 Orders split by seller, shipping status, split payments and the payout schedule.
Weeks 9 and 10 Disputes and returns workflow, the seller portal, finance reports.
Week 11 Load test, security review, runbook and handover.