How to Standardize Returns in Marketplace Selling? Process, SLA and KPIs in Practice

The best way to standardize returns in marketplace selling is to build a single process model — running from the initial request all the way through to the refund and the product’s second life. Every stage gets an owner, a clear start and stop event, an SLA (the agreed level of service delivery) and an assigned KPI (a measure of how the process actually performs), while statuses from the marketplace, the ERP, the WMS and the carriers all flow into one shared pool of data.

A fixed procedural core does not, however, mean an identical policy for every channel. Below we show how to design a marketplace returns process that reconciles the requirements of individual platforms with measurable SLAs and concrete KPIs. We have also put together a sample process map, a glossary of metrics and an implementation plan.

What will you learn from this article? In brief

• We built this guide on the Alsendo report “Returns in Polish E-commerce 2026”.
• Multichannel selling makes the process more complex — in a survey of 300 Polish e-commerce companies carried out at the turn of January and February 2026, 35% combined their own store with marketplace sales. Statuses and data from every channel are best mapped into a single model.
• Not measuring is often as serious a problem as the returns themselves — the average declared return rate in the survey was 3.5%, yet one third of companies were unable to state the figure for their own organization. That result best reflects the reality of smaller sellers, since they made up the bulk of the sample.
• One aggregate SLA is not enough — it is better to measure request confirmation, dispatch, transport, warehouse receipt, inspection, refund and the product’s return to availability separately.
• KPIs have to show time, cost, quality and recovered product value — in practice that means metrics such as return rate, time-to-refund, cost per return and SLA compliance rate.

Why do marketplace returns need standardizing? A shared model curbs the chaos between channels

Marketplace returns need a unified standard: every sales channel works with its own statuses, deadlines and settlement rules, and yet the customer experiences the whole thing as a single interaction with your brand. On the seller’s side, a return usually involves several parties — the marketplace, the order system, the logistics provider, the warehouse, finance and customer service — so without a shared model it is easy to end up with unlinked case numbers, a duplicated refund, or a status that is visible in one system and invisible in another.

As many as 38% of companies report gaps in integration and in the IT tools they use to track returns, which is direct confirmation of how widespread the problem of data scattered across systems really is. Respondents to the “Returns in Polish E-commerce 2026” survey also point to other serious challenges in handling returns: 51% name customer abuse (returning used or swapped products, for instance) and 45% name operating costs.

Standardization is not about imposing an identical policy on every channel; it is about unifying a shared core — one status dictionary, a minimum set of mandatory fields and identical measurement rules — while keeping distinct rules for a particular marketplace, market or product category. The more channels you run, the more handling variants become possible, which is why manual control stops scaling in organizations operating across several or a dozen-plus markets, and a shared data layer with automatic alerts becomes essential.

What should a standard marketplace returns process look like? Seven stages from request to value recovery

A standard marketplace returns process spans seven measurable stages, linked by a single case identifier and a common set of timestamps. The SCOR model (Supply Chain Operations Reference) — the most widely used standard for describing supply chain processes — illustrates this well, singling out Return as a separate process that covers the reverse flow, the assessment of the product’s condition and the decision on what happens to it next. That is one reason not to reduce a return to the transport of a parcel.

1. Return request — recording the channel, the order, the line item, the quantity, the reason and the expected form of settlement.
2. Eligibility check and authorization — verifying the deadline, the product, the rules of the specific channel and any exceptions.
3. Dispatch instructions issued — sending the label, code or address together with an RMA number.
4. Return transport — monitoring the carrier’s first scan and the transport events that follow.
5. Receipt and inspection — matching the parcel to the request, assessing the product’s condition and logging any discrepancies.
6. Decision and settlement — refund, exchange, partial refund or escalation of the case to manual review.
7. Product disposition and closure — back to sale, marked down, repaired or scrapped, which is the final decision on what happens to the product.

Withdrawal from a contract, a commercial return, a warranty claim and an exchange are, however, different processes, each with its own owner and its own settlement logic — mixing them in a single report distorts your metrics and makes channels harder to compare.

Request, authorization and dispatch — the shared start of the process

Every return should get its own RMA number (Return Merchandise Authorization, which is both the identifier and the authorization procedure for a return), tied not to the whole order but to a specific line item. That way, returning one item from a multi-item order does not complicate the settlement of everything else.

The system should pull in the data already held against the order automatically, apply a single catalog of return reason codes, and confirm receipt of the request immediately, recording the timestamp of that event. In large organizations, customers sometimes file the same return in parallel through the marketplace panel and through customer service — which is precisely when deduplication of requests takes on added importance.

It is worth building the minimum RMA record on a handful of fields:

• RMA number and order identifier — these tie the request unambiguously to a specific line item rather than to the whole order;
• source channel and marketplace — these let you segment the data and apply the right channel rules;
• return reason code — a standardized dictionary instead of a longer free-text description;
• expected form of settlement — refund, exchange or another way of closing the case;
• timestamps for the key events — request, authorization, dispatch, receipt;
• shared status — the source system’s status mapped onto a single dictionary.

Transport, receipt, settlement and closure — the shared end of the process

The logistics provider’s first scan confirms that the shipment really has entered transport, but it pays to separate the waiting time on the customer’s side from the actual transit time. Once the parcel arrives, the warehouse links it to the RMA number, checks the quantity and the product’s condition and assigns a quality grade — fully saleable, say, or requiring a markdown or a repair — and only on that basis does the system trigger the refund under the agreed rule and update stock.

A return should not be counted as closed simply because the customer has their money back, because for operations and finance the process runs until the decision on the product’s future has been taken and carried out. Our report “Returns in Polish E-commerce 2026” shows that around half of returned products go back on sale as fully saleable goods, which is exactly why value recovery deserves to be treated as a separate objective of the process rather than a by-product of the refund.

How do you build an SLA for marketplace returns? Separately for the customer, operations and partners

A return that has been in limbo for three weeks — has the customer not sent the parcel yet, has the warehouse not got round to the inspection, has finance not released the transfer? — is the most common symptom of a missing SLA. The fix is simple: set an SLA for each stage of the return separately, so that a delay becomes visible exactly where it arose instead of disappearing inside one aggregate “returns handling” deadline.

A good SLA defines:

• the event that starts and the event that ends the measurement,
• the target value,
• the calendar — business hours or elapsed time,
• the owner of the stage,
• the escalation path once the warning threshold is breached.

In practice, three levels of SLA matter:

• External SLA — the commitment made to the customer, or the requirement of a specific marketplace.
• Internal SLA — the operational level for the warehouse and customer service.
• Partner SLA — the turnaround time on the side of the logistics provider or the payment provider.

Internal deadlines should leave a buffer ahead of the external one — otherwise even a minor delay in the warehouse automatically breaks the promise you made to the customer.

Data from our survey shows how wide the gap between companies is: 49% refund the customer within a maximum of five days of receiving the return, but around 40% need at least 11 days, including 23% who take more than 14.

Table 1. A sample process and SLA matrix (the values are a target to calibrate against, not a universal market standard)

Stage	Start event	Stop event	Sample SLA	Owner
Request	customer submits the request	confirmation of receipt	within 15 minutes	system / IT
Authorization	request received	authorization decision	within 30 minutes	customer service
Dispatch instructions	authorization	label sent	within 30 minutes	system / IT
Transport	label issued	carrier’s first scan	monitored separately	logistics provider
Warehouse receipt	delivery to the warehouse	registration in the WMS	within 4 business hours	warehouse
Inspection	receipt	product assessment completed	within 24–48 hours	warehouse / quality
Decision and refund	inspection completed	refund instruction sent	within 24 hours	finance
Disposition	product classified	available for sale again	within 24 hours for grade A	warehouse / sales

Which KPIs measure marketplace returns best? Time, cost, quality and recovered product value all count

The best set of KPIs tells you four things at once: how fast you handle a return, how much it costs, how well it is executed, and how much of the returned product’s value you manage to recover. A single metric such as return rate on its own is not enough — it shows the volume of returns, but says nothing about whether the process is fast, cheap or effective.

To compare a given metric over time and between teams, you have to fix a clear definition for it: exactly what you are counting, from which moment to which, in what unit, who is accountable for the result, and at what value the alarm goes off. Without that, two people can calculate “the same” metric in two different ways and reach contradictory conclusions.

Table 2. A glossary of the core KPIs

KPI	Definition and formula	Unit	Notes
Return rate	units returned / units sold × 100%	%	do not mix up with the definition calculated from orders or from GMV
Time-to-refund	time from the agreed start event to the refund instruction being sent	days/hours	always state which event starts the measurement
Return processing cycle time	time from the return being initiated to the final decision on the product	days	a broader definition than time-to-refund
SLA compliance rate	cases completed within SLA / cases subject to SLA × 100%	%	calculate separately for each stage of the process
Cost per return	total process costs / number of closed returns	PLN	include transport, labor, systems and the loss of value in the goods
Full-price restock rate	products restocked at full price / products after inspection × 100%	%	not to be confused with total value recovery
Exception rate	returns requiring manual intervention / all returns × 100%	%	a high figure signals gaps in automation
Touchless return rate	returns handled without manual intervention / all closed returns × 100%	%	rises as systems integration matures
Value recovery rate	net value recovered from returned products / original value of those products × 100%	%	shows the value actually recovered, not just the volume of returns

The one KPI companies get wrong most often is cost per return: teams count only transport and handling, leaving out systems, specialist time and the loss of value in the goods. The real cost of a return is then understated — and the decisions based on that figure are wrong.

How do you roll out and automate a returns standard? Start with an audit, then integrate the data and the decisions

It is best to spread the rollout of a standard over several stages — first measure the process as it is, then test it in a pilot, and only at the very end automate the repeatable decisions.

• Days 1–30 — audit and baseline: map the processes in each channel, settle on one definition of return rate and time-to-refund, and pinpoint the biggest sources of manual work.
• Days 31–60 — standard and pilot: a shared dictionary of statuses and reasons, stage-level SLAs with named owners, a basic dashboard, and a pilot in one channel or one market.
• Days 61–90 — integration and automation: connect the data from the marketplace, the ERP and the WMS, generate labels automatically, match scans to the RMA number, and compare the pilot’s KPIs against the baseline.
• After 90 days — scaling: extend the standard to further channels and markets, and segment SLAs by product category and risk level.

The architecture behind this standard usually takes in the marketplace as the source of the order, the ERP (enterprise resource planning software) as the source of commercial and financial data, the WMS — the warehouse management system — as the source of receipt and stock data, and an integration layer that pulls the events together into a single picture of the process.

Today, companies mainly automate the basic steps of the process: 83% use automatic notifications about return status. Data is integrated with the logistics provider by 56% of businesses and with an ERP or e-commerce system by the same share, while only 48% use a dedicated returns management platform.

Table 3. Sample status mapping

Source status	Shared status	Event	Automatic action
“Return requested” in the marketplace	Request received	request registered	confirmation and RMA number sent
“Label generated” at the carrier	Label generated	dispatch instructions issued	status updated in the customer panel
Shipment’s first scan	In transit	carrier’s first scan	transport timer started
“Delivered to warehouse” in the WMS	Received into the warehouse	receipt registered	linked to the RMA number
“QC completed”	Inspection completed	condition assessment completed	refund rule triggered
“Refund issued” in the payment system	Funds refunded	refund instruction sent	case closed in the customer panel

From manual handling to an integrated marketplace returns platform

Picture a company selling on eight marketplaces in four countries, with three logistics providers and a separate warehouse for each market. Keeping an eye on statuses by hand in a setup like that stops scaling. Only 48% of companies currently use a dedicated returns management platform; the rest run the process manually, with email notifications, statuses copied between systems and spreadsheets to reconcile the data. Above a certain scale, that kind of model starts to cost more than implementing a platform would.

For any organization in that position, the integration layer can be handled by the Alsendo Innoship logistics platform, which merges data from the marketplace, the ERP and the WMS into the single event model described above. Not every company needs an off-the-shelf solution, though. Where the standard calls for its own exception logic — different refund rules for business customers than for consumers, say — a bespoke integration under Alsendo Enterprise is the better fit. Stores that are only now building their first shared standard across one or two channels can start with a smaller step: Alsendo Business Pro.

Whichever tool you choose, technology does not design the process on its own; it supports the process once the company has settled the definitions, the data, the SLAs and the accountability for each stage. A mature organization no longer asks only how many returns it has, but above all where in the process it is losing time, cost and product value.

FAQ — questions about the process, SLAs and KPIs for returns in marketplace selling

Below we answer the questions that come up most often when designing and automating a returns process.

What is the difference between an SLA and a KPI in returns handling?

An SLA sets the expected level of performance for a specific stage, whereas a KPI measures how the process actually performed. The SLA compliance rate is only one KPI among many.

How long should a marketplace return take?

There is no universal deadline for the process as a whole. Measure the wait for dispatch, the transport, the receipt, the inspection, the refund and the product’s return to availability separately, and match the individual targets to the category, the country and your logistics model.

How do you calculate the full cost of a single return?

You get to cost per return by adding up transport, labor, warehouse handling, systems, materials and the loss of value in the goods. Divide the result by the number of closed returns. Show the gross cost alongside the net figure after product value recovery.

Can one returns process serve several marketplaces?

Yes, as long as the core of the data, the statuses, the measurement and the accountability stays shared. Rules on deadlines, communication and dispatch methods can differ from one channel to another.

How do you measure cross-border returns?

Measure the time to the first scan, the international transport, the consolidation and the transport to the central warehouse separately, and segment your KPIs by country and route at a minimum. That matters most where international sales are only just picking up: in our survey, only 20% of companies sold cross-border, and of those, 66% accepted returns solely to an address in Poland, with no additional convenience for buyers abroad.

Sources:

• Alsendo — Returns in Polish E-commerce 2026 (report)
• ASCM — SCOR Digital Standard (SCOR DS)

Rafał Urbanek