Voice agents for exchanges, cancellations and returns

Distinguish a question from a request

Identify the goal: understand a policy, start a request or follow up on an existing one. Ask one question at a time. Do not collect an order number for a general policy question.

Use current policies approved by the business. This guide specifies no legal rights, return periods or refund conditions; those contents must come from and be reviewed by the responsible team.

Query only an authorized order

To check an individual order, the agent needs a configured connection to the responsible system. That system must verify the caller’s access before supplying information. Giving an order number in conversation does not establish authorization. Agree on that procedure with the integration owner.

Collect only information required for the process. If verification fails, explain the team's channel without exposing order details. Use synthetic records before connecting real data.

Record a request without claiming approval

Fictional example: the caller confirms an exchange request. The tool returns ‘request received’, reference DEMO-42 and ‘awaiting review’. Appropriate response: ‘Your request was recorded as DEMO-42 and awaits review’. Do not claim the exchange is approved or a refund has started.

When the tool returns an error or uncertain result, invent no reference and do not repeat creation without checking duplication at the destination. Deduplication and lookup belong to the external integration.

# Requests
Distinguish policy questions, new requests and follow-up.
Explain only policies from approved sources.
Before recording, confirm the request type and required information.
After calling a tool, describe only the returned result.
A received request does not mean approval, shipment or refund.
For errors or uncertain results, explain the limit and the team's channel.

Validate outcomes and exceptions

The table below helps test how the agent explains each request stage. It is an assessment example, not a native Tigy integration. Use the names shown in your system and check whether customers can understand what was received, approved or completed.

Pilot one task first

Start with policy information or one request type. Test changed intent, missing orders, denied access, repetition and corrected numbers. Compare the conversation with the created record, not just call completion status.

Expand after confirming that the agent asks permission before recording, retains corrected information and distinguishes receipt from a decision. Measure duplicate requests and handoffs without presenting examples as proven results.

Does a recorded request establish approval or a refund?

No. “Received,” “awaiting review,” “approved” and “completed” represent different stages. Check the meanings used by the company’s system. A return request is not an approved return, and a cancellation request does not prove that money was refunded.

In a fictional example, an API returns DEMO-42 and “awaiting review”. The agent can confirm registration and reference while preserving pending review. With absent or failed returns, invent no reference; the receiver needs a strategy to discover outcomes and prevent duplication before repeating creation.

Establish which outcome the caller is requesting

Exchanging a product, canceling an order, and returning a purchase are different requests. Someone may use “cancel” when they want another size, or say “return” when they intend to stop a subscription. Before explaining conditions, identify the purchase and desired outcome. A short question such as “Would you like another item or to end this purchase?” avoids guiding the conversation through a policy that does not match the person's actual intent.

At a fictional store, a customer receives a shirt that is too small and asks to cancel. If the goal is to receive the correct size, the exchange policy may be the right source. Another customer placed an order moments ago and wants to stop shipment; order state matters in that case. A third has already received the product and wants return instructions. Their opening language may sound similar, but required information and available actions differ.

Explain general conditions before collecting individual information when that resolves the question. Someone asking “Do you offer size exchanges?” may not need to provide an identity document and address. If the caller wants to open a request for a specific purchase, collect the necessary identifier and apply the operation's authorization procedure. Access should serve the case rather than a fixed list of questions everybody must answer.

Confirm the intended outcome in everyday language before writing anything. “You want to request an exchange for a larger size” is clearer than repeating an internal category code. If intent changes during the call, update the request and check whether an action has already occurred. The integration should prevent a verbal correction from creating two incompatible requests for the same purchase. Classification is useful because it directs the correct policy and action, rather than merely assigning a label.

Separate eligibility, submission, and completion

A policy may establish that a case is eligible to request a return. That does not mean the company has received the product, completed its assessment, or issued a refund. Define the states the integration can verify and the corresponding language. “The request was recorded” describes a different action from “the return was approved.” Without this distinction, the conversation creates expectations that the operational system cannot confirm.

If shipping has started, the system may refuse cancellation and indicate another company-approved next step. The agent should explain that result without repeating the action or promising an exception. If cancellation is still possible, confirm it only after receiving that result from the system. The absence of an error message is not enough.

If the tool returns “under review,” preserve that state. Ask staff which information can be given while the customer waits and which channel supports follow-up. Mention a deadline only when it is approved and applicable. Do not turn a historical average or illustrative document example into an individual commitment. For refunds, distinguish commercial approval, execution in the relevant system, and available information about receipt, according to what the integration actually provides.

Legal and commercial rules differ by context and jurisdiction. This service should reproduce the approved policy and route questions requiring individual assessment. The agent does not need to improvise legal advice to appear thorough. If a customer disputes a rule or describes an exception the source does not cover, record the reason and provide the existing review procedure. Accurate state is a central part of service quality, particularly when the caller understandably wants a definite financial outcome.

Protect the request against repetition and changed intent

Return-related calls may repeat because a customer did not receive clear confirmation. Before creating a new request, check the existing state when that capability is available. If an open reference already covers the same desired outcome, explain how to follow it. Another call should not automatically create a second collection request or another refund commitment. Duplicate prevention needs implementation in the integration as well as guidance in the prompt.

Test a slow tool while the customer asks “have you done it yet?” The agent needs to explain whether the action is ongoing or confirmed. Repeating it immediately can create another request. Ask the integration owner to check that the system recognizes repeated attempts and lets the team discover the first result before retrying.

Also test corrections after confirmation. A customer may say “Actually, I prefer an exchange” after a return request has been submitted. The agent should not pretend the first action never happened. Check current state, explain what can be changed, and invoke a modification operation only if it exists and is permitted. Without that capability, route the case with necessary context rather than promising that staff will automatically undo the request.

During information collection, avoid questions not required at that stage. Payment details or extensive documents should not enter the conversation merely because they might help in some future case. Establish which fields identify the purchase, which explain the reason, and which belong in another channel. A process collecting fewer unnecessary details is generally easier to finish and review correctly. Keep the customer's confirmed intention distinct from earlier ideas and from actions already recorded in the external system.

Evaluate the experience through the system outcome

Measuring only whether a call ended hides important errors. A short conversation may leave the customer without a reference; a friendly one may record the wrong category; an apparently completed request may never exist in the order system. Evaluate intent identification, policy application, action confirmation, and subsequent continuity. Each stage requires different evidence, and a polished closing sentence does not prove that every stage succeeded.

Build a sample covering size exchanges, cancellations before shipment, orders already shipped, returns under review, and customers calling to follow an existing reference. Add a product with insufficient information, a corrected identifier, an unavailable lookup, and changed intent. For each situation, specify the expected final state and permitted message. These scenarios reveal whether the agent distinguishes requests and remains accurate when the desired action cannot be completed.

Compare requests requiring staff correction, duplicate records, information collected again, and repeat contacts caused by unclear explanations. Separate cases requiring inspection or a later decision: the agent should not be expected to finish an assessment beyond its scope. It can still be evaluated on accurately explaining the process and leaving a useful record for the next team. This avoids rewarding premature closure or penalizing appropriate routing.

Use failures to improve the relevant layer. If customers misunderstand confirmation, revise the wording. If requests are classified incorrectly, improve the opening question. If the system accepts incompatible actions, fix integration validation. If the policy omits a common situation, obtain a decision from its commercial owner. Service improvement then follows the store's actual process rather than simply making the agent more persistent or more confident about an answer that remains unavailable. Review both what the customer heard and what the external system recorded before declaring an exchange, cancellation, or return successful.