Returns abuse software that catches the abuse and lets honest returns through fast
A return that says "doesn't fit" over a worn hem, and a return that really doesn't fit, arrive looking almost the same. Returns abuse software reads the wording and the pattern, applies your written rules the same way every time, and never slows the honest ones down to catch the rare bad one.
Updated
Returns a month, times the share nobody actually reads closely, times what your average refund is worth — that product is what a rubber stamp is costing you this month. Your numbers, not mine.
Every return judged the same way, the honest ones through fast
Tell me what your returns queue looks like
Two lines is plenty. How many returns a month, and what your written rules already say. I read it myself and answer within one working day.
Sergey Avakyan. You are writing to me, not to an inbox — I am the whole company, and I am the one who builds it. More about me →
One rule applied to the first claim of the month and the last — never a manager's mood deciding, and never a refund without the goods coming back.
Projects go in the order they arrive — the earlier we start, the earlier yours is built.
- Reads every claim against the rules you already have, the same way every time — no manager grinding through the pile by feel.
- Catches the patterns: worn-and-returned, a damage story the photo doesn't support, the wrong item back, a run of claims from one address.
- Honest returns approved and collected in the same run, with no delay for being ordinary.
- One batch each morning, every refusal with a reason attached, for you to sign — never a refund issued on its own.
The part that reads a claim against a written rule and never bends it twice is not new work. It sorts every return in my own store the moment it lands, the same way every time, and hands one batch a morning for a person to sign — one of the thirteen systems of mine running daily, out of sixty-five built.
A quarter of whatever figure we agree is due at the start, and that quarter is the only money at risk under the two-week promise — nothing else is due until the first real batch is judged. What puts you at the bottom of that band: one marketplace, a returns process that already lives in one system, and rules you can already say out loud. What puts you at the top: several marketplaces or warehouses, a returns process split across systems that disagree with each other, and rules nobody has written down yet. It lands in the middle band because sorting a claim is the easy half — the work is reaching into your order data cleanly enough to trust the answer, and agreeing what a refusal is allowed to say.
- Two weeks, or the first stage is free. The first stage is one named piece, written down before we start. If it isn't running two weeks after the start, you pay nothing for it. The clock pauses on any day I'm waiting on you for an access or an answer.
- You write the pass mark before I write the code. Before anything is built we agree one sentence that says what working means — for example, "it takes the call, puts the booking in the calendar and never promises a price, on nine of every ten of fifty real calls". If it misses that, you choose: I finish it at my own cost, or you take that stage's money back and the work stays with me.
- Three months of fixes included. For three months after handover I fix whatever breaks in what I built, already paid for. Something you ask for later, or a service someone else changes underneath it, is new work — and I'll tell you which it is before I touch it.
“I” here is the whole company: AVAROPA SLU, one founder and one employee, both of them me. The guarantee is the company's, and I am the person who honours it — you deal with the same one throughout.
Every stage you have paid for is yours the moment it is paid — the code and the accounts, handed over as we go. Nothing here depends on you staying.
Prices exclude VAT — 21% in Spain, reverse charge for an EU business with a valid VAT number, and normally none outside the EU — confirmed on your invoice. The band is a starting point; the exact figure is agreed and fixed before any work begins, and it does not move after that. The two-week first piece is the part I guarantee; the finish windows are what a job this size usually takes.
What changes on Monday
Whoever opens the queue first either waves it through to clear the pile, or argues about it in the group chat.
Read against the written rule, refused with the reason attached, and queued in the morning batch for a signature.
Each claim is judged on its own, because nobody remembers the first three.
Matched to the pattern the moment it lands, flagged for a person to see the history before deciding.
Sits in the same pile as everything else, waiting its turn behind the disputed ones.
Approved and collected in the same run, no delay for being ordinary.
None of this needs your team to change how they process a parcel. The rules are the same rules — just applied every time instead of when someone has the patience.
How it works, what it refuses, and when you don't need it
What this is built out of
Every part of this already runs somewhere. Sorting a claim against a written rule the moment it lands, and reading the buyer's own wording for the patterns that mean abuse, is what my returns and defects handler does in my own store today — a four-sentence brief from the person who runs sales turned into rules, and the default of approve-and-collect is correct roughly nine times in ten. The second, independent check before a decision ships — one pass proposes, a separate pass has to agree before a refusal goes out — is the same shape as the check that already reads every reply on the customer-chat side, kept as a plain deterministic filter because a model checking its own model leaked under variance. And the rule itself lives as a written contract inside the data platform: a definition nobody wrote down does not get to quietly apply — it is refused at the door and reported.
So the build is not research. It is fitting that pattern — read, check against a written rule, a second check before anything ships, one batch for a person to sign — to your returns, your rules and your marketplaces. The systems on this site run from a single chat bot up to one that answers questions about a whole business; sorting a return sits comfortably inside that.
The claims that are hard, and how they are handled
- An honest claim that reads badly. A real defect, described in a hurry, can sound exactly like an excuse. The rule checks the wording and the days since delivery, not the tone — a genuine one-off goes through the same as any other honest return.
- Abuse dressed as honesty. Someone who wore it once and knows to write 'doesn't fit' will write exactly that. No single sentence catches it; the pattern across claims — the same address, the same wording, the same timing — is what does.
- A photo that doesn't match the story. Damage claimed in the text and damage visible in the photo are two different questions, and buyers assume nobody checks both. This checks both, every time, not only when someone has the patience.
- A claim that almost fits a rule but not quite. Fifteen days instead of fourteen, wording close to a known pattern but not it. Those go to a person rather than get forced into a decision either way.
- Nobody measures what got quietly approved. The number that matters is not returns processed, it is how many approved claims were actually abuse and how many refused ones were actually honest — both measurable if someone spot-checks the batch.
What I would build, and in what order
- The rule set, written down first. The same discipline as the rest of my systems: a rule that is not written down does not get to apply itself. This is the slow, unglamorous part, and it is where most of the value is.
- The second check before a refusal goes out. Kept deterministic on purpose, not a second model marking the first model's homework — that is where the check I already run leaked, before it was rebuilt as a plain filter.
- A named queue for the near-misses. A short list of situations where it stops and hands the claim to a person, with the pattern it noticed attached, and someone who owns that queue.
- The two numbers, from day one. Refusals a person overturns, and abuse that gets past it — both measured before and after, so the thing gets judged rather than admired.
Where the decision should stop, in your own words
This list is the actual deliverable, and it is written with you before anything is built. The version running in my own store today:
- Approve without collecting the goods — never. Every claim ends refused, or approved and collected; there is no state in between.
- More than fourteen days between delivery and the claim — refuse, with the date attached, unless a person overrides it.
- Wording that matches a written abuse pattern — refuse, with the specific pattern named, not just 'suspicious'.
- Anything that fits neither rule — approve and collect, which is the default, and correct roughly nine times in ten.
You don't need this if
- You process under about a hundred returns a month. Read them yourself — that is the honest answer, not a workaround.
- Your rules live in someone's head and change with their mood. Write them down first — that alone will stop some of the abuse.
- Nobody will actually open the morning batch. Then all this buys you is a queue nobody reads.
What actually gets built
Open the parts list — 10 steps, and which of them already run
Not a drawing of a product. This is the shape of the system for this job, and what each part is made of. Pick a situation and the path through it lights up.
The claim arrives
- The claim arrivesphoto, note, order numberWhatever the buyer already sends — the photo, the free-text reason, the order it belongs to. Nothing new for them to fill in.
- Matched to its orderone record, not fourThe claim, the order and the buyer's history pulled into one record, refused at the door if any of it does not match what is written down.Working today →
It reads what happened
- The wording is readworn, wrong item, repeat addressThe buyer's own words checked against the patterns that mean abuse — worn-and-returned, a damage story the photo does not support, the wrong item back, more than one claim from the same address.Working today →
The rule it applies
- Checked against your written rulesthe same way every timeYour own rules, written down once and applied the same way to the first claim of the month and the last.Working today →
- A second check before it shipsone pass proposes, one confirmsThe same shape as the reply check that already runs on the customer-chat side: a separate pass has to agree before a refusal goes out, kept as a plain rule rather than a second opinion from the same model.Working today →
What happens next
- Honest ones through fastapprove and collectApproved and collected in the same run — never approved without the goods coming back.
- Abuse queued with a reasonthe rule it broke, namedA refusal with the specific rule it broke attached, not a bare 'no'.
- One batch each morningsign, don't sortEvery decision of the day in one list, for a person to sign or overrule — nothing goes out on its own.Working today →
Someone is watching it
- Someone notices if it stopsa silent queue backs up fastIf the queue stops moving overnight, nobody notices until the backlog is a week deep — the watchdog that already checks every system of mine on a schedule catches that.Working today →
- One line in the morningapproved, refused, flaggedHow many approved, how many refused, how many flagged as a pattern, and why — posted where the team already reads its morning brief.Working today →
Follow a situation
Tap one to light up the path. Tap it again to see all of it.
7 of the 10 parts here are already running in my own businesses every day — they come from 5 of the thirteen systems of mine in daily use, and each box says which. The rest is the work: your rules, your marketplaces, and what a refusal is allowed to say.
The parts of this already running in my own store
- Returns & defects handler — the closest thing to this already running: every claim in my own store sorted by written rules the moment it lands, one batch handed over each morning to sign.
- Customer-chat assistant — where the second, independent check before anything reaches a customer was proven first, and why it stayed a plain deterministic filter.
- Data platform — the rules living as written contracts, so a definition nobody wrote down is refused at the door instead of silently applied.
Honest answers
How much does it cost?
€4,800 to €8,300 as a one-off build, higher with several marketplaces or a returns policy nobody has written down yet. A quarter is due at the start and is the only money at risk under the two-week promise; nothing else until the first real batch is judged. The first hour, to work out whether it is worth it at all, is free.
Is it worth it under 100 returns a month?
No. Read them yourself — at that volume a person going through the pile by hand is cheaper and just as accurate. The point of this is applying one rule to thousands of claims the same way, and under a hundred a month there aren't thousands.
What counts as return abuse?
A worn item sent back as new, a damage claim the photo doesn't support, the wrong item in the box, or a run of claims from the same address inside one quarter. The rule looks at the pattern and the wording, not a single claim judged in isolation.
Does it refund people automatically?
No. It sorts every claim against your rules and hands you one batch to sign — an approval still means approve-and-collect, never a refund issued without the goods coming back. That prohibition is written into the rule set, not left to a prompt.
How does it tell an honest return from abuse?
In my own store the default is approve-and-collect, correct roughly nine times in ten; a refusal needs a reason — too long since delivery, or wording that matches a known pattern. Your own version of those two rules replaces mine once we write them down together.
What happens to the honest returns?
They go through the same run, approved and collected without waiting for someone free to open the ticket. An ordinary return should never take longer just because a manager is busy arguing about an unusual one.
What already exists and what gets built?
The two hard parts already run: sorting a claim against a written rule and reading the wording for abuse patterns, live in my own returns handler, and the second, independent check before a decision ships, live on the customer-chat side. What gets built for you is wiring it to your own rules, your own marketplaces and your own order data. Writing the rules down is the part that takes the time, not the code.
Send me a week of your own returns
Real claims, including the ones you argued about internally. I will mark which the rule would have caught, which it would have waved through, and which need a human every time. You see that split in the first hour, which is free, before you've spent anything at all.
Book that hour →