Choose a Warehouse Transfer, Substitute, or Revised Delivery Date
Choose a delayed-order recovery option by comparing usable supply, achievable timing, extra cost, and the customer commitment at stake.
- Author
- Stacksync · App tips writer
- Published
- Read time
- 6 min read
Compare recovery options against the customer’s actual constraint
Choose a delayed-order recovery option by comparing usable supply, achievable timing, extra cost, and the customer commitment at stake. Another warehouse preserves the original item, a substitute changes what the customer receives, and a revised date changes when they receive it. Each requires different evidence and decisions.
Avoid ranking alternatives purely by the earliest displayed date. A date based on unreceived supply or unconfirmed transport is less certain than one supported by available stock and a workable dispatch plan. Show the assumption next to the option so the approver can judge it.
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 |
|---|---|
| Shopify | Unfulfilled demand, promises, approved order changes, and fulfillment confirmation. |
| NetSuite | Location-level usable stock, inbound purchase orders, and costed supply alternatives. |
| HubSpot | Customer commitments used to assess recovery options. |
| Zendesk | Existing cases, customer consent, approved communications, and follow-up history. |
Required context for this workflow design.
When another warehouse is a viable option
Check the exact SKU, quantity available to this order, dispatch cutoff, and delivery route. Include any incremental handling or transport cost in the approval request. If stock is reserved elsewhere, the warehouse is not automatically an available alternative. Escalate any reallocation decision through the existing operational authority.
Recheck the supply after approval. A proposal prepared at the start of the day may no longer be executable in the afternoon. Preserve the previous decision for audit, but do not apply it to a different warehouse or higher cost without review.
When to offer a substitute or a later date
An available substitute needs explicit customer consent for the actual variant and quantity. A similar description, previous purchase, or silence on the ticket is not consent. Explain any relevant difference in the proposed item using verified product information, and wait for the response in Zendesk.
For a revised date, distinguish a supported planning estimate from a confirmed commitment. Include the reason for the change and the next follow-up. If no option currently meets the customer’s constraint, say so in the internal proposal and escalate rather than claiming recovery has been arranged. Continue monitoring the existing case, checking prior actions before any message or replacement write.
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 |
|---|---|---|
| Extra cost not approved | Wait for merchant decision | No added-cost action |
| Substitution lacks consent | Request customer choice | Original item not silently replaced |
| Approved stock disappears | Prepare revised option | Revisit affected decisions |
| Replacement order created | Monitor fulfillment | Case remains open |
Exception decisions for delayed order recovery.
Illustrative exception and recovery
A customer accepts a substitute, but the stock check now shows only one of the three required units. Consent for three units does not authorize a mixed replacement. Prepare a revised proposal, obtain the relevant decisions, and keep the original case open.
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
One Zendesk recovery case per order issue, with costed alternatives, versioned decisions, customer consent where required, confirmed changes, and fulfillment evidence.
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
- Search existing tickets, customer messages, and replacement actions before each run.
- Require merchant approval for extra costs and customer consent for substitutions.
- Recheck the selected inventory and apply only the approved order changes.
- Communicate through Zendesk and keep following until fulfillment is confirmed.
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.
- At-risk cases reaching confirmed fulfillment
- Recovery actions with matching cost approval and substitution consent
- Duplicate customer messages or replacement orders
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
Explore these integrations and topics
Related articles
