Closing the loop

Creating the order is not the end of the job.

A return isn’t finished when it reaches your order system. It’s finished when the customer knows what happened. In between sit your OMS, your warehouse, a carrier — and a queue of people asking for an update. Here’s how Returnberry closes that gap.

#
Step
Who
Status here
01

Capture

The request arrives by email, ticket or form. Returnberry reads it and builds a return order — an RMA — ready for your system.

Automatic

New
02

Understand

It’s checked against every earlier request, linked to its follow-ups and routed to the right return location.

Automatic

New
03

Complete

The customer fills the gaps from a one-time link, or your team does it by hand.

Customer or your team

Customer review
04

Create

By connector, API, or your system’s import file — mapped to your fields and recorded as a batch.

Automatic

Sent
—

Your systems process it

The RMA is approved, a label issued, the item received. Returnberry never touches their internals.

Your OMS · WMS · carrier

—
BACK

The status comes back

By webhook or API sync — or as a file, through preview → confirm → commit → revert. Matched on the references Returnberry sent, not on your systems’ internal IDs.

Returnberry

Completed
05

Close

The update lands on the original ticket and the ticket resolves — once every return on it has an outcome, and exactly once, ever.

Returnberry

Ticket resolved
Why it is built this way

Three decisions that keep this safe.

01 — Preview writes nothing

Because files are never quite what you were told

Columns are mapped from the file’s own headers, and the operator can override them. Every ambiguity refuses instead of picking. A value that fails validation is reported, not stored. Being wrong about the file is visible, not damaging.

02 — Undo exists

Because one mis-mapped column is otherwise permanent

A completed return can’t be pushed backwards by hand. Without a reverse, a single bad mapping would strand real returns as “complete” carrying the wrong numbers. Revert clears only what that import wrote.

03 — The update waits for the status

Structurally, not by policy

The ticket update is built from what’s recorded on the order — there’s no way to hand it a value. Posting runs as its own sweep, so an import that stops halfway can never leave a completed return with a customer who was never told.

Two modes

Start invisible. Widen when you trust it.

A private note is invisible to the customer and emails nobody — the safe first run. A public reply is the mode that actually removes the “any update?” tickets. Resolving the ticket afterwards is a third, separate switch.

Before anything is posted, the live thread is checked: if someone on your team already answered by hand, nothing is sent.

See it with your own tickets.

We’ll run a week of your requests through a sandbox workspace and show you every verdict — before anything touches your systems.