Shopify return request or return label email not sending — after the buyer already asked to send it back.

A return is not a refund. Refund and cancel mail fires when money moves or the order is cancelled — that playbook is refund / cancel email not sending. This page is earlier (or parallel): the buyer opened a return request, you approved it, or a prepaid return label was emailed — and that mail never landed. Those templates live in Shopify admin under Settings → Notifications → Customer notifications: Return request, Return approved / Return label created (wording varies by plan and Shopify Returns version). Order confirmation and Shipping confirmation are different templates again.

Six ordinary reasons that return mail never lands: the template is still off, Notify customer was unchecked when the return or label was created, Shopify has no return object (you refunded only, or a Loop / Returnly / Redo / Narvar app never wrote one back), a Shopify Flow “send customer email” on Return created never matched, you tested Order refund or Order confirmation instead of a real return, or sender / spam hid a send that did fire. Walk them in that order. You already pay for Shopify. You do not need a second returns-email app to read the notification list.

Open Settings → Notifications → Customer notifications. Find Return request. Find Return approved or Return label (exact labels depend on whether Shopify Returns is enabled). Read the on/off state of each, not the subject line, not a preview, not Order refund next to them. Disabled does not send. A staffer who turned native return mail off “so Loop can own it” and then never published the app’s email leaves a hole that looks like Shopify is broken.

They are separate templates from Order refund and Order cancelled. Approving a return without issuing a refund can fire return mail and never refund mail. Refunding without creating a return can fire refund mail and never return mail. A return that later refunds can fire both — or neither if both templates are off. Do not debug this page on an Order refund toggle.

Turn Return request / Return label on only if native Shopify is supposed to send them. If a returns app or a Flow workflow is supposed to send instead, leave these templates off on purpose and go fix that product. Do not leave both native and the app on unless you want two emails for one return.

The template can be on and still not send. Approving a return, creating a return from the order, or generating a return label often includes Notify customer / Send a notification to the customer. Unchecked means no email, even with a live template and a real return on the order. Staff who approve returns “quietly” so they can paste a label in Slack often never email the buyer.

This is the warehouse trap. Someone generates twenty labels at 4pm with the box off, then never sends. A saved browser that remembers the last return dialog state will keep it off. Restock and refund checkboxes are inventory and money — they do not send the return-request or return-label email.

For the next test: pick one fulfilled paid order, create or approve a return with Notify customer on (or generate a label with notify on), to an inbox you control, wait a minute, then read that inbox — not the order timeline alone. The timeline can show “Return created” without “Return request email sent to…”.

Native return mail fires on a Shopify return object, not on a refund alone and not on a label PDF sitting in a returns-app dashboard. Open the order. If there is no Return / Return request on the timeline, native Return request and Return label templates have nothing to send. A full refund with Restock and no return is the refund email path — different event.

Loop, Returnly, Redo, Narvar, AfterShip Returns, and similar tools often own the buyer-facing return portal. If the app emails the label itself and never creates a Shopify return (or creates one with notify off), native Shopify stays quiet. That is not “Shopify return email is broken” — it is which product owns the send. Confirm the app’s “create Shopify return” and “send email” toggles separately.

A Slack “please send it back” note, a Gorgias macro with a carrier link, or a handwritten RMA in Sheets is not a Shopify return. Create the return in admin (or fix the app that should), then re-read section 03 — the notify box on that new return.

Some shops skip native templates and send return instructions with Shopify Flow: trigger Return created / Return approved / Fulfillment created (for a return label fulfillment), then Send customer email or Send HTTP request to a template tool. If that is your path, a disabled native Return label template is expected — the bug is Flow, not Notifications.

Open Shopify Flow → the workflow → Run history. Inactive workflows never run. A condition that requires return reason = “Wrong size” will skip every other reason. A wait step that has not elapsed looks like silence. An action that failed (missing customer email, template variable error) shows in the run, not in the buyer’s inbox. Full Flow debugging is Shopify Flow not running— use that page when the workflow itself never fires.

Flow “Send internal email” is staff mail. It is not the customer return-request template. Do not treat a Slack ping to ops as proof the buyer got a label.

Placing a test order proves Order confirmation, not Return request. Issuing a refund proves Order refund, not Return label. Preview in the notification editor and Send test email prove the template renders. They do not prove a live return fires it. A staff email on the order is not the customer. An unpaid draft cannot return.

Honest test: checkout from a phone that is not logged into admin, fulfill the order (or use a fulfilled live order), create/approve a return with Notify customer on (or run the Flow path), to an inbox you own that is not the store’s staff address. Wait. Then search that inbox and spam for the store name. If Order confirmation and refund mail arrived and the return / label mail did not, the bug is template / notify box / return object / Flow — not “Shopify email is down.”

Missing customer email on the order or customer record has nowhere to send — same failure mode as order confirmation, different event. Digital / non-returnable SKUs that never open a return portal also never create the event.

Shopify (or Flow) can send and the customer still reports nothing. Open Settings → Notifications and read the sender email. A custom from-address without authenticated DNS (SPF / DKIM for the domain Shopify tells you to add) lands in spam, or is dropped. A shared @shopifyemail.com from-address also gets filtered on some inboxes. BCC to the owner is not proof the customer got it — BCC can arrive while the To: line bounced.

On the order timeline, look for a notification sent event, not just Return created. If Shopify says it sent, have the customer search spam, promotions, and the exact from-address. If Shopify does not say it sent, go back to template / notify box / return object / Flow — do not buy a deliverability app for a mail that never left.

Do not install a second returns-email app to “make sure it fires.” You will double-email the next customer who was never the bug. Shopify Email (marketing campaigns) is also not this template — mixing them is how you pay for two products and still send none.

Stay DIY if you can spend one afternoon on the list above: templates on, notify box on, a real Shopify return (not refund-only), Flow run history if you use Flow, sender/spam. Create one live return from a phone. Read the inbox. That is the whole playbook. No agency required. Short answers also live on the merchant FAQ. Related troubleshooting: refund / cancel not sending (money moved, different template), shipping confirmation not sending, Shopify Flow not running, order confirmation not sending.

Pay for help when the work is not the notification toggle — it is connecting the stack you already have so return mail is one live path instead of a native template plus a Flow draft plus a returns app you forgot, lead capture is not dying in DMs, and exceptions show up in a channel you already check. That is the Latch AI Ops install.

What $997 USD one-time buys: lead capture on the live store, ops alerts in a channel you already check, and a checkout-ready workflow. 72 hours after collaborator access, not after payment. One live Shopify store. Access plus a delivery thread. Store URL collected at checkout. Not a SaaS seat, not a notification rebuild, not a returns-app rebuild, not a Klaviyo rebuild, not a Gorgias implementation, not a support VA, not a brand or theme job.

Other shops’ public ranges, not testimonials: a Shopify Flow or recovery-app install typically runs $500–$2,500. A returns-ops or Klaviyo-only rebuild typically runs $2,000–$5,000. $997 is the cheap end of that work, sold as a 72-hour install of three systems — not as a ticket-cut number or recovered checkout revenue.

What it does not buy: fewer WISMO tickets, recovered checkout revenue, a lift in conversion, or a case study. Latch AI Ops has not published customer proof because there are no customers yet. You are buying the install.

Checkout is on Whop. Operator is Nico. United States offer. You can revoke collaborator access after handoff. We do not take owner passwords.