Returns & Refunds
A message lands in your support inbox: "I'd like to send this back." This agent finds the order, reads the delivery date off the carrier scan, counts your return window from the day the box actually arrived, checks the line items against your carve-outs, and drafts the resolution — refund, store credit, or exchange, with the restocking fee shown as arithmetic. It never issues the refund. That click stays with a person.
Yours outright — no required subscription.
Every agent is built for your business — your systems, your approval chain, your way of working. We scope it on the call.
If this sounds too technical, don't worry. We take care of everything for you.
- Private VPS deployment. This agent runs on a server that belongs to you, not a shared cloud tenant. Your order history and your customers' messages stay on your box.
- A technician agent alongside it. Every hire ships as a pair: the Returns & Refunds Agent working the queue, and a VPS-technician agent on the same box keeping it patched, backed up, and monitored. You're not hiring one thing, you're hiring a small team of two.
- Your policy, written down. Setup starts by getting the real policy out of people's heads and into rules the agent can apply — the window, the carve-outs, who eats the return label, when a restocking fee applies. That work is the difference between an agent that helps and one that flags everything.
- Communication channel connection. Wired into wherever return requests actually land — a shared mailbox, your help desk, your return form — so nothing has to be forwarded to it by hand.
- An exceptions queue. Anything past the window, final sale, tags missing, or otherwise a judgment call goes to a separate queue with the facts assembled and no decision made. Read weekly, it's a map of the gap between the policy you wrote and the one you actually run.
- Security hardening. Private VPN, firewall, and encryption configured on your server before it reads a single customer message.
- A live walkthrough, then 14 days of priority support — we show you exactly what both agents do and where this one is supposed to stop, then stay close through your first two weeks of real return volume. You own everything: the server, the agent, the code it runs on.
Not sure it fits? Check fit in 90 seconds in the free assessment chat.
Who this is for
- You're a DTC brand doing a few hundred orders a day with two or three people on support, and return requests arrive in a shared inbox and a web form — so whoever opens it first decides what your policy is that morning.
- Your written policy says 30 days from delivery, but there are five unwritten carve-outs — the wholesale account you always comp, the VIP with nine orders, anything that arrived broken — and only your ops manager knows all five.
- You have three or four people with refund permission, and when you find a refund on a final-sale item three weeks later, there's no record of who approved it or what they were told at the time.
- You watch returns triple for six weeks after the holidays or a big promo, and the person answering them is a seasonal hire who has read the policy page once.
How it earns trust
The failure mode of AI in returns isn't that it gets one wrong — a tired human on a Monday gets them wrong too. It's that a wrong answer looks exactly as certain as a right one, and nobody can reconstruct it later. This agent makes the opposite bet: every request leaves a record you can open months from now and read.
The order match, shown not assumed
Every draft carries which order it matched and the evidence it used — order number, email match, last four of the card. A wrong match is the most common way this goes bad, so it's the first thing on the page instead of something you find out about later.
The window math, shown as arithmetic
The delivery date it counted from, which carrier scan that date came from, the clause it applied, and the restocking fee worked out step by step. When a customer says your team counted from the wrong day, you can see the day it counted from and where it got it.
A name on every decision
Approved or overridden, the record keeps who did it and what they were looking at. Months later, a refund is traceable to a person and a reason, not just to a number in your payouts.
None of that makes the agent right more often; it makes a wrong answer catchable at the reason instead of only at the number.
Pairs well with
These share a workflow with this role. Tick any to add them to your setup.
Refunds are the one thing I want to see before it goes out the door. Does it ever move money?
No. It does not issue refunds, does not touch your payment processor, and gets no refund permission of its own. Every resolution ends as a draft — amount, fee, reason, policy clause — waiting on a person. If you set an auto-approve rule for in-policy, low-dollar cases, you write that envelope; the agent can never widen it and never decides on its own that a case belongs inside it.
I don't want a bot telling my customers no.
It won't. A denial always goes out over a human name. The agent can draft the no, cite the clause, and lay out the facts, but sending it is a person's job. Same for anything with heat in it — a customer on their third email about a broken order should hear from someone who read the thread.
Every return gets a different answer depending on who's on the inbox that day. How does this fix that?
By making one pass over every request the same way: find the order, take the delivery date from the carrier scan, count the window from that date, check the line items against your carve-outs, propose a resolution. The consistency comes from writing the policy down. In month one it will flag things you'd have approved in four seconds, because every carve-out still living in someone's head reads to it as a plain exception. That friction is real, and it goes away as you write those rules down.
I found out three weeks later that we refunded a final-sale item. Would this have caught it?
It would have flagged it rather than approved it — final sale goes to the exceptions queue with the facts assembled. Whether the refund still went out is up to whoever approved it, but you'd have their name on it, the clause they overrode, and the reason. We also set up a reconciliation between refunds issued in your store and approved drafts; a refund with no matching draft means someone went around the agent, which is itself worth seeing.
How wrong can it be, and how would I know?
The most common bad draft is a confident wrong order match — a customer writes with no order number, from a spouse's email, describing "the blue one." That's why the match and the evidence behind it sit on the face of every draft, not buried. Bad carrier data is the other one: given a missing or late delivery scan, it will count your window correctly from the wrong day. And it cannot see the item. "It arrived damaged" and "I wore it to a wedding" look identical in an inbox; it can ask for photos or hold for warehouse inspection, but it cannot judge condition or tell you a return is fraudulent.
What's covered under the $1,997 setup, and what isn't?
One company, one system of record, one approval chain — flat, one time. Your existing approval chain stays yours; the agent adds a step before a refund goes out, it never removes one, and it doesn't change who holds refund permission. Multiple storefronts or genuinely different return policies per brand get scoped on the free 15-minute call. Typically about seven days from kickoff to it working real requests.
Hiring more than one? A department on tap — the subscription puts a build team behind every request, agent after agent.