Refund processing SOP: the Gorgias to Shopify handoff

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.

Why cross-tool refunds break

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:

• The refund is issued in Shopify but the Gorgias ticket is closed without a note, so the next agent who picks up a follow-up has no idea it was already handled.
• The agent refunds the full order including shipping when policy says shipping is non-refundable, because the policy lives in a Notion page and the procedure lives somewhere else.
• Restock gets checked when it should not be (damaged goods) or left unchecked when it should be (unopened return), and inventory drifts.
• A partial refund gets approved by someone without the authority to approve it, because the approval threshold was never written into the procedure. It was just something the ops lead knew.

Every one of those is a seam failure. Both tools work fine. The handoff is undocumented.

The procedure, step by step

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.

1. Triage the request in Gorgias

Open the ticket and confirm three things before touching Shopify.

• Order number. If the customer did not give one, search Gorgias by email and the Shopify integration surfaces their order history in the sidebar. Never process a refund from a name alone.
• Request type. Refund, replacement, or store credit are three different procedures. This one covers refunds.
• Age of the order, checked against your return window. Outside the window makes this an exception, which goes to step 6.

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.

2. Check the refund against policy

Before opening Shopify, decide what you are actually refunding.

If the total exceeds your approval threshold, and most teams land between $150 and $300, stop here and go to step 6.

3. Issue the refund in Shopify

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.

• Set the quantity per line item rather than typing a total. Line-item refunds carry the discount math and the tax math for you.
• Restock: check it if the item is coming back sellable, uncheck it for damaged goods, opened consumables, or anything going to write-off. This checkbox is the direct link between your refund procedure and your inventory accuracy, so treat it as a decision rather than a default.
• Refund shipping: enter the amount you decided in step 2. Shopify pre-fills nothing here, so a skipped step means a wrong refund.
• Reason: use your team's fixed vocabulary. Free text here makes the monthly refund-reason report worthless. Pick five reasons, write them into the SOP, and never add a sixth without updating the SOP.
• Notify customer: usually off, because you are about to send a better message from Gorgias with full context. Leaving it on means the customer gets two emails and replies to the wrong one. Note that Shopify has this selected by default, as it does Restock items, so both are things an agent has to actively turn off rather than actively turn on.

Four of those choices have consequences in Shopify that outlast the ticket, so they belong in the SOP as explicit branches rather than as defaults an agent clicks past.

The over-refund case has its own control worth knowing about before you need it. Refunding to the original payment method on an order already refunded to store credit requires the Over-refund orders previously refunded to store credit permission, and Shopify limits it to orders processed through Shopify Payments. If an agent reports the original payment method locked on the refund screen, that is what they are hitting.

4. Write the outcome back to Gorgias

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.

5. Close the loop

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.

6. Exceptions queue

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.

Where this SOP goes stale

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.

A real example: Gorgias Helpdesk 2.0

Everything in the section above is the general case. Here is the specific one, because it happened to this exact procedure while the article was live.

Gorgias published Helpdesk 2.0 on 6 May 2026, updating the post on 26 May. It is a redesign of the agent workspace, and by Gorgias's own description it changes four things that a refund SOP touches.

• A chat-style interface with speech bubbles replaces the old email layout.
• Past conversations open in a sidebar beside the active conversation, and recent orders appear in the right panel, so checking history no longer means leaving the ticket.
• When AI Agent escalates a conversation it attaches a handover summary covering the issue, the actions already taken, and why it was passed to a person.
• The left sidebar reorganises into Inbox, AI Agent, Marketing and Analytics.

Gorgias also says the upgrade is in place: macros, views, rules and integrations carry over automatically, with no migration work. That is the part that makes this dangerous rather than obvious. Nothing broke. No agent hit an error. The macros your refund SOP names still exist and still work, so there is no moment where anybody is forced to notice that the document is now describing a screen that is gone.

Here is what that does to the procedure above, step by step. The flags are our reading of the changes Gorgias describes, not Gorgias guidance.

The row that matters most is the second one. An instruction telling agents to leave the conversation to check order history is now describing the exact friction the redesign was built to remove. The SOP is not just out of date there, it is actively teaching a slower way of working.

Note what the Shopify half of the procedure did during all of this. Nothing. Steps 2 and 3 are untouched, because they run in a different company's software on a different release schedule. That is the argument for writing a cross-tool SOP with a visible seam: when one vendor moves, you can tell in minutes which half of the document is suspect instead of re-reading all of it.

Re-recording as a review tool

Knowing a tool changed is not the same as knowing what to edit. The cheapest way to close that gap is to record the procedure again and compare, rather than rewriting from memory.

1. Record the refund end to end on a real ticket, after the change.
2. Compare the new recording against the documented SOP step by step. Mark the steps that differ, and mark the ones that match, because knowing which half is still trustworthy is half the value.
3. Have a reviewer approve the changed steps and keep the matching ones. Keep the previous version on record rather than deleting it, so you can still answer what the procedure said on the day a given refund was issued.

The reviewer is what makes this work rather than theatre. A comparison nobody approves is a flag, not a fix.

Make it executable, not just documented

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.