Marketplace Returns Management and Customer Return Portal
How to run marketplace returns without chaos: a customer return portal, barcode check-in at the warehouse, automatic return codes and exchange orders.
- Why a return costs more than it looks
- Marketplace returns and own-store returns are different jobs
- Customer return portal: email and order code
- Barcode check-in at the warehouse and the automatic return code
- Exchange orders: turning a return into a sale
- Returns process checklist
- How it works with Bulutegra
Marketplace returns management means collecting returns from every channel in one list, verifying each item that reaches the warehouse by barcode, and recording the return or exchange correctly in the ERP. A customer return portal is the page where a buyer from your own store starts a return with an email address and order code, which gives you an automatic return code and a warehouse check-in flow. This article covers why returns cost more than they look, how marketplace returns differ from own-store returns, and how a portal simplifies the process for sellers on Turkish and international channels alike.
Why a return costs more than it looks
A return creates four separate costs: the shipping paid to get the item back, the labour to inspect it and make it saleable again, the stock that cannot be sold in the meantime, and whether the marketplace refunds its commission. The last is the one most often missed; in some cases the commission on a returned order stays deducted from your payout. We cover "returns with commission not refunded" in payout and commission reconciliation.
The first way to reduce returns is the product page: correct size data, a size chart, realistic images. Cutting returns with Size Finder and international size and unit conversion cover that side. The second way is to process the returns that do arrive cheaply and quickly, which is this article's subject.
Return rate never reaches zero. The goal is to lower what each return costs the business and to learn why it happened.
Marketplace returns and own-store returns are different jobs
On a marketplace the buyer starts the return in the marketplace's interface; the shipping label comes from the marketplace, the item comes back to you, and under certain conditions the marketplace refunds the buyer. Your job is to accept or reject within the deadline once you receive the item, and to update stock correctly. Deadlines and conditions vary by channel; check the marketplace's current seller agreement.
On your own store the whole flow is yours. The buyer emails you, you generate a shipping label, the item comes back, you refund or send an exchange. Run by hand, this produces three problems: the buyer says "I started my return" but there is no record, a parcel arrives at the warehouse with no clear link to an order, and accounting books the refund late. The customer return portal exists to solve exactly those three.
Customer return portal: email and order code
The portal is a simple page where a buyer from your store starts a return. They enter their email address and order code; the items on the order are listed; they choose which item, how many, and for what reason, and can request an exchange instead. Three things happen at that moment:
- The return request is recorded and appears in the order list.
- An automatic return code is generated and sent to the buyer.
- The reason (size, damage, not as expected) becomes reportable.
The buyer no longer emails and waits, and you no longer search for "which order was that". In Bulutegra the return portal works with email and order code, and the return code is generated automatically. Because the CRM module gathers WhatsApp Business API, email and marketplace questions in a single inbox, context is not lost even if the buyer follows up on WhatsApp after using the portal.
Barcode check-in at the warehouse and the automatic return code
When a return parcel reaches the warehouse, the weakest link is the question "whose parcel is this?". Barcode check-in removes it: the warehouse operator scans the product barcode, the system matches the return code to the order, the item condition is selected (saleable, damaged, missing parts) and stock updates accordingly. A saleable item goes back into the single stock pool and reappears on every channel; a damaged one is held separately.
Two rules make this flow easier. First, a parcel that arrives without a return code drops into a separate "unmatched" list and never mixes into stock. Second, a user in the Warehouse role only performs the check-in; the refund proceeds with approval from the Accounting role. Roles are covered in security, 2FA and roles in marketplace integration.
Exchange orders: turning a return into a sale
Telling a buyer who wants a different size to "return it first, then order again" usually means losing the buyer. An exchange order merges those steps: when the buyer selects exchange in the portal, a new order linked to the return record is created; the new size is reserved from stock, and the flow completes when the returned item reaches the warehouse and is checked in. In the ERP the return and the exchange appear as separate but linked documents, and accounting sees any price difference.
The stock side of exchanges matters: if the new size is out of stock, the portal tells the buyer and steers them to a refund instead. That avoids "exchange approved but item unavailable". In the multi-channel order list the exchange order appears under its own channel tab; multi-channel order management describes that list.
Returns process checklist
- Are your accept/reject deadlines for marketplace returns noted per channel?
- Is the portal live for own-store returns; can buyers start one with email and order code?
- Is the return code generated automatically and sent to the buyer?
- Does the warehouse check in by barcode and select item condition (saleable, damaged)?
- Do saleable returns go back into the single stock pool?
- Is the exchange order linked to the return record, with a stock check?
- Are returns with commission not refunded flagged in payout tracking?
- Are return reasons reported monthly and fed back to the product page?
Item eight closes the loop. If "size" is the leading return reason, the problem is not in the warehouse but on the product page.
How it works with Bulutegra
Bulutegra's returns management has four parts: the customer return portal (email and order code), barcode check-in at the warehouse, automatic return codes and exchange orders. Marketplace returns and own-store returns sit in the same list separated by channel tabs, and saleable items return to the single stock pool. In payout tracking, returns with commission not refunded are followed with a status, a ticket and a note. The Warehouse, Returns, Accounting and Admin roles each see their own step in the flow. See the Solutions section for the modules.
To see the returns flow with your own order data, request a demo.
Frequently asked questions
Do marketplace returns and returns from my own store work the same way?
No. On a marketplace the buyer starts the return in the marketplace's interface and the shipping label comes from there; your job is to accept or reject within the deadline and update stock. On your own store the whole flow is yours, and a customer return portal is what keeps it orderly.
What is a customer return portal?
A simple page where a buyer from your own store starts a return or exchange with their email address and order code. The request is recorded instantly, an automatic return code is generated, and the warehouse checks the parcel in by scanning the barcode against that code.
Is the marketplace commission refunded on a returned order?
It depends on the channel and the conditions; in some cases commission is not refunded. Track "returns with commission not refunded" as a separate line in payout reconciliation and check the marketplace's current seller agreement.
