How to Build a Returns Processing Agent

Returns are where commerce operations lose margin and customers lose patience, usually at the same time. The policy has edge cases nobody decided, the answers customers receive vary by whoever handles the contact, and the process of getting a label and a refund takes longer than the purchase did. An agent that applies a clear policy consistently, explains its decisions, and moves quickly improves both sides of that. This guide covers building one, drawing on FISTA Solutions' AI agents delivery in commerce. It complements ai returns management and how to build an order tracking agent.

Why start with the policy?

Because the edge cases are the whole problem. A returns policy typically states a window, a condition requirement, and some exclusions, and then reality produces the return on day thirty-one, the gift with no receipt, the opened item that turned out faulty, the sale item under a policy that excludes sale items but not faulty ones, the item bought online and returned in store, and the customer who has returned eleven of their last twelve orders.

Each needs a decided answer, written as a rule, with the reason the customer will be given. Doing that work is the project's substance, and it improves human agent consistency as much as it enables automation. See how to write an ai spec.

Edge case	Needs a decided answer
Just outside the window	Discretion limit, by value or customer history
Gift without receipt	Identification path and refund method
Opened but faulty	Fault assessment route and who decides
Sale or clearance items	Whether exclusions apply to faults
Cross-channel returns	Which channel's policy governs
Missing components	Partial refund basis
High return-rate customer	Review rather than automatic refusal

How should eligibility decisions be communicated?

With the reason, the rule, and a way to dispute. A customer told the return falls outside the thirty-day window, with the purchase date and the window stated, accepts the answer far more readily than one told the return is not eligible. The dispute path matters as much: a refusal with no route forward becomes a complaint, a chargeback, or a review.

Where the rules permit discretion, such as a small overrun on the window for a good customer, the agent should apply it within defined limits rather than escalating every marginal case, because the discretion is why the limit exists.

How is abuse screened without punishing customers?

By looking at patterns over time rather than single events, and by routing flags to people rather than acting on them. Signals worth monitoring: return rate relative to order volume over a period, repeated returns of high-value items, discrepancies between the item sent and the item returned, wardrobing patterns where items return just within the window in used condition, and returns from addresses or payment instruments associated with prior abuse.

An ordinary customer with one unusual return should never see any of this. Flags go to a review queue where a person decides, because the cost of wrongly treating a good customer as an abuser exceeds the value of the return in almost every case. See ai fraud detection.

What can the agent do automatically?

Within limits: approve eligible returns, generate the return label or QR code, book a collection where the carrier supports it, issue a refund on receipt or, for trusted customers and low-value items, on dispatch, and process an exchange. Each bounded by value limits, customer history, and item category.

The limits should be explicit and reviewable. An agent that refunds any amount is a fraud target; one that refunds up to a threshold with anything above going to a person is a control.

Why offer exchange rather than refund?

Because it is frequently what the customer wants and it keeps the sale. A customer returning a size does not want their money back; they want the right size. Offering the exchange first, as a genuine choice rather than an obstacle, resolves the need and retains the revenue. The same applies to a faulty item where a replacement solves the problem.

The distinction between offering and obstructing matters. An exchange offered once, clearly, with the refund still available in one tap, is service. An exchange the customer must decline three times is a dark pattern that generates complaints and regulatory attention.

How should refund timing be communicated?

Honestly, including the parts the organisation does not control. A refund issued today may take several days to appear depending on the payment method, and a customer who is told that does not contact support on day two. Stating the expected timeframe with the reason removes a substantial share of follow-up contacts.

What should escalate?

Damaged and faulty items needing assessment, high-value returns above the limit, contested cases, anything flagged for abuse review, complaints, and cases where the customer's account differs from the system's record. Each handed to a person with the full context.

How is it evaluated?

Eligibility decision accuracy against the policy, checked by the returns team on a sample. Resolution rate without escalation. Exchange conversion where offered. Refund-to-appearance timeline accuracy. Abuse flag precision, judged by reviewers. Contact volume on returns before and after. And the commercial measure: revenue retained through exchange versus refunded.

What does the build sequence look like?

One to two weeks deciding the policy edge cases with the returns and commercial teams. One week on systems integration across order management, returns, and carrier. Two weeks on the eligibility engine with reasons and the conversation. One week on label generation, refunds within limits, and exchange offers. One week on abuse pattern detection routed to review. Then cross-channel handling.

What goes wrong?

Policies with undecided edge cases. Refusals without reasons. Abuse flags acted on automatically. Exchange offered as an obstacle. Refund timing unstated. Unlimited refund authority. And launching before the returns team agreed the discretion limits, which leaves the agent either rigid or unbounded.

How FISTA Solutions helps

FISTA Solutions builds returns agents on policy expressed as decided rules, with eligibility reasons customers accept, bounded refund and label automation, abuse patterns routed to human review, and exchange offered as a genuine choice, through AI enablement, AI agents, and forward deployed engineers working with commerce operations. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime and 47% efficiency gains where measured.

To make returns faster for customers and cheaper for operations, message FISTA on WhatsApp, or read ai returns management.