Returns and exchanges intake

A return request sounds simple until the business has to identify the order, confirm the item, apply the current policy, understand why the customer is sending it back, and decide whether the request needs review. A caller may also describe damage, a missing part, a gift, or a purchase that the order system cannot find. Treating every case as a routine return creates bad promises; sending every case to a general queue wastes staff time.

A returns and exchanges line gives the request a consistent first pass. The AI phone agent collects the required details, checks only the policy and order information exposed by approved systems, and records the requested outcome. It can complete intake and route the case, but it should not invent eligibility or approve money movement. For industry-specific operating context, see ecommerce support.

A concrete return call

Consider a customer who wants a different size.

Agent: I can collect your exchange request and check the information available in our order system. What is the order number and the item you want to exchange?

Caller: I have the order number. The jacket is too small, and I want the next size up.

Agent: The connected system found the jacket. Before I continue, please confirm the verification detail required by the store.

Caller: Done. I also removed the tags before I realized it did not fit.

Agent: The standard exchange guidance requires staff review when the tags have been removed. I will record the size you received, the size you want, and what you told me about the tags. I can try the returns team now or submit the request for follow-up. Which do you prefer?

The agent does not stretch the standard policy to fit the call. It finds the exception, preserves the customer’s own description, and moves the decision to someone with authority. A separate order status line can handle callers who only want shipping information.

How to configure it on ThunderPhone

Start with a prompt that separates fact collection from approval. Define:

• the order and verification fields the business requires before disclosing details;
• the item, quantity, reason, condition, purchase channel, and requested resolution to collect;
• the exact policy language the agent may explain;
• exception triggers such as failed verification, missing orders, damage, missing parts, gifts, expired windows, removed tags, repeated claims, or an angry caller; and
• the allowed outcomes: submit for review, provide an approved next step, or transfer to staff.

Attach the current returns policy through ThunderPhone’s document library. It accepts text, Markdown, CSV, PDF, and DOCX files, supports per-agent document scoping, and provides built-in mid-call search. Uploading a document does not attach it automatically, so select the approved material for this agent and remove obsolete versions. Use a knowledge base for stable policy explanations, not for live order facts.

Expose live order lookup and request submission through a narrow REST action or an approved remote Zapier MCP server. Remote MCP servers are added by URL, synchronized for tool discovery, and attached to the agent; static HTTP headers are supported. Limit the available fields and actions to what the intake flow needs. A returns line does not need unrestricted access to customer accounts or refund controls.

If the business manages cases in HubSpot or Salesforce, send the captured request there. A custom workflow can use REST and subscribed webhooks. ThunderPhone supports multiple webhook endpoints with separate secrets and event subscriptions, HMAC-SHA256 request signatures, and exponential-backoff retries for non-blocking deliveries. Store the verification result, item, caller-stated condition, requested outcome, policy exception, transfer result, and final disposition.

Connect an appropriate production number for live calls. Inbound demo U.S. numbers are available for testing, but they are inbound-only and not intended for production. When an exception needs a person, an eligible production number can use attended warm transfer: the caller waits while the agent privately briefs the recipient, and the agent returns with the outcome if the recipient declines, does not answer, or reaches voicemail. Demo numbers and browser calls are limited to cold transfer.

Before launch, test ordinary exchanges, unrecognized orders, failed verification, damaged items, policy exceptions, duplicate requests, and an unavailable returns team. Reusable scenarios and graded call logs can check whether the agent avoids promises and follows the correct human handoff path.

What to measure

Track measures that show whether the intake is accurate and useful:

• required-field completion;
• successful order lookup and verification;
• standard requests versus policy exceptions;
• first-time routing to the correct destination;
• transfer acceptance and fallback completion;
• repeat contacts for the same request; and
• reviewed calls containing an unsupported eligibility, refund, or replacement statement.

Do not treat a low transfer rate as the goal by itself. A damaged product, suspected abuse, or disputed purchase may be successful precisely because the agent escalated it.

Honest limits

ThunderPhone cannot correct stale order data, inspect an item, determine whether damage occurred before delivery, or prove a caller’s identity from a stated order number alone. The agent should not issue refunds, capture payment, create shipping promises, or waive policy unless the business has built an explicitly approved action with the required controls. Staff should handle fraud concerns, charge disputes, unusual accommodations, repeated claims, and ambiguous policy cases.

Keep product-defect documentation in warranty claim intake when it follows a different policy and ownership path.

Create your ThunderPhone account to configure and test returns and exchanges intake.