Guide chapters
00 - How to use this guide01 - The marketplace model comes before features02 - Sellers: data model and onboarding03 - The seller catalogue04 - Integrating seller shops05 - Stock levels06 - Cart and checkout07 - The order model08 - Shipping and fulfilment09 - Payments10 - Payouts11 - Commissions12 - Promotions and loyalty13 - Returns and disputes14 - Moderation and operator decisions15 - The operator panel: from one person to a team16 - Events, notifications and recovery17 - Security boundaries in a marketplace18 - Reversible and irreversible decisions19 - The maturity matrix: manual or automated20 - A reference MVP
Chapter 19
The maturity matrix: manual or automated
Why this table#
The whole guide comes down to one distinction: what should be done by hand, what by machine, and what exactly decides. This table gathers it in one place.
The mistake column matters most. A manual process is fine as long as it does not remove the option of automating later, and it usually removes it by not recording something, not by lacking code.
The matrix#
| Process | At the start | Trigger | Next stage | Most expensive mistake |
|---|---|---|---|---|
| Seller approval | manual | approvals take a fixed block of time | queue and filters | no record of the decision reason |
| Catalogue | manual entry | a seller has hundreds of products | file import | a product without variants |
| Integrations | none | a seller has a shop | one-off import | no external identifier |
| Stock | manual or from import | selling in two channels | synchronisation | stock as a field on the product |
| Shipping | method and cost on the group | parcel volume | carrier integration | no record of who bears the cost |
| Payments | one provider | a second payment method | a shared layer | no event ledger |
| Payouts | manual | repetition and mistakes | a schedule | payouts not linked to orders |
| Commissions | one rate | an individual rate | rules with precedence | the amount computed on read |
| Returns | request and decision | a second partial refund | link to the payout | returns only of whole orders |
| Moderation | manual, history on the object | a second person decides | decision author and notes | no author field |
| Panel | contextual screens | a second person in the panel | roles and filters | data isolation in the view |
| Observability | logs and visible errors | the first discrepancy | a discrepancy listing | failed jobs disappearing |
How to read the triggers#
A trigger is an event, not a number. It is not about a sales threshold or a seller count, it is the moment the current version starts producing work or errors. That moment arrives at wildly different scales in different projects.
Need to implement these processes in a real marketplace?
I design multi-vendor platforms with onboarding, payments, moderation, and operational workflows.
Explore marketplace development