Most stores do not have an order-issue process. They have a person who is good at order issues.
That works, right up until that person is on vacation, or two problems land the same afternoon, or someone else answers the email. Then you discover the process was never written down — it lived in one head, and heads do not scale or hand over cleanly.
This is a workflow you can adopt on Monday. It is tool-agnostic: it works in a spreadsheet, in a project board, or in software built for it. Nothing below requires you to install anything.
What breaks the moment a second person is involved
One person handling everything has no coordination cost. Every problem below appears the instant there are two.
No single source of truth. The customer’s email is in one inbox, the warehouse’s answer is in Slack, the carrier claim reference is in someone’s sent folder. Reconstructing a case means asking three people.
Duplicated outreach. Two people contact the same supplier about the same broken order, twenty minutes apart. It looks disorganized from the outside — because it is.
Dropped follow-ups. The classic. Everyone assumed someone else was chasing it. The customer discovers this before you do.
No visibility. The founder cannot answer “how many damaged deliveries did we have last month, and which supplier?” without an afternoon of archaeology. So nobody asks, and a genuine pattern goes unnoticed for a year.
Every one of these is a coordination failure, not an effort failure. Coordination failures are fixed with process.
Define the lifecycle
An order issue is a case that moves through stages. Five is enough. Fewer and the status stops being informative; more and nobody maintains it.
The important discipline is not the names — it is that each stage has a condition for entering it and one person responsible for moving it on.
| Stage | What it means | What must be true to move on |
|---|---|---|
| Reported | Issue is logged against the order. Customer has been acknowledged. | Order linked, category assigned, owner named, customer told you are looking into it. |
| Investigating | You are establishing what happened. | Evidence gathered — photos, packing record, tracking history. You know whether this is carrier, supplier, or internal. |
| Awaiting | Blocked on someone outside the team — customer, supplier, or carrier. | The blocker is named, with the date you asked and the date you will chase. |
| Resolving | The fix is in motion: replacement shipped, refund issued, credit applied. | Customer has been told exactly what is happening and when. |
| Closed | Customer resolved and the recovery claim settled or written off deliberately. | Both halves are done. Not one. |
Two rules make this work.
“Awaiting” must always name the blocker and a chase date. Without it, “Awaiting” becomes the drawer where cases go to die. A case that has been awaiting a supplier for eleven days with no chase date is not blocked, it is forgotten.
“Closed” requires both halves. The most common process failure in ecommerce is closing a case when the customer stops being unhappy, while the claim against the carrier is still unfiled. You resolved the complaint and paid for it yourself.
Two variations are worth knowing about, because you will meet them the moment you look at software. Some tools split Awaiting by who you are waiting on, making Awaiting Customer and Awaiting Vendor separate stages. That is the same discipline with the blocker encoded in the status rather than written into a field, and it is worth adopting if your team routinely waits on both. Other tools give the recovery claim a status of its own, so a case can sit at Claim Filed while the customer side is already resolved. Treat that as a good sign: it means the second closure condition above is built into the tool rather than left to somebody remembering it.
Ownership: one name, always
One named person owns each issue at every moment of its life. Not a team, not a rota, not “support.”
One owner, always. If an issue exists without a named owner, that is a bug in your process. The owner is not necessarily the person doing the work — they are the person accountable for the case moving.
Handoff is an action, not an assumption. Passing an issue means changing the owner field and saying so. “I mentioned it to Sam” is not a handoff. Sam has not accepted anything.
The owner changes when the stage changes, if the work moves. If the warehouse is investigating, the warehouse lead owns it. When it returns to customer resolution, ownership returns to support. Written down, out loud, each time.
One person reviews unowned and stale issues weekly. Ten minutes. Anything with no owner, or no movement in seven days, gets one or the other assigned. This single habit catches most of what would otherwise be lost.
The failure this prevents is the expensive one: nobody drops a case on purpose. They drop it because they believed it belonged to someone else.
Categorize so the data means something
Category feels like admin overhead on issue one. By issue fifty it is the most valuable field you have, because it turns a pile of anecdotes into evidence you can put in front of a supplier.
| Category | Use when | Typically recoverable from |
|---|---|---|
| Damaged in transit | Item left intact, arrived broken. Packaging usually shows it. | Carrier |
| Missing item or parts | Order incomplete — a component, a piece of a set, hardware. | Supplier or internal fulfillment |
| Wrong item | Customer received something they did not order. | Internal fulfillment |
| Quality defect | Arrived intact but faulty, flawed, or not to standard. | Supplier |
| Late or lost delivery | Never arrived, or arrived far outside the promised window. | Carrier |
Keep it to five or six. Long category lists get miscategorized, and bad data is worse than none.
The reason this matters: “damaged in transit” concentrated on one carrier and one lane is a conversation with that carrier. “Quality defect” concentrated on one supplier and one SKU is a conversation with that supplier — and a very different one if you can say fourteen of the last two hundred units, here are the photographs rather than we feel like these break a lot.
Category is what converts a customer service cost into supplier leverage.
Separate the resolution from the claim
This deserves its own section because it is conflated constantly and it costs real money.
The customer resolution is the refund, replacement, or reship. It is urgent, it should happen fast, and its clock is measured in hours and days. The customer does not care whose fault it is and should not be made to wait while you find out.
The recovery claim is what you file with the carrier, supplier or insurer to recover the cost. It is slow, procedural, evidence-hungry, and its clock is measured in weeks — often with a hard filing deadline near the start. Carrier claim windows for visible damage are frequently short and unforgiving.
They must run in parallel and be tracked separately. The two-clock diagram in our damaged orders guide lays out why the second clock is the one that quietly costs you money.
The failure mode is always the same. The customer gets a fast replacement, thanks you, and disappears. The case feels resolved, so it gets closed. The claim was never filed, or was filed and never chased. Multiply by a year of orders and you have a number worth caring about — one that is invisible because each individual instance felt like good customer service.
Practically: every issue carries two closure conditions. Customer resolved, yes or no. Claim settled, written off deliberately, or not applicable. Nothing closes on one.
What to review monthly
Half an hour, once a month. Five numbers.
Volume by category. The shape of your problem. If “damaged in transit” is 60% of issues, that is a packaging or carrier project, not a support project.
Volume by supplier. Normalized by units shipped — raw counts just tell you who your biggest supplier is. A supplier at three times the average defect rate is a commercial conversation.
Volume by carrier and lane. Damage concentrates in specific routes and handoffs far more than people expect.
Time to resolution. Median, not average — one nightmare case will skew a mean and hide a healthy operation.
Recovery rate on claims. Of the cost you were entitled to recover, how much did you actually get back? This is the number nobody tracks, and it is usually the one with the most money attached.
That last pair is where this stops being admin. Walking into a supplier review with 4.1% of units from you arrived defective last quarter against 1.2% across our other suppliers, here are ninety documented cases changes the conversation entirely. That is a negotiation, and you can only have it if somebody categorized the issues at the time.
Rolling this out
A short adoption checklist. It takes about a week of mild discipline before it stops feeling like extra work.
- Agree the five stages and write them somewhere the whole team can see. Do not customize them yet — run the defaults for a month.
- Pick your categories. Five or six. Write one sentence defining each so two people categorize the same issue identically.
- Decide where issues live — one place, and only one. A spreadsheet is a fine answer on day one.
- Name a default owner for issues that arrive without an obvious home, so nothing sits unowned for even an hour.
- Set the weekly review. Ten minutes. Unowned issues, stale issues.
- Set the monthly review. Thirty minutes. The five numbers above.
- Backfill nothing. Start with new issues only. Retrospectively reconstructing three months of cases is how good processes die in week one.
- Revisit after 30 days. Now customize — the stages and categories that annoyed your team are the ones to change.
The process is the asset. Whether it lives in a spreadsheet, a project board, or dedicated software matters far less than whether it is written down and followed by everyone.
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
If you would rather it lived in the Shopify admin alongside the orders themselves, our app IssueDesk implements this workflow natively — but the workflow above stands on its own, and a spreadsheet that everyone actually updates beats software that nobody opens.
Common questions
How many stages should an order issue workflow have?
Five: reported, investigating, awaiting, resolving, closed. Fewer and the status stops telling you anything; more and nobody maintains it. What matters is not the names but that each stage has a condition for entering it and one person responsible for moving it on.
Who should own an order issue?
One named person, at every moment of the case. Not a team, not a rota, not support in general. The owner is not necessarily the person doing the work, they are the person accountable for the case moving. Nobody drops a case on purpose; they drop it because they believed it belonged to someone else.
How should I categorize order issues?
Five or six categories, each with a one-sentence definition so two people classify the same issue identically. Damaged in transit, missing item or parts, wrong item, quality defect, and late or lost delivery covers most stores. Long category lists get miscategorized, and bad data is worse than none.
When is an order issue actually closed?
When the customer is resolved and the recovery claim is settled or deliberately written off. Closing on the customer alone is the most common and most expensive process failure in ecommerce: you resolved the complaint and quietly paid for it yourself.
