Customer Return & Refund Orchestration
A customer opens a return. Resolving it well means confirming the request, restocking inventory correctly, issuing the refund, and keeping the customer's record current — today spread across a ticket, the ERP, and a payment step that's easy to delay.
The Goal
What you'd actually type to Dendr AI
Natural-language input
“Process the return for order #58291 and refund the customer.”
The Ecosystem
Agents & MCP servers orchestrated
Support ticketing
Zendesk
Illustrative vendor
Captures and tracks the return request.
ERP / inventory
Oracle ERP
Illustrative vendor
Restocks the returned item and updates inventory.
Payment
Payment / refund rails
MCP server
Issues the refund to the original payment method.
CRM
Salesforce
Illustrative vendor
Updates the customer's order and service history.
Communication
Graph / SMTP MCP
Confirms the refund to the customer.
How It Works
How the Dynamic Planner builds the chain
The Intent Engine structures the goal above into an intent graph. The Dynamic Planner grounds each step against the live Agent Capability Graph and assembles the coordination path at request time — no one pre-authored this exact sequence.
Confirm the return request and reason code in Zendesk.
Update inventory in Oracle ERP once the returned item is confirmed received.
Issue the refund via the payment agent to the customer's original payment method.
Update the customer's order and service history in Salesforce.
Email the customer confirming the refund and amount.
Semantic Routing in Action
The right agent, every time
support.ticket.return matches Zendesk exactly, kept distinct from the general ticketing.create tag used in the IT-operations use cases via domain filtering.
payment.refund.issue is grounded specifically to refund-capable payment agents — not every registered payment agent supports refunds, so the router filters out collection-only agents first.
crm.record.update matches Salesforce; if a separate loyalty-program agent were registered with an overlapping tag, domain filtering on “retail-customer” keeps the two from colliding.
Approve Once. Use Anytime.
Chain-level authorization, reused on every run
- The customer service lead approves the “standard return and refund” pattern once, covering ticket confirmation, restock, refund, and record update as a single authorized chain.
- Every return that fits standard policy (within the return window, no fraud flag) runs automatically under that same approval — the team isn't re-approving refunds one at a time.
- Returns that fall outside standard policy are a structurally different, separately tagged and approved pattern, so edge cases never quietly ride on the standard authorization.
Dynamic Replanning & Resilience
What happens when reality doesn't match the happy path
If the item hasn't been physically received yet, the planner holds the refund step until Oracle ERP confirms restock, rather than refunding on the ticket alone.
If the refund fails (e.g., expired card), the planner routes to a manual refund-method-update step and notifies the customer rather than leaving the return in limbo.
Business Outcome
What the retailer gets
Faster refunds without waiting on manual coordination between support, warehouse, and finance.
Inventory and financial records stay accurate because restock and refund are sequenced, not assumed.
A consistent customer experience regardless of which support agent opened the original ticket.
Related
The matched pair
See how retailers handle returns without the back-and-forth.
Get a demo and see the return-and-refund chain run against your own registered agents.
Zendesk, Oracle, and Salesforce are referenced above as illustrative, recognizable examples of the enterprise systems Dendr AI can orchestrate through A2A, MCP, vendor adapters, or OpenAPI manifests. These are reference architectures, not case studies of named customers, and do not imply a partnership, integration certification, or endorsement by those vendors.