A refund starts in your helpdesk and ends in your store. The seam between them is where refund procedures quietly break.
A refund starts in Gorgias and ends in Shopify, and the handoff between them is where refund SOPs quietly break. The procedure below is the one most DTC support teams actually need documented: who decides, where the money moves, what gets written back to the ticket, and which of those steps changes when your policy changes.
This is a worked example. If your stack is Gorgias plus Shopify you can copy it directly. If it is not, the shape still holds. Any operational procedure that crosses two tools has a seam, and the seam is the part nobody writes down.
A refund inside a single tool is easy to document. Open the order, click Refund, enter the amount. That is a screenshot and two sentences.
But nobody processes refunds in one tool. The customer emails, so the request lands in Gorgias. The money lives in Shopify. The reason code that feeds your monthly returns review lives in whichever field you picked eighteen months ago. The agent holds all three in their head at once, and the SOP, if it exists at all, documents only the middle part.
The failure modes are consistent across teams:
Every one of those is a seam failure. Both tools work fine. The handoff is undocumented.
Here is the full thing, written the way it should live in your SOP tool. Adjust the thresholds to your own policy. The structure is what matters.
Open the ticket and confirm three things before touching Shopify.
Tag the ticket refund-in-progress before you leave Gorgias. This is the highest-value step in the procedure and the one most often skipped. It is what stops two agents refunding the same order twice on a busy Monday.
Before opening Shopify, decide what you are actually refunding.
| Component | Refundable when |
|---|---|
| Product total | The item is being returned, or policy covers it outright |
| Original shipping | The error was ours: wrong item, damaged, or late past the guaranteed date. Not for change of mind |
| Return shipping | Ours if the error was ours, the customer's otherwise |
| Discount codes | Always calculated on what they paid, not list price. Shopify handles this on a line-item refund but not on a typed amount |
If the total exceeds your approval threshold, and most teams land between $150 and $300, stop here and go to step 6.
Open the order in Shopify admin. Use Refund, not Return, unless you are also creating a return label. Those are different objects, and mixing them up is how you end up with a return that shows as open forever.
Back in the ticket, add an internal note with four facts: refund amount, what was excluded and why, restock yes or no, and the Shopify refund ID. Four facts, one line each.
This is the step that makes the procedure auditable three months later when someone asks why an order was refunded at 80 percent. Without it, the answer lives in one agent's memory.
Then reply to the customer with the refund amount, the exclusions in plain language, and the settlement window. Five to ten business days is right for most card processors, but check yours.
Remove the refund-in-progress tag, apply refunded, and close the ticket. If a physical return is expected, do not close it. Snooze until the expected delivery date and let the return-received procedure take over.
Anything over the approval threshold, outside the return window, or involving a chargeback goes to a named person, not a channel. Channels absorb exceptions, named owners resolve them. Write the name into the SOP and update it the day that person's role changes.
This post covers running a refund. The macro SOP covers building the automation behind it: action chains, tagging, and the weekly test that catches a broken Shopify connection.
That is a working refund procedure today. Here is what makes it wrong six months from now.
The Shopify admin moves. Shopify ships interface changes constantly, and your screenshot of the refund screen is a snapshot of one week in 2026. When a button moves, the SOP becomes subtly wrong. Not wrong enough for anyone to raise it, just wrong enough that new hires stop trusting it.
Your policy changes and the SOP does not. You decide to start refunding original shipping on late deliveries. That decision gets made in a Slack thread on a Tuesday. The SOP still says shipping is non-refundable. Now half the team follows the new rule and half follows the document, and you do not find out for a quarter.
The approval threshold drifts. It was $150 when the team was three people. It is effectively $500 now, because the ops lead got tired of approving everything. Nobody wrote that down.
The person named in step 6 leaves. The SOP still names them.
This is SOP drift: the document did not change, reality did. It is the failure mode nobody catches, because a stale SOP looks exactly like a current one. There is no error message. The procedure just stops matching what the team does, and the gap surfaces when someone new follows it literally and gets it wrong.
ReccordSOP runs a daily sweep for published SOPs that have crossed 90 days without a review and emails the owner a one-click question: is this still accurate? That is the whole mechanism. A stale procedure gets surfaced instead of sitting there looking authoritative.
The six signals that reveal drift, a 20-minute monthly check, and the 30-day audit for teams who have never looked.
The other half of the problem is that a refund procedure living in a document is a procedure someone has to remember to open.
Most teams write the SOP, share it once, and watch it become reference material nobody consults during the actual work. The agent processing forty tickets on a Monday is not opening a six-step document.
Dispatch it as a checklist run instead. A published SOP can be sent to a person as a run: the steps are snapshotted at dispatch, the assignee checks them off as they go, and the completed run records exactly which version of the procedure was followed. For a refund that matters. Three months later you can show that the agent who refunded a $400 order did check the approval step, and you can show what the threshold said at the time.
For recurring work such as the weekly chargeback review or the monthly refund-reason audit, set a schedule and the run is created and emailed to the assignee automatically. The procedure stops being a document and starts being a task that shows up.
If your refund procedure currently lives in one person's head, record yourself doing it once. That is the fastest version of this article you can act on today.
Record the refund once. Get a structured SOP with screenshots, dispatch it as a checklist run, and get told when it stops being true.
In Shopify. Gorgias can trigger a Shopify refund through the integration and it works, but the refund object still lives in Shopify, and that is where reporting and reconciliation happen. Whichever you pick, pick one. The worst outcome is a split team, because then no report is complete.
Same procedure, with restock unchecked and a photo attached to the Gorgias ticket before the refund is issued. The photo requirement is a policy decision, so write it into step 1 and it happens before the agent is emotionally committed to resolving the ticket.
Not manually, which is the point. Either you re-record the procedure when the screenshots stop matching, or you accept drift. What you can control is knowing when it has drifted, which is why a review prompt on a schedule beats a calendar reminder you will snooze.
The shape does. The seam moves, because you are reconciling a refund against a return the 3PL received rather than against the Shopify order, but the structural advice is identical: tag before you leave the first tool, write the outcome back, and name an owner for exceptions.
Most DTC teams land between $150 and $300 for one-touch refunds, calibrated to AOV. The number matters less than writing it down and reviewing it, because an unwritten threshold drifts upward every time an ops lead gets tired of approving things.
I built ReccordSOP after watching too many DTC ops teams lose months to undocumented workflows. These SOPs are battle-tested with Shopify operators running $1M to $50M brands.
Last reviewed July 27, 2026
A return policy is a promise. A returns SOP is the machine that keeps it the same way every time.
Macros silently break. Customers notice before you do. Here's the audit that catches broken macros before CSAT slides.
Manual responses win under 20 percent of the time. A repeatable process is how you flip that.
Most SOPs are wrong within 90 days of publishing. Here's how to detect it before it costs you a customer.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.