The short version: Shopify has no native home for a damaged order. Notes and tags will carry you to about ten issues a month; after that you need three things — one owner per issue, a status that moves, and a written record that outlives the person who took the call. Below is a workflow you can adopt this week, and an honest read on which category of tool fits which situation.
A customer emails on a Tuesday. The dresser arrived with a cracked corner. They have a photo.
What happens next involves four people. Someone in support has to reply and decide what the customer gets. Someone in the warehouse has to confirm how it left. Someone has to file a claim with the carrier or the supplier. And someone — usually the founder, usually three weeks later — has to work out whether this is the fourth cracked dresser this quarter or the first.
Shopify is very good at the transaction. It is not built to hold a case. There is nowhere in the admin that answers who owns this, what stage is it at, and what happened last. So the case gets held somewhere else: an inbox, a spreadsheet, a Slack thread, someone’s memory. That is where the losing-your-mind part starts.
What Shopify gives you natively — and where each piece runs out
To be fair to the platform: the native tools are genuinely useful, and plenty of small stores never need more.
Order notes attach free text directly to the order. That is the right location — the note lives where the context lives, and anyone opening the order sees it. What a note cannot do is belong to someone. It has no state. Two people can overwrite each other. And a note that reads “customer says damaged, waiting on photos” is indistinguishable, a week later, from one that has already been resolved.
Tags are better than people give them credit for. A damaged tag makes orders filterable, which means you can count them — and counting is the beginning of managing. But tags are flat. damaged tells you a category, not a status, not an owner, and not a history. Teams try to solve this by inventing damaged-open, damaged-awaiting-supplier, damaged-closed, and within a month the tag list is unusable and half the orders carry two contradictory tags because nobody removed the old one.
Refunds and the order timeline record what you did, accurately and permanently. That is real value. But they record the financial outcome, not the process that produced it — and they say nothing at all about the carrier claim you filed to recover the cost.
None of this is a criticism of Shopify. An order object is a record of a sale. A damaged-goods case is a small project with a lifecycle, and those are different shapes.
Why the spreadsheet stops working
Almost every team lands on a spreadsheet, and it is the correct first move. It is free, it is instant, and it makes the problem visible. Keep using it if it is working.
It tends to fail in four specific ways, usually in this order.
Nobody owns a row. There is an “assigned” column, and it is either blank or contains a name from six weeks ago. The failure is not the column, it is that nothing forces the column to be true.
It drifts from the orders. The sheet says order 4021 is awaiting a replacement. Shopify says it was refunded on Thursday. Both are recorded by real people; neither is wrong; the two systems simply never talked.
The history evaporates. A cell gets overwritten, and the sequence of what happened is gone. When the supplier disputes your claim in six weeks, you have an outcome and no evidence.
It goes stale quietly. No spreadsheet announces that it stopped being maintained. You find out when a customer follows up on something everyone assumed was closed.
The tell that you have outgrown it is simple: if a customer emails asking for a status update and nobody can answer without asking two colleagues, the sheet is no longer the source of truth.
A workflow that holds up
This works regardless of tooling. Adopt the process first — a tool that automates a process you have not defined just produces faster confusion.
1. Capture the issue against the order, not next to it. Whatever you use, the record has to be reachable from the order and the order reachable from the record. Every minute someone spends matching an email thread to an order number is a minute of pure loss.
2. Give it exactly one owner. Not a team. A person, by name, at all times. The most expensive failure in order issues is not a slow resolution — it is the one everybody assumed someone else had picked up.
3. Set a status that has to move. Five stages are enough: reported, investigating, awaiting, resolving, closed. The value is not the labels; it is that a status forces someone to answer what is this waiting on right now, which is the question a stale spreadsheet can never answer. Each stage needs a condition for leaving it — we break those down in the full order issue workflow.
4. Log the evidence immediately. Photos, the carrier’s tracking record, the packing note, the customer’s exact words. Carrier claim windows are frequently short — often measured in days for visible damage — and the evidence you did not gather on Tuesday is unavailable by the time you need it.
5. Separate the customer resolution from the recovery claim. This is the one that costs real money. Refunding the customer and recovering the cost from the carrier or supplier are two processes on two clocks. The customer resolution is urgent and fast. The claim is slow, procedural, and easy to abandon once the customer is happy. Teams that track them as one thing routinely make the customer whole and then quietly eat the cost.
6. Close deliberately. Closing means the customer is resolved and the claim is settled or written off on purpose. Everything else is an issue that fell off a screen.
Choosing a tool: three honest options
There are three real categories here and they suit genuinely different situations. The right question is not which is best, it is where is your problem actually happening.
A full helpdesk — Gorgias, eDesk, Zendesk, Re:amaze. The right answer when your problem is inbound volume. If order issues arrive as email, chat, SMS and social DMs, if you need a shared inbox with macros, assignment rules and response-time targets, and if you have people whose job is answering customers, buy a helpdesk. Nothing else does that job as well. The trade-off is not really cost, it is fit. The pricing models differ more than people expect — Gorgias charges by ticket volume and not per agent at all, while Zendesk, Freshdesk and Help Scout price per seat — but either way the constraint is the same. A helpdesk is a customer messaging tool, and the warehouse lead who checks how something was packed is never going to live in one, whether or not their seat is free.
A customer-facing returns or complaints portal — Loop, AfterShip Returns, and similar. The right answer when your problem is intake. If you want shoppers submitting the issue themselves with photos attached, in a structured form, without a human transcribing it — that is what these do. They are strongest on returns and exchanges specifically. They are generally weaker at the messy internal half: the supplier claim, the warehouse investigation, the follow-up that spans three weeks.
A lightweight internal tracker — this is where our own app, IssueDesk, sits. The right answer when your problem is your team losing track internally. The customer conversation is already handled fine — by email, by phone, by a helpdesk you already own. What is broken is that nobody can say who owns issue 4021 or what it is waiting on. An internal tracker lives in the Shopify admin, attaches issues to orders, gives each one an owner and a status, and keeps the history in one place.
Be honest about which describes you. If most of your problems arrive as inbound messages and you have no shared inbox, a tracker will not fix that and a helpdesk will. If your customers are handled but your team is dropping the internal follow-through, a helpdesk is a large amount of machinery aimed at the wrong half of the problem.
Plenty of stores end up running two: a helpdesk for the conversation, a tracker for the case. If you are still weighing whether a helpdesk is the right shape at all, we make that case in detail here.
Start with the process, not the software
Write down your stages. Assign one owner per issue. Log evidence the day it arrives. Track claims separately from refunds. Do that in a spreadsheet for a month and you will learn more about your actual failure rate — which supplier, which carrier, which product — than any tool will tell you on day one.
Then, if the spreadsheet is straining, pick the category that matches where your problem lives.
The order issue log, as a spreadsheet
Every stage, category and closure condition in this guide, already built. Dropdowns for stage and category, a chase-date column, and a monthly review tab that counts your five numbers for you — including the one nobody tracks.
- Highlights any issue where the customer was made whole but the claim was never filed
- Flags an Awaiting row the moment it passes its chase date
- Opens in Excel, Numbers or Google Sheets
And whichever category that turns out to be, the month of manual tracking is not wasted work. It is the requirements document you hand to whatever you buy next.
Common questions
Can you track damaged orders in Shopify natively?
Partly. Order notes hold the detail and tags make damaged orders countable, which is genuinely useful at low volume. What neither does is assign an owner, hold a status that moves, or keep a history that survives being overwritten. Past roughly ten issues a month, the case ends up living somewhere else anyway.
What is the best way to track damaged orders in Shopify?
Define the process before you pick a tool. Capture the issue against the order, give it exactly one named owner, set a status that has to move, log the evidence the day it arrives, and track the customer refund separately from the carrier or supplier claim. A spreadsheet running that process beats software running no process.
Should I use a helpdesk, a returns portal, or an internal issue tracker?
It depends where the problem actually sits. Inbound message volume is a helpdesk problem. Getting customers to submit issues with photos is a returns portal problem. Nobody internally knowing who owns an issue or what it is waiting on is a tracker problem. Plenty of stores end up running two of the three.
Why should the customer refund and the carrier claim be tracked separately?
Because they run on different clocks. The refund or replacement is urgent and measured in hours. The recovery claim is slow, evidence-hungry, and often has a filing deadline near the start. Teams that treat them as one thing make the customer whole, feel finished, and never file the claim.
