Decide return eligibility against the policy version in force, refund to the original tender inside the deadline the payment type sets, and route exceptions to the returns adjudicator rather than deciding them.
Take in the return request, the order, its tender split and the live policy version from supported returns.
02
Resolve which regime governs.
Reason
03
Check eligibility under that regime, and stamp the policy version it was decided against.
04
Read the refund deadline the payment type sets and the refund form the rule permits.
05
Bind the decision to the order facts it rested on and to the clock it started.
Decide
06
Flag warranty claims, regulated goods, filed disputes and anything above the ceiling.
07
Hold those for the Returns & Claims Adjudicator instead of deciding them.
Out
08
Keep the decision, its evidence, the adjudicator's outcome and the disbursement together.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
The agent decides eligibility against the published policy; the adjudicator holds the exceptions and the money, and a rule-mandated refund is released on the merchant's compliance template.
Example workflow
One return, request to refund
AgentHuman
1Return request receivedReturns portal, helpdesk, marketplace or carrier drop-off
2Record assembledOrder lines, shipment state, tender split, prior refunds and the live policy version
3Eligibility decidedThe governing regime, the outcome, the clock start and confidence
4Policy checks runPolicy-version checks, tender checks, ceiling and hold checks and confidence threshold
No human action required
Stages 1 to 4 run unaided and no money has moved — the adjudicator's lane stays empty until the confidence gate.
5DecisionSplits on the eligibility gate
Clear on policy
Follows the pre-authorised path.
Policy-ambiguous
Goes to the adjudicator first.
Returns adjudicator
The decision is held with its regime, its evidence and the confidence.
Approve · Amend · Refer to compliance
Approved — refund released▼
6Returns and payment systems updatedOnly where write access and approval policy allow it
7Result evaluatedRefund correctness against the ledger, deadline adherence, overturns and reopened returns
Corrections
Every adjudicator overturn is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Denying a refund the Mail Order Rule requires.
Deciding a warranty claim or the remedy it earns.
Refunding to anything other than the original tender.
Refunds above the ceiling, or to a recently changed payee.
Automation boundaryAgent acts unaided
✓Check eligibility against the current published policy and cite.
✓Generate a prepaid label for a non-regulated, in-window.
✓Report where an issued refund sits in the payment.
✓Release a pre-authorised refund at the original tender and amount.
Any write happens inside the boundaries agreed at implementation, never ahead of the adjudicator's approval.
Touching an order carrying a filed dispute or a regulator contact.
Recovering or clawing back a refund that has already been paid.
Labels for hazmat or regulated goods, and recalled-item returns.
Netting a restocking, inspection or processing deduction.
Example output
One eligibility decision, annotated
Every decision carries the policy version and the order facts it was made on.
Eligibility output · single returnIllustrative example
Return
Decision
Refund form
Governing regime
Confidence
Clock start
Never-shipped line
Order cancelled for non-shipment, so a refund is owed regardless of the return window
Original tender
Mail Order Rule
89%
Cancellation, timestamped
As receivedTaken from the order, the tender record and the published policy — nothing on this side is inferred.
Evidence usedShipment state per lineTender split on the orderPublished policy version
Why this outcomeThe goods never shipped, so the rule's clock governs and a person still decides.
ActionApproveAmendRefer to compliance
What the score decidesBelow the configured threshold the decision waits on the adjudicator.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every returnFrom the order and its tender
03Eligibility
Decide against the published policy
Read the order, the tender split and the policy version that was in force when it was placed.
01Approved path
Close the return, not the ticket
Straightforward in-window returns are decided and labelled without a queue.
02Human review
Put the hard ones in front of a person
Rule-mandated refunds, warranty claims and disputed orders are held, so the adjudicator sees those and little else.
04Build an evidence trail
Each decision keeps the policy it applied and the evidence behind it.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Returns managementLoop Returns Happy Returns
Payments and refund railsStripe Adyen
BNPL and alternative tenderKlarna Affirm
Agent
Returns & refund handling
Reads the order Decides eligibility Holds exceptions
Disputes and dispositionSignifyd · Riskified Optoro · Narvar Returns
Read the refund-defect rate as a lift against the all-return baseline and the pattern shows: a few cohorts absorb most of the wrong amounts Nestack reports it by slice rather than in aggregate..
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Never shipped, split tender or BNPL
8.0%
3.5×
Review
Warranty defects, window closed
6.4%
2.8×
Review
Subscription and auto-renewal
3.2%
1.4×
Watch
In window, original tender
1.6%
0.7×
Normal
Bar: refund-defect lift vs. the all-return baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
The suite is longer at the end of it
A cycle is done when the failure has become a test the next release has to survive.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Refund defects concentrate in one return reason.
02Diagnose
The adjudicator works back through the returns and the policy versions behind them.
03Improve
Version-stamp the change and attach the records that exposed it.
04Verify
The affected cases run again, and a fail stops the release.
05Learn
It becomes a standing test, and the returns policy changes with it.
Learn → DetectThe return edge. Whatever is detected next is measured against a longer suite.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, eligibility workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Returns workflow discovery and boundary definition.
02Returns and policy-source assessment.
03Policy-version, regime and ceiling mapping and rule mapping.
04Order, tender and returns ingestion.
05Eligibility logic and evidence binding.
06Confidence scoring and adjudicator routing.
07Adjudicator review workflow.
08Returns-platform and payment integration.
09Eligibility regression cases.
10Guardrails and refund controls.
11Decision-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne policy, one marketProductionProduction return volumeAdvancedMultiple markets / tenders
Introduced at Pilot
Eligibility against your policy✓✓✓
Adjudicator approval✓✓✓
Eligibility baseline✓✓✓
Introduced at Production
Reporting by return reason—✓✓
Adjudication workflow in your systems—✓✓
Approved refund write-back—✓✓
Returns-platform integration—✓✓
Introduced at Advanced
Multi-market policy sets——✓
Multi-stage refund approvals——✓
High return volume——✓
Enterprise refund controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your published returns policy and its versions→Policy-version, regime and clock mappingWeek 1
02Representative closed returns→Eligibility baseline, evidence binding and deadline rulesWeek 2
03Your refund ceilings and tender rules→Refund-ceiling mapping and automation-boundary definitionWeek 1
04Access to relevant APIs, feeds or exports→Returns, commerce and payment assessment, then integration setupWeek 2
05Returns that should not have been approved→Eligibility cases and failure-mode testingWeek 4
06What must clear before a refund is issued→Threshold logic, refund routing and approval controlsWeek 3
07A named adjudicator to approve refunds→Adjudicator review workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Phases are drawn over the weeks they actually occupy, which is why week 5 doubles up rather than padding.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Returns workflow discovery, policy mapping and the automation boundaryW2Policy and payment sources in place, then a baselineW3Eligibility logic, confidence scoring and refund controlsW4Eligibility cases and refund guardrailsW5Payment integration, pilot returns and targeted correctionsW6One returns cycle run under the returns manager, then handover
Reading the bandBars are drawn from the workstream list, not rounded to fit. Week 5 genuinely carries two phases.
At the end of W6The last checks clear on real returns and monitoring moves to Agent Care.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Retail AI agent
Build a returns agent around the deadlines you already owe.
Show us your returns policy, your tender mix and who signs off on money. Refund timing and refund form are set by the rule and the payment type, not by preference, so we map what the agent may decide and what your adjudicator keeps.
