> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to handle returns and exchanges as a process
- URL: https://blog.jestor.com/handle-returns-and-exchanges/
- Published: 2026-09-16T18:53:47.000Z
- Updated: 2026-09-16T18:53:47.000Z
- Author: Bruno Bannach

To **handle returns and exchanges** consistently, the request needs a stage for inspection and a decision rule that does not depend on who answers. In **Jestor**, a return is a record connected to the original order, with photo evidence, a reason category and an outcome.

## Why returns are handled inconsistently

Returns arrive through whichever channel the customer prefers, and are resolved by whoever picks them up. Two customers with identical situations get different outcomes, which is the fastest way to generate complaints about fairness.

The reason data is also lost, which is the most valuable part.

What a structured process fixes:

- Identical cases resolved differently
- No evidence of the item's condition on arrival
- Refunds issued before the item was inspected
- No data on why products come back
- Stock returned to inventory without a quality check

## Stages for a return

| Stage          | What happens                       | Evidence          |
| -------------- | ---------------------------------- | ----------------- |
| Requested      | Customer states reason             | Reason category   |
| Authorized     | Eligibility checked against policy | Decision recorded |
| In transit     | Item on its way back               | Tracking          |
| Inspection     | Condition verified                 | Photos attached   |
| Outcome        | Refund, exchange or refusal        | Justification     |
| Stock decision | Restock, repair or write off       | Recorded per item |

## Step by step to build it

1. **Connect the return to the original order**, so history is available.
2. **Require a reason category**, from a short controlled list.
3. **Check eligibility against policy** at authorization, not at inspection.
4. **Require photos at inspection**, before any outcome is decided.
5. **Record the outcome with a justification**, including refusals.
6. **Decide the stock disposition** explicitly for every item.
7. **Review reasons monthly**, grouped by product.

## Why the reason data is the real prize

Returns are a cost, and the instinct is to minimize processing effort. The more valuable output is the pattern: one product returning for the same reason repeatedly is a description problem, a quality problem or a sizing problem, and fixing it removes the cost entirely.

## Why choose Jestor

In **Jestor**, a return connects to the original order and its items, reason categories live in a controlled registry so grouping is reliable, photos render inside the card without downloading, conditional rules can require evidence before an outcome stage, and stock disposition can move inventory through the same integration used elsewhere.

## Frequently Asked Questions

### Should refunds be issued before inspection?

Only if your policy says so explicitly, since inspection is what verifies condition. See [jestor.com](https://www.jestor.com/?ref=blog.jestor.com).

### Why use a controlled list of reasons?

Because free text reasons cannot be grouped, and grouping is what reveals the fixable pattern.

### What should happen to returned items?

A disposition decision per item: restock, repair or write off, recorded on the record.

## Video Tutorial: Step by Step

With **Jestor**, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by **AI**. Discover Jestor at [jestor.com](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.