You’ve probably seen this story before, even if the details differ each time: a returns backlog that’s been perfectly manageable for months, until one week it triples in size. Suddenly it’s not a backlog, it’s a queue with no end, and it lands on the customer service team’s desk after a barrage of complaints. CS didn’t cause it, but CS has to deal with it anyway, fielding a wall of frustrated customers for a problem that started somewhere else entirely.
That’s something worth talking about. The symptom always turns up in the same place - the inbox - while the cause is almost always sitting further upstream, in a system or a process that nobody’s watching closely enough to catch before a customer does. Or something that hasn’t been cleanly mapped out, so no-one truly understands. Or has the time to fix.
CS is usually downstream of something else
At record store Rough Trade, the volume of “where is my order” queries in the inbox was a genuine drag on the team, until they built an inbox classifier that now resolves around two-thirds of enquiries automatically by checking order status directly. This was work we wrote about in more detail after OX2, alongside the returns platform they purpose-built.
The point isn’t the specific numbers, though. It’s the way they fixed it. They treated a CS problem as a systems and process problem first, and the CS burden dropped as a result, rather than the other way round.
Different teams catch the same gap at different times
At Bluebella, discrepancies between the storefront, the ERP system and the warehouse used to fall through the cracks and get caught reactively by whichever team happened to notice first. They built a daily dashboard that flags the mismatch before a colleague or customer has to notice and complain about it. And showcased it at OX2.
That’s the wider pattern across pretty much every brand running more than one system for order fulfilment: the gap gets found at the most inconvenient possible moment, for whichever team is closest to it that day, and it’s rarely the same team twice. One week it’s warehouse ops mid-pick. The next it’s CS mid-inbox. Eventually it’s a brand or PR issue, because enough customers hit the same gap at once.
If someone’s genuinely responsible for watching the systems upstream, most of this never reaches that point at all - and it’s easier to build that watching function now than it’s ever been.
What actually reduces WISMO volume
Not a better help centre article, for a start. What actually moves the number is closing the gap between what the customer sees and what’s true in the warehouse, before they have to ask.
That looks like proactive status updates instead of reactive lookups. Order tracking that actually shows a customer where their order is, in real time, rather than a static “processing” screen or an “order is in progress” that means nothing.
And if they do reach out, customer service systems should be properly integrated with order and fulfilment data, so customers get a real answer immediately that recognises who they are and what they ordered, and the customer service team are enabled to do their jobs properly without chasing down the ops and logistics team.
Importantly, WISMOs should not turn into a request for the customer to jump through hoops or a queue with a two-day SLA before a human even looks at it. That’s not the experience anyone’s aiming for, and it’s entirely avoidable with the right plumbing upstream.
The real cost of the tax
Every hour a CS team spends manually chasing a warehouse booking or explaining a sync error is an hour not spent on the customer interactions that actually need judgement. That’s the WISMO tax - not the query itself, but the fact that a systems problem gets paid for, every single day, out of a team’s capacity to do the part of the job that matters.
Fix the upstream reconciliation, and the WISMO volume mostly takes care of itself. Don’t just add headcount to answer the same broken question faster.
If this resonates, commercethinking.com