The refund process: request to resolution

Robin: OK so I'm just going to record this, if that's alright. Walk me through the refund process end to end, like you'd explain it to a new hire. Whatever level of detail you think is useful.

Priya: Yeah, no problem. So, refunds. I do this every day, I've been on the team three years now, so — ask whatever. Where do you want me to start?

Robin: Start at the very beginning. How does a refund request even reach you?

Priya: Right, so intake. We have four channels basically. Phone — that's still about a third of our volume honestly, people love to call. Email comes into a shared inbox that auto-tickets into Zendesk. Web form on the support site, that's probably the biggest channel now, maybe forty percent. And the chatbot, which kicks structured refund requests over to us when it can't resolve them itself. So phone, email, web, chatbot. Four channels.

Robin: Got it. And what gets captured at intake?

Priya: The standard stuff. Reason category — defective, not-as-described, changed-mind, that kind of thing. Refund amount, account info, the original transaction reference. The system pulls a lot of that automatically once you key in the order number. Oh, and there's a fraud check that runs in the background — it just kicks the ticket out automatically if the account's been flagged. We don't really touch those, they go to the fraud team.

Robin: OK. So fraud check happens, ticket lands with CS. Then what?

Priya: Then we review it. So I — or whoever's on the queue — pulls up the ticket, checks eligibility first. Is it within the return window, is it an eligible product, that sort of thing. Some categories are non-refundable, like digital downloads after activation, gift cards, certain promo items. If it fails eligibility we close it out with a templated response.

Robin: And if it passes?

Priya: If it passes, we categorize it properly — defective, not-as-described, chargeback risk, goodwill, whatever fits. Categorization matters because it routes differently and it feeds the metrics. Then we make the call.

Robin: The approval call?

Priya: Yeah. So the rule is, anything under fifty bucks we auto-approve at the CS level. I just click approve, it goes through. We get about two hundred refund requests a week and honestly the vast majority are under fifty — somebody's coffee maker accessory broke, whatever — so we move through those really fast. The whole point of the threshold is to not bottleneck the manager on tiny stuff.

Robin: And above fifty?

Priya: Above fifty it routes to the manager for review. They look at it, approve or deny. We have a twenty-four hour SLA on all of it, so even the manager queue has to clear within a day. That's a hard SLA, finance tracks it, we get dinged if we miss it. Honestly the holiday spike in December is brutal for that — we had like four hundred a week last December and I was here until eight every night, but we hit the SLA.

Robin: OK. What happens after approval?

Priya: Approval triggers the refund. It goes to the payment processor — Stripe for cards, PayPal handles its own, ACH for bank transfers, that whole thing. Processor confirms back to us, usually within a few minutes for cards, can be a couple days for ACH. Customer gets an automated email saying the refund's been issued, with the expected timing on their side. That's like five to ten business days depending on their bank.

Robin: And denials?

Priya: Denials, the manager writes the denial email and sends it directly. They have templates obviously, but they personalize it depending on the situation. We try to be human about it, especially if the customer's been with us a while. Then the ticket gets closed.

Robin: That's the manager sending it, not CS?

Priya: Yeah, manager sends it. They made the call so they own the communication. It's been that way the whole time I've been here.

Robin: Got it. Anything after close?

Priya: After close, the system auto-fires a CSAT survey. That's the little one-to-five thumbs thing. Our team CSAT is sitting around 4.3 right now which is, I mean, given that half these people are upset to begin with, that's pretty good. We also get a weekly metrics report — volume, approval rate, average handle time, that kind of thing — that goes to finance and to our director.

Robin: And if a customer pushes back on a denial?

Priya: I mean, sometimes they reply to the email and argue. We'll re-read the ticket, but if the denial was correct it stays denied. Once the case is closed it's closed. People move on.

Robin: No formal appeal process?

Priya: Not really, no. I mean, technically anyone can escalate to a manager but the manager already made the call so. It just kind of ends there.

Robin: OK.

Priya: Oh, one thing I should mention — chargebacks are weird. If somebody bypasses us and just disputes with their bank, that whole flow goes to a different team, the disputes team. We loop in if they need order context but we don't own the response. Just so you know that's carved out.

Robin: Noted. Anything else top of mind?

Priya: Um. I think that's most of it. Like I said — intake, fraud check, CS review, eligibility, categorize, auto-approve under fifty or route to manager above fifty, twenty-four hour SLA, payment processor, customer notified, close, CSAT. That's the loop. We've gotten really efficient at it, honestly. The new ticketing macros we rolled out maybe six months ago shaved like twenty percent off our handle time.

Robin: OK, got it. That's super helpful.