Main site

Retail AI agent · Returns and refunds

Returns & Refund AI Agent

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.

Typical delivery
4–6 weeks
Deployment
Your stack
Adjudicator
Original tender
After launch
Agent Care

What this agent does

Eligibility first, disbursement second

In

  1. 01

    Take in the return request, the order, its tender split and the live policy version from supported returns.

  2. 02

    Resolve which regime governs.

Reason

  1. 03

    Check eligibility under that regime, and stamp the policy version it was decided against.

  2. 04

    Read the refund deadline the payment type sets and the refund form the rule permits.

  3. 05

    Bind the decision to the order facts it rested on and to the clock it started.

Decide

  1. 06

    Flag warranty claims, regulated goods, filed disputes and anything above the ceiling.

  2. 07

    Hold those for the Returns & Claims Adjudicator instead of deciding them.

Out

  1. 08

    Keep the decision, its evidence, the adjudicator's outcome and the disbursement together.

  2. 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

  1. 1Return request receivedReturns portal, helpdesk, marketplace or carrier drop-off
  2. 2Record assembledOrder lines, shipment state, tender split, prior refunds and the live policy version
  3. 3Eligibility decidedThe governing regime, the outcome, the clock start and confidence
  4. 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

  1. 6Returns and payment systems updatedOnly where write access and approval policy allow it
  2. 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 required

8 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 boundary

    Agent 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 return

Illustrative example
Return
Never-shipped line
Decision
Order cancelled for non-shipment, so a refund is owed regardless of the return window
Refund form
Original tender
Governing regime
Mail Order Rule
Confidence
89%
Clock start
Cancellation, timestamped

As received

Taken from the order, the tender record and the published policy — nothing on this side is inferred.

Evidence used

  • Shipment state per line
  • Tender split on the order
  • Published policy version

Why this outcome

The goods never shipped, so the rule's clock governs and a person still decides.

What the score decides

Below the configured threshold the decision waits on the adjudicator.

Action

ApproveAmendRefer to compliance

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every return

From 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.

04

Build 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 management

    • Loop Returns
    • Happy Returns

  • Payments and refund rails

    • Stripe
    • Adyen

  • BNPL and alternative tender

    • Klarna
    • Affirm

Agent

Returns & refund handling

  • Reads the order
  • Decides eligibility
  • Holds exceptions

  • Disputes and disposition

    • Signifyd
    • Riskified
    • Optoro
    • Narvar Returns

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the refund

The layers nest. What each one misses is named in the map below it.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeRestrict the agent to eligibility opinions when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, policy-version and ceiling changes.Track
L4TraceabilityRecord the regime, the evidence, the decision, the approver and the disbursement.Record
L3Adjudicator approvalHold flagged returns for the named adjudicator; it governs release, not whether an approved decision was right.Gate
L2Policy guardrailsTest decisions against the published policy version, tender rules and refund ceilings; a failure returns the decision.Restrict
L1Confidence thresholdsRoute low-confidence decisions to the adjudicator before any disbursement.Require review
Model coreDecision produced — governing regime, outcome, clock start and confidence
L1 – L2
Test whether a decision may stand
L3
Puts the release in the adjudicator's hands
L4 – L5
Show what policy applied and when it changed
L6
Reverts to proposal-only when signals degrade

How Nestack evaluates it

Evaluate the whole return — not only the amount that was paid.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the outcome the customer is given

  1. E1Final-output evaluationWas the right regime applied, at the right amount, to the right tender?
  2. E2Step-level evaluationDid the agent use the order, the tender split and the policy version in force?
  3. E3Tool evaluationDid it read and write the correct return and the correct payment record?
  4. E4Confidence calibrationDo low-confidence decisions actually attract more overturns?
  5. E5Slice evaluationHow does performance change across specific return reasons?
  6. E6Business outcomeHow many refunds were reissued, reversed or paid outside their deadline?

Floor — what the customer actually experiences

Failure modes

Where each failure originates in the agent

Seven modes, placed at the stage each originates.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • RT-03

      Cached order total

      A total predating a partial cancellation is refunded in full.

    Stage gathers

    Order lines, tender records, with the source each came from

  2. 02 · Reasoning

    2 modes

    • RT-04

      Wrong regime applied

      A return window is applied to an order that was never shipped.

    • RT-06

      Warranty denied as a return

      A defect claim is closed against the policy window instead.

    Stage proposes

    The regime, the outcome and confidence

  3. 03 · Tool / write

    2 modes

    • RT-02

      Duplicate refund

      A refund call times out and is retried with no idempotency key.

    • RT-05

      Ledger and provider diverge

      The order is marked refunded after a call that actually failed.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • RT-01

      Issuer timeline promised

      The customer is told when their bank will post the credit.

    Stage returns

    The decision and the amount the customer receives

  5. 05 · Change / Version

    1 mode

    • RT-07

      Superseded policy cited

      A policy update reaches the storefront but not the agent's index.

    Stage tracks

    Model, prompt, policy versions and ceiling config

  • Sev-1 · a held act performed by the agent
  • Sev-2 · a wrong refund reaches the customer
  • Sev-3 · source degrades
See the complete Retail failure-mode catalogue

Affected slices

The average return hides the ones that hurt

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 aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Never shipped, split tender or BNPL8.0%3.5×Review
Warranty defects, window closed6.4%2.8×Review
Subscription and auto-renewal3.2%1.4×Watch
In window, original tender1.6%0.7×Normal

Bar: refund-defect lift vs. the all-return baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 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 stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Refund defects concentrate in one return reason.

  2. 02

    Diagnose

    The adjudicator works back through the returns and the policy versions behind them.

  3. 03

    Improve

    Version-stamp the change and attach the records that exposed it.

  4. 04

    Verify

    The affected cases run again, and a fail stops the release.

  5. 05

    Learn

    It becomes a standing test, and the returns policy changes with it.

  6. Learn → Detect

    The 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.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Returns workflow discovery and boundary definition.Week 1
  2. 02Returns and policy-source assessment.Week 1, Week 2
  3. 03Policy-version, regime and ceiling mapping and rule mapping.Week 1, Week 2
  4. 04Order, tender and returns ingestion.Week 2
  5. 05Eligibility logic and evidence binding.Week 2, Week 3
  6. 06Confidence scoring and adjudicator routing.Week 3
  7. 07Adjudicator review workflow.Week 3, Week 4
  8. 08Returns-platform and payment integration.Week 5
  9. 09Eligibility regression cases.Week 4, Week 5
  10. 10Guardrails and refund controls.Week 4
  11. 11Decision-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final 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 price
Confirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.
Separate from build
Build 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.

  1. 01Your published returns policy and its versions

    Policy-version, regime and clock mapping

    Week 1

  2. 02Representative closed returns

    Eligibility baseline, evidence binding and deadline rules

    Week 2

  3. 03Your refund ceilings and tender rules

    Refund-ceiling mapping and automation-boundary definition

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Returns, commerce and payment assessment, then integration setup

    Week 2

  5. 05Returns that should not have been approved

    Eligibility cases and failure-mode testing

    Week 4

  6. 06What must clear before a refund is issued

    Threshold logic, refund routing and approval controls

    Week 3

  7. 07A named adjudicator to approve refunds

    Adjudicator review workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, 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.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Returns workflow discovery, policy mapping and the automation boundary

W2Policy and payment sources in place, then a baseline

W3Eligibility logic, confidence scoring and refund controls

W4Eligibility cases and refund guardrails

W5Payment integration, pilot returns and targeted corrections

W6One returns cycle run under the returns manager, then handover

Reading the band
Bars are drawn from the workstream list, not rounded to fit. Week 5 genuinely carries two phases.
At the end of W6
The last checks clear on real returns and monitoring moves to Agent Care.
Duration
Six-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.

Typical delivery
4–6 weeks
Deployment
Your returns stack
Adjudicator approval
Original tender
After launch
Agent Care available

Nestack Agents · Returns and refunds

AGT-RT-02 · Agent Care available after launch

Build a returns agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your returns

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.