[Customer service & support]() / [Use cases]() / [Order changes]() [How it works]() [What you get]() [Scope]() [Start a review]() [Customer service & support]()[Order changes]() # Change or cancel orders before the warehouse picks. A cancellation or edit that’s finished in the warehouse and the payment system, then confirmed to the customer once it’s true. [Start with a support review]() [How it works]() Fernway Outfitters Today · 7:02 pm Your size swap on order O-8431 The warehouse had already started picking your order, so we couldn’t change the size in time. We’re checking whether they can hold it, and a teammate will confirm by 9 am. Nothing has been charged or refunded. Trail pantOrder O-8431 · size 32 to 34 requested View order Nothing is called changed until the warehouse confirms it When the warehouse has already started, the customer hears what’s true and who owns the next step. ## Sound familiar? - The request is in the helpdesk, and the warehouse picked the order an hour ago. - An agent says “canceled” and the parcel ships anyway. - Refunds go out by hand, and some go out twice. A parcel that ships after “canceled” costs return shipping, rework and the customer’s trust in your next message. Fernway’s launch week, cancel and edit requests 1. ## 120 requests in launch week. Cancellations, address fixes and size swaps, by email, chat and DM. The AI reads each one and finds the order. 2. ## Each one checked before anything moves. Who’s asking, whether it’s been picked, and what the policy allows. Four needed a question back first. 3. ## 104 done in every system. The warehouse stop is confirmed, then the order cancels and the refund goes out once. Twelve went to your team instead. 4. ## 102 customers told what’s true. The message goes out after the work is done, never before. Two bounced, and a person picked them up. 5. ## The record is what you keep. Order O-8421: stopped before the pick, $84 refunded once, customer confirmed at 6:14 pm. Order **120**Asked **116**Checked **104**Done in every system **102**Confirmed to the customer Where it landed DR O-8421 · Dana R. Reached confirmed to the customer Stopped before pick, $84 refunded SW O-8424 · Sam W. Reached confirmed to the customer Address changed KM O-8426 · Kim M. Reached confirmed to the customer Stop confirmed, then canceled AB O-8428 · Alex B. Reached confirmed to the customer Refund issued TO O-8435 · Tom O. Reached done in every system Refund issued, email bounced, team calling MJ O-8437 · Mia J. Reached checked Picked first, refund held for team CP O-8431 · Chris P. Reached checked Size swap, picking started LT Lee T., order unknown Reached asked Asked which order, no reply yet Completion record · CX-1042 Order O-8421 Step Result Time Customer verified Owns O-8421, paid $84 6:12 pm Warehouse stop F-882 stopped before pick 6:12 pm Shopify order Canceled 6:13 pm Refund $84 issued once 6:13 pm Customer told Confirmed by email 6:14 pm Cancellation policy CAN-3 [How a completion record works]() ## What changes. ShowTodayWith the engine Requests Copied between the helpdesk, Shopify and the warehouse Checked and done in each system by rules Confirmation “Canceled” sent when the request is logged Sent once the warehouse stop is confirmed Refunds Issued by hand, sometimes twice Issued once, with the reference recorded Exceptions Passed along in Slack Held with an owner and a deadline ## How it works. 6 steps, 4 stages. - AI**2** - Rules and automation**3** - Your team**1** - Approval 1. 1 Ask 1. AI ### Read the request Works out what’s being asked, even in the customer’s own words, and finds the order. - Gorgias 2. 2 Check 1. Rules and automation ### Check identity, state and policy The customer owns the order, the edit window is open and the change is inside your limits. - Shopify - ShipBob 3. 3 Do 1. Rules and automation ### Stop the pick, then cancel and refund once The warehouse stop is confirmed first. A retry can’t refund twice. - ShipBob - Shopify 2. Your team Approval ### Own what the system can’t finish Picked orders, payment increases and goodwill go to the person with authority, with the case attached. 4. 4 Tell 1. AI ### Tell the customer what’s true Writes the confirmation after the work is done, or says what’s pending and who owns it. 2. Rules and automation ### Write the completion record Every system’s state and time, kept as your record. Held cases teach the next rule ## What you get. Real work, every week. Completion record · CX-1042 Order O-8421 Step Result Time Customer verified Owns O-8421, paid $84 6:12 pm Warehouse stop F-882 stopped before pick 6:12 pm Shopify order Canceled 6:13 pm Refund $84 issued once 6:13 pm Customer told Confirmed by email 6:14 pm Cancellation policy CAN-3 The completion record: one line per system, with the time each one finished. Held for the team O-8431 · fulfillment lead Size swap asked for after picking started. Asked Trail pant, 32 to 34 State Picking started 6:48 pm Done so far Nothing changed in any system Told the customer A teammate will confirm by 9 am Next Hold the pick, or exchange after delivery The held case, with everything the next person needs. Your fulfillment lead works from it. Edge cases · tested **5 of 5**cases pass before go-live - The warehouse ships between the lookup and the cancel - The customer sends the request twice - The email doesn’t match the order’s owner - The refund times out after it succeeded - A change would raise the payment Goes to a person Run again after every policy or connector change The edge cases we test before it goes live, and again after every policy change. ## How you’ll know it’s working. 1. Verified completions per eligible request Requests where the warehouse, the order and the refund all agree, out of those your policy allowed. 2. Duplicate or lost actions Refunds issued twice, and stops that never reached the warehouse. 3. Repeat contact within seven days Whether the customer had to ask again. Baselines agreed before we build. ## Works with what you have. Commerce - Shopify - NetSuite Support - Gorgias - Zendesk Fulfillment - ShipBob We configure first As of October 2026, Gorgias’s AI Agent can act on Shopify orders and, through its ShipBob connector, on the warehouse. Zendesk has an agent-approved cancel-and-refund recipe that needs Copilot. We set up what your helpdesk already does, then test it. We build when The warehouse stop, the refund and the customer message don’t reconcile, or you need proof a change finished in every system. ## What a first build includes. Built in your accounts, around your team. Scope, fee and baseline agreed before we start. 1. 1 Design 2. 2 Build 3. 3 Run it, or hand it over [Start with a review]() [Scope this build]() ### We build - Eligibility rules for cancellations, address changes and size swaps - Actions across your helpdesk, Shopify and warehouse, tested on the hard cases - A completion record for every request - A hold-and-handoff path with an owner and a deadline ### We start from - Helpdesk and Shopify access - Warehouse or 3PL access and cutoff times - Your cancellation and refund policy - A month of change requests ### From your team Owner CX lead, with the fulfillment lead Involves - Customer service - Fulfillment - Finance - Engineering ## Questions teams ask. Our helpdesk AI can already cancel orders. Why more? It can change the order in Shopify. Whether the warehouse stopped is a separate question, and so is the refund. We configure the native actions first, then add the check that all three agree before anyone says “canceled.” What if the warehouse already picked it? Then the customer hears that, and a person owns the next step: hold the pick, recall it or take it back as a return. The system never says “canceled” until the stop is confirmed. Can customers just edit their own orders? Often, and it’s the cheapest fix. Jones Road told the vendor Order Editing that a one-hour edit window removed its order-edit tickets. That’s a vendor-hosted account with no baseline, but we’d start there if it fits, then build around what still comes in. Who owns it once it’s running? You do. It’s built in your accounts, documented, with training for the people who run it. Ownership usually sits with your CX lead, with the fulfillment lead. We can keep running it with you, or step back. How do we start? Usually with a support review: two to four weeks, a fixed fee credited to the build, and a plan that’s yours. If the job is already clear, we can scope the build directly. ## Part of your support engine. One of 12 use cases, in 6 parts. [See the whole support engine]() 1. [Order changes **2**]() 2. [Delivery & returns **2**]() 3. [Product help **2**]() 4. [Knowledge **2**]() 5. [Quality & proof **2**]() 6. [People & coverage **2**]() In order changes - **Order changes**You’re here - [**Order status**Resolve “where is my order” with a status customers can trust]() Works with - [**Delivery recovery**Recover delayed and lost shipments before customers chase]() - [**Returns and exchanges**Guide returns and exchanges to the right outcome]() See it at work - [**In the Fernway launch**Day 1: “Cancel the whole order”]() ## Stop the parcel before it ships. Start with a support review. [Start with a support review]() [**Talk it through first**15 minutes]() We reply within one business day. --- Source: [https://www.thekeating.co/use-cases/order-changes/]() [Contact Keating & Co](mailto:nelson@thekeating.co) · [Agent guidance](https://www.thekeating.co/llms.txt)