A customer emails about a delayed order. Your agent replies within the hour, offers a tracking update, closes the ticket. Four days later, the same customer is back, same order number, asking why nothing has moved. You close that one too. The CSAT survey that goes out afterward comes back at 4.8 out of 5, because the agent was polite both times and the second reply came fast.
Nothing in that score tells you the order shouldn’t have needed a second contact at all.
This is the gap between a support team that feels responsive and an operation that is actually under control. CSAT measures how a single interaction felt. It says nothing about whether the underlying problem got fixed, or whether the same customer, or ten others with the same order pattern, will be back next week. The metric that catches this is repeat customer contacts, and most ecommerce operators aren’t tracking it in any structured way.
Why “resolved” and “closed” are not the same thing
A ticket gets closed the moment an agent stops replying, whether or not the customer’s actual problem went away. If the shipment is still stuck in the same warehouse three days later, closing the ticket didn’t resolve anything. It just moved the conversation out of the queue.
Repeat contacts happen for a small number of recurring reasons, and almost none of them are about agent tone or response speed:
- The first reply didn’t actually answer the question, so the customer has to ask again in different words.
- The promised fix (replacement dispatched, refund processed, ETA confirmed) didn’t happen on the timeline given, so the customer follows up to check.
- The issue was passed to a different department or platform and nobody told the customer it was still open.
- The root cause (a warehouse delay, a defective SKU, a payment gateway error) wasn’t fixed, so new customers with the same order pattern start contacting for the same reason.
That last point matters more than it looks. A repeat contact isn’t always the same person contacting twice. Ten different customers messaging about the same shipping delay is the same signal as one customer messaging ten times: an unresolved operational issue generating support volume instead of getting fixed.
CSAT can’t see any of this, because CSAT is scoped to one interaction at a time. A support team can hold a 95% CSAT average while quietly absorbing a growing volume of repeat traffic tied to two or three unresolved backend issues. The survey looks healthy. The workload keeps climbing. Nobody can say exactly why, because nothing in the reporting connects one contact to the next.
What a repeat contact rate actually measures
Repeat contact rate is usually defined as the share of customers who reach out more than once about the same or a related issue within a set window, commonly seven days. Some teams track it by unique customer, others by order, others by topic. It can be measured either as same-issue repeats, where the customer explicitly returns about the same problem, or as time-window repeats, where any second contact within a defined period counts.
For ecommerce specifically, order-level tracking tends to be more useful than customer-level tracking, because the same order can generate contacts from different people (the buyer, then a gift recipient, then a payment method holder disputing a charge) while pointing at the same operational cause.
Published benchmarks vary by contact type and industry, and most of them come from general support-center research rather than DTC ecommerce specifically, so treat any range as a rough compass rather than a target. One industry summary puts order and billing-related repeat contacts for retail and ecommerce in the 5 to 12 percent range within a seven-day window, with spikes during high-volume periods when staffing and proactive updates don’t scale with order volume. If your number is well outside that range, the more useful question isn’t “is this bad” but “what specific workflow is producing it.” Yotpo
A tracking method that fits inside a spreadsheet
You don’t need a helpdesk platform overhaul to start seeing this. A single tracking sheet, updated as tickets close, does the job at the volume most solo operators and small teams are working with.
The minimum viable structure is four columns, plus a fifth for resolution status:
| Field | What it captures |
|---|---|
| Order ID | Links every contact back to the specific order, not just the customer |
| Contact reason | The stated reason for this specific message (delay, defect, refund status, wrong item) |
| Root cause | Why the reason actually happened (warehouse backlog, no proactive update sent, payment error, SKU-level defect) |
| Contact count | Running total of contacts tied to this order ID |
| Status at close | Genuinely resolved, or “closed pending resolution” |
The distinction between “contact reason” and “root cause” is where most trackers fall short. Contact reason is what the customer typed. Root cause is what your operation did or didn’t do. “Where is my order” is a reason. “No proactive delay notification was sent when the warehouse fell behind” is a root cause. Only the second one tells you what to fix.
Once an order hits a second contact, flag it. Once it hits a third, that order needs manual review outside the normal queue, because something in the fulfilment or communication chain has broken down badly enough that routine replies aren’t closing the loop.
Reviewed weekly, this sheet answers three questions no CSAT dashboard can:
- Which specific SKUs, carriers, or workflows are generating repeat volume.
- Whether repeat contacts are concentrated in a short window after order placement (a fulfilment problem) or spread out over weeks (a product or expectation-setting problem).
- Whether the same root cause is showing up across multiple orders, meaning it’s systemic rather than a one-off.
That third point is usually the most expensive one to miss. A single defective batch or a warehouse handoff gap can sit undetected for weeks if every resulting ticket gets logged and closed individually, with nothing linking them together. Nine thousand and twenty-five orders processed over nine months of one operation showed the same pattern: contacts that looked unrelated when reviewed ticket by ticket turned out to trace back to two or three recurring operational gaps once they were tracked by order ID and root cause instead of by ticket.
Closing the ticket is not the same as closing the loop
There’s a habit in support teams, understandable given how ticket queues are usually measured, of treating “closed” as the finish line. Response time and closure rate are easy to report, so they get watched closely. Whether the underlying issue actually stopped recurring is harder to measure, so it gets watched less, if at all.
The fix isn’t more agent training or faster replies. It’s separating two different questions at the point of closing every ticket: did this specific customer get an answer, and did the thing that caused them to contact you in the first place actually get resolved. A ticket can score yes on the first and no on the second, and that gap is exactly where repeat contacts come from.
If you’re not sure where your own operation stands on this, that’s usually the first thing worth checking before anything else.
Take the free 25-question Ecommerce Operations Health Check. It takes about five minutes and shows which operating area (support, fulfilment, communication, or returns) needs attention first, based on where the gaps actually sit rather than a guess.
[Start the Ecommerce Operations Health Check → https://cxopslab.io/ecommerce-operations-health-check/]
Building this into your existing SOPs
A repeat contact tracker only works if it connects to whatever documentation your support team is already using to handle tickets. If your current SOPs don’t specify what counts as a root cause versus a symptom, or don’t require an order ID field on every contact log, the tracker will drift into inconsistent use within a few weeks.
This is the same gap that shows up across most fast-growing DTC support operations: SOPs that describe how to respond, but not how to track whether the response actually fixed anything. Our ecommerce SOP template covers the documentation structure this needs, including the fields that make root-cause tracking possible instead of optional.
Where repeat contacts trace back to a fulfilment handoff rather than a support gap, such as warehouse status not reaching the support team before a customer follows up, that’s a separate workflow problem worth checking against your own warehouse-to-support process.
What to do with this once you’re tracking it
Repeat contact tracking isn’t a reporting exercise for its own sake. Once you have two or three weeks of data by order ID and root cause, the pattern usually points at one of a small number of fixes: a proactive notification that isn’t going out when it should, a carrier or SKU with a disproportionate defect or delay rate, or a handoff between warehouse and support that has no defined owner.
None of those show up in a CSAT score. All of them show up in a contact log that’s actually structured to catch them.
If you’re already tracking response time and CSAT but haven’t looked at repeat contacts by order, that’s usually the fastest gap to close, and often the one that explains why support workload keeps climbing even when individual interaction scores look fine.
Take the free 25-question Ecommerce Operations Health Check. It takes about five minutes and flags which operating area is most likely driving hidden repeat volume in your current setup.
[Start the Ecommerce Operations Health Check → https://cxopslab.io/ecommerce-operations-health-check/]
About CX Ops Lab
CX Ops Lab publishes operational frameworks, SOP templates, and case-study content built from real DTC ecommerce operations, not theory. Every framework was pressure-tested during live operational conditions across Shopify, Shopee, and Lazada at $610,000+ USD GMV scale.
Website: cxopslab.io │ Products: payhip.com/CXOpsLab