Merit · Product · Internal Explainer
The Seller Portal, explained
Merit sells goods it does not own. The Seller Portal is where the people who do own them list their stock, take orders, and get them out of the door. Every screen below is exported from the Seller Portal Figma file, so this is the real design, not an impression of it.
01In one minute
If you only read one section, read this one.
Merit runs branded marketplaces where members burn loyalty points on real goods. Someone has to supply those goods. Some come from Merit's own stock, but most come from third party sellers, and every one of them needs a way to say here is my product, here is my price, here is how much I have, and then a way to actually fulfil the orders that follow.
The Seller Portal is that surface. It is the seller's entire relationship with Merit: catalog in, orders out, money back. Before it existed, sellers emailed spreadsheets to the Operations team, who typed them in by hand. Average time from a seller having a product to that product being buyable was seven days.
The strategic goal for 2026 is written as "from manual oversight to automated autonomy". In plain terms: get Merit's Operations team out of the middle. Every screen in this portal exists to remove one thing a human at Merit used to do by hand.
Sellers list products by web form, CSV, SFTP or API. Products land in PIM, an Offer is created against the seller, and it goes live.
Orders arrive, the seller accepts, picks, packs and ships. Who ships depends on the model in section 03.
Delivery closes the order and triggers payout. Today the payout itself is still calculated by hand, monthly.
This is not a consumer product. The primary user is a warehouse operator under time pressure, often on a shared login, often not the person who owns the account. Most design decisions in the portal follow from that single fact, and most of the complaints in section 10 come from forgetting it.
Building this page from the real Figma turned up several places where the shipped design and the written specification disagree, including one that is fully inverted. Section 08 lists them. They are not nitpicks, they change what the revamp is actually for.
02Who uses it
Four roles, two of them inside Merit. Each one meets a different part of the product, which is why there is no single "the seller journey".
Seller Admin (owner)
Sets the account up, adds the catalog, sets prices, manages bank details and invites their own staff. Logs in weekly, not hourly. Cares about margin, payout and whether their products are winning the Buy Box.
Warehouse operator (picker and packer)
The heaviest user by a wide margin. Opens the order queue in the morning and works it down. Standing, often on a shared screen, frequently holding a physical box. Needs big targets, printable paper, and no ambiguity about what to do next.
MFN Elite seller
A trusted seller allowed to use their own couriers. Same portal, different order screen and an extra tracking step. Cannot self serve into this tier, Merit switches it on.
Ops Admin
Works in a different application, the Ops Admin panel, not the Seller Portal. Invites sellers, sets their shipping model, flips the Elite toggle, and reviews everything the matching engine is unsure about. Half of what a seller sees is decided here.
The Seller Portal and the Ops Admin panel are two products with two different users. The Ops Admin panel is not in this Figma file at all, so if it is in scope for the revamp there is currently nothing to revamp from. Worth settling before design starts.
03Three shipping models, and why every screen depends on them
A seller is configured to exactly one of these. It changes the order screen, the actions available, and in principle the data they can see. Read this before section 07.
| Model | Who moves the box | Shown in the portal as | Extra steps |
|---|---|---|---|
| SPL Standard Pick-up Logic | Merit's carrier collects from the seller | Merit Logistics (SPL) | Pack, then request an AWB for pickup |
| FBM Fulfilled by Merit | Merit, from Merit's own warehouse | Seller is mostly out of the per order loop | Send stock to Merit up front |
| MFN Elite Self shipping | The seller's own fleet or courier | Self Managed | Accept, then enter courier and tracking |
SPL is the default. MFN Elite is off unless an Ops Admin turns it on, and per the specification it requires a verified warehouse address in Saudi Arabia and a cancellation rate under two percent.
04Getting a seller onto the platform
Users: Ops Admin, then Seller Admin. Sellers cannot sign themselves up. Every account starts as an invitation from inside Merit.
Setting a seller's default shipping method at invite time happens in the Ops Admin panel, which this file does not cover. It matters because today every invited seller defaults to SPL, and if they are really an MFN or FBM seller somebody has to correct it in the backend afterwards.
05Product upload, all five ways
User: Seller Admin. This is the largest surface in the product and the flow that replaced emailing spreadsheets to Operations. There are five distinct ways in, aimed at five sizes of seller. All five need to be designed, because a seller picks one and lives in it.
| Method | Who uses it | What it handles | Design exists? |
|---|---|---|---|
| 1. Single web form | Small sellers, one-off additions | One product, via a search-first wizard | Yes, detailed |
| 2. Bulk CSV | Mid size, hundreds of SKUs | Template, partial success, per-row results | Yes, detailed |
| 3. Bulk images by URL | Anyone using CSV | An images column of pipe-separated URLs, fetched asynchronously | Spec only |
| 4. SFTP drop | Enterprise, 1000+ SKUs | Seller's ERP writes a CSV to a dedicated folder, polled every 5 minutes | Spec only |
| 5. API | Technically integrated sellers and aggregators | Keys, batch endpoint, status polling, rate limits | Spec only |
Methods 3, 4 and 5 exist in the PRDs and nowhere in the Figma file. That is not a gap in this document, it is a gap in the design, and it is arguably the single most useful thing on this page for planning the revamp. Two of the five doors are drawn, three are not.
Method 1: the single product wizard, which starts with search
The most important thing about this flow is the order of operations. It does not begin by asking for a category or product details. It begins by asking whether Merit already sells this thing.
From here the flow forks, and the Figma organises it as exactly those two branches: Listing Exists and Listing Doesn't Exist.
Method 2: bulk CSV, and the best screen in the product
The tooltips in that screen are the clearest statement of the rules anywhere in the product:
| Outcome | What the tooltip says | Status |
|---|---|---|
| Successfully processed | All mandatory attributes are present, the entry has been accepted and processed | Live |
| Invalid or rejected | One or more mandatory attributes are missing, the entry was rejected and needs correcting before re-uploading | Fix and re-upload |
| Match found | A matching product was found, the offer has been linked to the existing listing automatically and is live now | Live |
| Possible match | A similar product may already exist, this entry will be reviewed by the admin team to confirm the correct match | Under review |
| No match found | No matching product was found, a new listing will be created after admin review | Under review |
The confidence numbers visible in the design settle a question the written documents disagree about. Rows at 96 and 95 percent are Match Found and go live. Rows at 90, 85 and 82 percent are Possible Match and wait for review. A row at 45 percent is No Match Found. So the boundary for going live automatically sits above 90 percent, which matches the upload PRD's three bands and contradicts the single seventy percent threshold described in the 3 August onboarding session.
A row missing a critical field, price, SKU or GTIN, is Rejected and the seller must fix the file. A row missing a recommended field, description or weight, becomes a Draft, saved and finishable in the UI. Same failed import, two completely different recovery journeys.
Methods 3, 4 and 5, specified but never drawn
Bulk images ride on the CSV rather than being a separate upload: an images column holds pipe-separated public URLs, fetched asynchronously and stored under a content-addressable name so the same photo uploaded by two sellers is stored once. Links must be direct and unauthenticated, with a specific exception for public Google Drive links. Failures are per image, not per row, so a product can go live with two of its three photos, and nothing in the current design shows that partial state.
SFTP gives enterprise sellers a folder at /sftp/seller_{id}/inventory/, polled every five minutes, with differential updates so unchanged rows are skipped and a processing report emailed back. The portal becomes a monitoring surface rather than an input one, and no such surface exists in the design.
The API needs a developer area: sk_live and sk_test key management, webhooks, a rate limit of 100 requests per minute, and batch status polling via POST /v1/products/batch then GET /v1/batches/{id}. Note the specification assumes a sandbox environment, and there is no Seller Portal sandbox today.
06Price and stock
User: Seller Admin. The highest frequency catalog action by far, and the one where latency costs real money.
Stock decrements when payment is confirmed, not when the customer reaches checkout. There is no reservation or hold. Two customers can therefore both buy the last unit, and one of them fails after paying. This is known, confirmed current behaviour, and the interface has to deal with it honestly rather than pretend it cannot happen.
07Fulfilling an order
User: warehouse operator. The core loop of the product, and the screen the heaviest user spends the day in. The Figma splits it into two boards, one per shipping model.
Merit Logistics (SPL). The primary action is Request AWB and Ship, with the helper text "Pack the order and click Request AWB when ready for SPL pickup", so the seller signals readiness and Merit's carrier takes over. Note the right hand Order Timeline, Print Items on the items card, and Special Instructions carrying handling notes. Figma: Hi Fi Designs / Orders - Merit logistics, 988:10172
| State | Allowed action | Who gets told |
|---|---|---|
| New | Accept, Cancel, Print items | Seller email |
| Accepted | Pick and pack, then Request AWB (SPL) or enter tracking (Self Managed) | Customer sees "Accepted" |
| Ready to ship | Hand over to carrier | Customer push notification |
| Shipped | Manual delivery override only | Customer sees courier and tracking |
| Delivered | None, order is closed | Payout triggered |
An order becomes Delivered when the customer taps "Received" in the B2C app, or automatically after seven days with no dispute raised. That auto close is what makes payout possible without a human confirming every parcel.
After bulk accepting a batch of orders, the operator is returned to the order list with no indication of what to do next, and has to open each order individually. The proposed fix is a preparation view: the accepted batch on one scrollable surface, each card showing order, tenant, item, SKU, quantity and packing notes, markable as packed without navigating away, resumable if they leave. It is not in the Figma and it is the highest value gap in the product.
08Where the design and the specification disagree
Found by building this page from the Figma and the PRDs side by side. Each of these needs a decision, and each one changes what the revamp is for. Take this list to the demo.
1. Customer data masking is the wrong way round
The specification says a seller on SPL must see the customer's name, phone and address masked, because Merit's carrier holds the delivery details and the seller only needs to pack a box. It says an MFN Elite self-shipping seller sees the full details, because they physically have to deliver to that address.
The Figma does the opposite. The SPL order screen shows the full name, email and phone. The Self Managed screen masks them. Logically the specification is right: you cannot deliver a parcel to ******313.
Also: in both screens the shipping address block is fully readable regardless, so address masking does not appear anywhere in the design, and the masking format differs from the spec too. The spec asks for Ah***d, the design shows A***r R***.
2. The match threshold
The 3 August onboarding described a single seventy percent confidence threshold. The upload PRD specifies three bands, and the Figma confirms the PRD: above ninety goes live, sixty to ninety waits for review, below sixty is treated as new. The seventy percent figure should stop being repeated.
3. The API assumes a sandbox that does not exist
The upload specification offers sellers an sk_test sandbox key. There is no Seller Portal sandbox environment; it was deferred with the wider sandbox effort, which is also why the design team has to be given staging accounts instead.
4. Two visual languages in one file
The product upload screens use a dark navy application header. The order screens use a white header with a left navigation rail carrying text labels. These are different design eras sitting in the same product, and any revamp has to pick one deliberately rather than inherit both.
5. Large parts of the product were never designed
No design exists for: the SFTP monitoring surface, the developer and API area, bulk image partial-failure states, the Ops Admin panel, the printed pick list, the post-bulk-accept preparation view, self-service returns, or a settlement and payout view. Several of these are in the 2026 roadmap, so the revamp is partly a redesign and partly original design, and those are different kinds of work to estimate.
09What actually exists today
Three separate questions get confused constantly: is it specified, is it designed, is it shipped. This table keeps them apart.
| Area | Specified | Designed | Shipped |
|---|---|---|---|
| Seller onboarding wizard | Yes | Yes | Live |
| Single product upload, search first | Yes | Yes | Live |
| Bulk CSV and upload results | Yes | Yes | Live |
| Price and stock | Yes | Yes | Live |
| Order list and order detail | Yes | Yes | Live |
| MFN Elite self shipping | Yes | Yes | Partial |
| Bulk images by URL | Yes | No | Partial |
| SFTP ingestion | Yes | No | In progress |
| External API and developer area | Yes | No | In progress |
| Printed pick list, A4 and 80mm | Yes | No | Partial |
| Post bulk accept preparation view | Yes | No | No |
| Secure account change, dual OTP | Yes | No | No |
| Performance dashboard | Yes | Partial | No |
| Self service returns | Yes | No | No |
| RBAC and team accounts | Yes | Partial | No |
| Settlement and payout view | Partly | No | Manual |
| Ops Admin panel | Yes | Not in this file | Live |
The Specified and Designed columns are solid, they come from the PRDs and from the Figma directly. The Shipped column is assembled from meeting records and moves faster than any document. Verify it screen by screen during the demo.
10Notes for the revamp
The constraints that will bite, and the problems worth solving first.
Rules that come from the specification, not from taste
- Masking exists for a legal reason. Merit is the merchant of record, so the seller does not own the customer relationship. Which side gets masked needs settling, see section 08, but the principle is not a design preference.
- The pick list carries no money and no identity. No price, no totals, no customer name, address or phone. It must render on A4 and on an 80mm thermal roll. It has never been designed.
- Print is available before Accept. Operators need the paper in hand before they commit.
- Actions are state locked. Cancel disappears once an order is shipped. The action area is a state machine, not a fixed toolbar.
- Stock has no hold, so a last unit can be double sold and the interface has to handle that honestly.
- Returns never auto restock, because returned goods may be damaged.
- Account changes need OTP to both the old and the new address, in one session, fifteen minute expiry, three failures freezes for an hour.
- Sellers see "Catalog Item" and "Your Offer", never "Identity" or "Marketplace Record". Internal vocabulary leaking into seller screens is a known failure here.
The problems, roughly in order of how often they come up
- No preparation view after bulk accept. The biggest single gap.
- Tenant name missing from order detail. Operators fulfilling for Al Fursan, SAIB, Kantar and Saudia need to know which branding and repackaging applies before they start packing, and it must persist across every state. It is not on the order screens in the Figma.
- Order list is thin. Needs product thumbnail, product name and product ID.
- Search is weak. No filter by internal UUID or merchant SKU, date range too short, and search and date filters conflict instead of combining.
- Bulk upload error reporting is good in the design and thin in the shipped product, so this may be an implementation gap rather than a design one. Worth checking on staging first.
- No performance visibility, while sellers are judged on cancellation rate and dispatch SLA.
- Returns are invisible to the seller.
- No settlement view, so payout is a black box.
Is the Ops Admin panel in scope? It is a different product with a different user and it is not in this Figma file. And is this visual and interaction level only, or is information architecture in scope? If it is the latter, items one to four are design problems rather than restyling.
11Glossary
The words that come up constantly and mean something specific here.
- SPL
- Standard Pick-up Logic. Merit's carrier collects from the seller. Appears in the portal as "Merit Logistics (SPL)". The default for every new seller.
- FBM
- Fulfilled by Merit. The seller ships stock to Merit's warehouse in advance and Merit fulfils to the customer.
- MFN Elite
- Self shipping, shown as "Self Managed". A trusted seller uses their own courier and enters their own tracking. Off by default, admin enabled.
- AWB
- Air Waybill, the carrier's shipping document. On an SPL order the seller requests one once the parcel is packed, which is how they tell Merit it is ready for pickup.
- Tenant
- The branded marketplace an order came from: Al Fursan, SAIB, Saudia, Kantar. It decides packaging and inserts, which is why operators need it visible before packing.
- Offer
- A seller's price and stock against a catalog product. Several sellers can hold offers on the same product, which is what makes it a marketplace.
- Buy Box
- The winning offer shown by default on a product page. Chosen on trusted stock, availability, total price including shipping, and seller cancellation rate.
- PIM
- Product Information Management, built on MedusaJS. Holds product data, separate from price and stock.
- Match Found, Possible Match, No Match Found
- The three outcomes of identity resolution on upload. Above ninety percent confidence goes live automatically, the middle band waits for admin review, and the bottom band becomes a new listing after review.
- Source Authority Scoring
- How conflicting product data is resolved. Merit retail scores 100, a brand owner 90, an authorised distributor 70, a marketplace seller 50. Higher wins. This is why a seller's description can silently not appear.
- Merchant of Record
- Merit is the legal seller to the customer, which is why the seller does not own the customer relationship and why masking is legitimate rather than obstructive.