Product Exchange Checks: Refunds, Stock, and Customer Choice
Before an exchange, check whether the units are eligible, whether the replacement is actually available, and whether the customer chose it.
- Author
- Stacksync · App tips writer
- Published
- Read time
- 6 min read
Eligibility, customer choice, and approval answer different questions
Before an exchange, check whether the units are eligible, whether the replacement is actually available, and whether the customer chose it. Then obtain the merchant’s approval for the specific return and replacement. Collapsing these checks into a single “approved” status makes it easy to issue the wrong item or duplicate a financial remedy.
A previous refund needs line-level interpretation. Identify which units it covered and why it was issued. A shipping-charge refund is different from refunding the product itself. Do not calculate entitlement from the order’s net total alone; that number can obscure several unrelated adjustments.
Evidence needed to resolve the exception
Use this exception guide when reviewing a proposed Genie workflow or investigating a case that cannot proceed confidently. The tables describe operational decisions to configure in your environment. They are not claims that a connected application automatically supplies your organization’s policies, identity mappings, or approval process.
| System or owner | Evidence and responsibility |
|---|---|
| Zendesk | Exchange request, customer choice, internal approval, and resulting order references. |
| Shopify | Original purchase, return and refund history, and approved return/replacement records. |
| NetSuite | Replacement variant availability by location. |
| Return policy | The merchant’s current eligibility rules and any approved exception. |
Required context for this workflow design.
Offer variants without promising an allocation
List the size and color combinations supported by current NetSuite availability. Avoid suggesting that a displayed quantity reserves inventory while the customer considers the options. The availability check should include location and the stock definition your operation uses. Recheck after the response because another order may consume the units in the meantime.
If the chosen variant is no longer available, explain that through Zendesk and offer the remaining verified choices. Do not substitute a similar color to keep the exchange moving. If no suitable option remains, route the case for a policy-based decision rather than silently converting the request into a refund.
Keep the approval attached to the exact remedy
The reviewer needs the original order line, prior remedies, selected replacement, quantities, relevant policy clause, and cost implications. A note that says “looks good” without the proposal context is difficult to apply safely after a ticket changes. Record the decision against the proposal the reviewer actually saw.
Check the ticket and original order again before creation. A second support agent may already have processed the exchange. If a return exists but no replacement reference is visible, investigate that specific gap. Do not conclude that the whole operation failed just because the final ticket update is missing. Confirmed IDs are more reliable than whether the last message was posted.
Decision table for common exceptions
Use the condition in the first column to choose the next action. The final column describes the boundary that must remain true while the case is unresolved. Apply the organization’s actual policy and source records to the live case; do not treat an illustrative condition as proof that the condition exists.
| Observed condition | Next action | Required boundary |
|---|---|---|
| Variant unavailable | Offer verified alternatives | Wait for customer selection |
| Prior refund on requested units | Review the existing remedy | No automatic duplicate compensation |
| Customer chose; merchant has not approved | Request merchant approval | No return or replacement created |
| Return exists after timeout | Link existing return and inspect replacement | No duplicate return |
Exception decisions for product exchanges.
Illustrative exception and recovery
A return was created successfully but the ticket update timed out. On retry, the existing return ID is found against the original order. The workflow uses that record and investigates the replacement outcome, preventing a second return.
This example uses fictional records to show the decision logic. It is not a customer case study or a claim of measured results. In a live case, retain the actual record IDs and evidence behind each statement, and replace all illustrative quantities or timing assumptions with the approved operational inputs.
What to record before resuming
A Zendesk exchange proposal containing original order lines, policy evidence, prior remedies, customer-selected variant, merchant approval, and confirmed return and replacement IDs.
Preserve the original finding and the evidence that resolves it. Record which person or system supplied the clarification, which proposal it applies to, and the action now permitted. Do not erase the uncertainty from the history: a later reviewer needs to understand why the case paused and why it resumed.
Boundaries that remain in force
- Evaluate the merchant’s policy and prior refunds at item and quantity level.
- Offer verified sizes or colors and wait for customer choice in Zendesk.
- Require merchant approval before creating either return or replacement.
- Recheck availability and existing records immediately before creation.
Review the case before restarting
First verify that the new evidence resolves the original blocker rather than a different issue. Then check whether the case, source records, or proposed action changed during the wait. A response attached to the right ticket can still be insufficient if it refers to an earlier proposal or leaves a required quantity, identity, or approval unresolved.
Run the relevant row from the decision table as a review scenario. Confirm that the job stops at the required boundary, asks for the specified information or decision, and resumes from the confirmed state. If a write or message may already have succeeded, inspect its destination before repeating it; if this job only prepares a draft or report, verify that it stays within that output scope.
- Exchanges created with both choice and approval recorded
- Duplicate return or replacement count
- Exceptions caused by stock changes after customer selection
Track unresolved cases by their actual blocker and owner. A case waiting for clarification needs a different next action from one waiting for a confirmed result. Review the evidence when the state changes, and keep any still-unresolved completion condition visible instead of treating a successful intermediate step as the end of the work.
Give your Genie a job description
Copy the job description below. It preserves the scope and decision boundaries of this use case. Configure the referenced systems, record relationships, policies, and approval owners in your workspace before enabling the job.
Paste this into “Give your Genie a job description.” Explore Stacksync Genies.
Implementation references
These first-party references document the underlying records and interfaces. The cross-system sequence, approvals, and completion rules in this article are a proposed operational configuration; validate them against your connected workspace before enabling it.
FAQ
Frequently asked questions
Related articles
