Every Wednesday, just before three
A story about who our support systems are really designed to serve, and how to build a team worth the name.
Updated 27th August 2026.
Why most support systems are designed for the wrong person – and how to build a customer support team worth the name
It was a truly remarkable thing to see. Curious in the expression of human creativity for sure, if not a little saddening that this is what the system was making people do. You see, every Wednesday afternoon, a little before three o'clock, a customer support team begin a curious ritual of movement.
The customer cases the team were working on would start moving – not toward resolution as the customer might rightly assume, but sideways, backwards and any direction than where they currently were. An issue would slide from one team's queue into another's, then into a third, then sometimes back where it started. It looked, at least initially, like everyone had been on energy drinks and they were bursting with industry. It was, in fact, the opposite. It was the team aiming to empty their team's queues ahead of the 3pm management reporting snapshot. The goal, it transpired, was to ensure the team didn't have many cases in it's queue. None of the teams cared who's queue the majority of cases were in, so long as it wasn't theirs. After the 3pm report was automatically generated, things went back to normal.
Astonishingly, this charade had been happening for the last 8 months. What a remarkable use of time, energy and attention. Not to mention the affect this was having on the customers. It was like an adult version of pass the parcel, only with the goal of not landing with the parcel when the music stopped. Maybe it's more like musical chairs? Anyway, the customers, and let's be honest, management also, had no idea this was happening. I wonder what the customers would have said if they'd known this was designed into the business they were buying from?
And here's the idea worth playing with, because it's a cracker: nobody in that team had set out to treat anyone badly. Every one of them was decent, capable, interesting, talented, fun, customer focused (yes!) and trying to keep their head down so they didn't get told off. The system, designed by management, was creating this behaviour, and – given what it counted and what it punished – the behaviour made perfect sense.
The people weren't the problem. The report was.
The natural response to a story like this is more training in customer centricity or some other buzzy sounding word about putting the customer first. Or, maybe even a stern word to stop doing it. Or, more likely now, a better dashboard and reporting audit to "tell off" those who avoid being "told off" for having too many cases in their queues. All of that is tempting, but absolutely wrong.
The three o'clock shuffle as I came to name it, wasn't a people problem at all. It was a systems problem affecting the people. Here's a thought experiment. Swap the whole team out and leave the report (plus the repercussions) in place, and the new team will have invented their own version of the shuffle by the following week. The problem wasn't the people, it was the fact the management were aiming to improve how quickly customer's cases are resolved (and tell people off), and reached for the report as an easy proxy. In doing so, they created even more delays and misguided work, which in turn affected how quickly customer cases were resolved. A spiralling problem created by not resolving the most fundamental missing piece in this story.
Every support system is designed for someone – and most are designed for the person reading the report, not the person who needs help. Get that one thing right and most of what follows is minor detail. Get it wrong, and no amount of care on the front line will rescue you.
The measure that ate the service
I've found that support is among the most heavily measured functions in most companies, and among the worst served by its own measurement. The trouble begins the moment a number stops being a signal and becomes a target – and worse, a target hung around an individual's/team's neck at review time.
Tie an arbitrary figure to someone's appraisal and you haven't motivated them to help the customer; you've motivated them to move the figure in the right direction, and only very occasionally are the two the same thing. Issues get bounced. Half-fixes become the norm. Time spent with the customer is cut. Resolutions, from the customer's perspective, are incomplete. The dashboard turns a satisfying green while the customer, somewhere in mild frustration, turns purple. We've all been there on the receiving end of this.
This is not a naive call to stop measuring anything. Far from it. Measure plenty. Measure the cycle time from the minute an issue is raised to the minute it's genuinely resolved – a basic and powerful thing, and staggeringly few teams actually capture.
Measure how often the same problem reoccurs. This bewilders me that teams will scale up, ramp up, train up and report up that they are handling more problems each day, without realising that many of them are merely the same problem rearing it's head frequently. Scaling up to deal with the problem is one approach, but the other is far more effective; address the source problem in the first place. I did this with a company dealing with 1500 calls every Monday because customers had forgotten their log in details. As more customers onboarded, more issues came in. The team ramped up, they were awarded team of the month for dealing with so many cases so quickly. I suggested fixing the root cause. The cheap fix, done in twenty minutes – by adding a self service password process – took the calls from 1500 to zero.
It's therefore wise to solve problems once and for all. Most of what lands in a support queue isn't really a support problem at all; it's the downstream issue of something further up the journey – a confusing signup, a poor tech release, a failed transaction because the instructions weren't clear. So solve it properly on the immediate call – and then go and find whoever created it and ask, kindly, whether it can be switched off at source. A problem turned off upstream never has to be handled again by anyone.
Measure first-contact resolution, which is ultimately what most customers want. I phone up, I get it fixed on that first call. Measure the lifetime value of a customer, the cost of losing one, the reasons for losing customers and the cost to acquire new ones. You'll soon find that it's worth holding on to customers you already have, than spending to replace them with new ones. Measure which customers generate the most support requests; you might find there's a training issue.
But hold those numbers as instrumentation and signals, not ammunition and incentives. They're a map of the health of the service machine – they show you where it's running clean and where it's slipping up a little – and a map is a poor stick to beat the operators with. Metrics belong to the system. They were never meant to belong to a person.
Designed for the customer, or for the report?
Walk into many support functions and you'll find teams buried under tools chosen for what they report rather than what they resolve, processes built to shield managers rather than help customers, a CRM arranged around the comfort of people who never once have to use it in anger – and as an aside, the CRM is likely incorrect too. Each decision was sensible on its own to solve a visibility problem. Stacked together over time though, and used to measure the people rather than the service and they end up pointing the whole function inward, at itself, rather outwards towards the purpose from the customer's perspective.
The correction is rather simple: when you have to choose between internal tidiness and reporting, and the customer's experience, choose the customer. If that means occasionally jumping through a hoop of fire – metaphorically, I should point out – then so be it. Without the customer there's no tidy function to protect and report on in the first place.
Make it easy to reach you. There are few experiences more deflating than needing help and meeting a wall – a phone number buried three menus deep that doesn't even work, a contact form with thirty fields just to get someone to call you back, an epic fantasy gauntlet of "are you quite sure?" or "is this the information you are looking for?" before a human will appear. Add to this now the rage of AI chatbots, where it takes twenty minutes of back and forth before it eventually concedes it can't help you and you'll need to speak to a human. Almost all of these are designed for the company, not the customer.
Cut the form back to what you genuinely need. Leave the number where a worried customer can actually find it.
Support sits downstream of everything
The reality is customer support sits at the bottom of every slope in the business. And that's not meant in a bad way. They are an essential function that often bear the brunt of everything upstream of them.
Every decision, every release, every space between two teams that was never filled, every sale of something that isn't even sold, every quality problem in delivery, everything upstream eventually flows down and arrives, with a thud, on the support desk. Which is why the best support leaders I've worked with spend a remarkable amount of time, energy and attention nowhere near it. They build relationships at the boundaries – with product, delivery, sales, legal, operations – over coffee and in one another's stand-ups, so that a change is something the team is aware of before it lands rather than after it goes off.
They also use staplers, a lot. They staple themselves to customer's issue and follow it on its journey, the entire way through the system. They see where it stalls, where it waits for Dave – who only works Tuesday and Thursday – where it loops back and forth, where is spends three weeks in a queue for a team who have competing goals, where ownership seems bizarrely hard to find. It's an uncomfortable process and the fastest education out there. Because most friction lives exactly in the gaps nobody owns or the waits nobody can really see: the handovers, the queues with no name attached, the competing goals, the lack of reward on the other side of that friction. You can't fix what you can't see, and from behind a dashboard you can't see any of it.
None of this is possible though with a team working in fear, on broken kit, without the information customers assume they already have, without the space and time to support the customer. A good customer experience is built on a good employee experience – that's not ideology, it's the very essence of giving the customer, and the team, what they need.
If the team need a second monitor, a test environment to reproduce a fault, or a quiet room to take a sensitive call, sort it out; the cost is trivial set against a single customer kept, retained and feeling valued. And give them room to mend their own work without escalating every idea upward – they already know what's broken in the process, system and work. This requires a climate in which people are not afraid to do the right thing for the customer.
The human part, which is most of it
For all this glorious talk of systems, the thing a customer actually remembers is a very human thing. How they were made to feel when they were stuck.
So build real relationships – a short message, a call back, a clear explanation of what's happening and why. None of it takes long; all of it lands and the customer will feel it. Where the numbers allow, introduce the people on your team by name, and tell customers what your team actually knows how to do and how they will help. A customer is not a standard unit to be processed through a standard pipe in a standard company. They're not standard at all. They're exceptional – and they can tell, in about four seconds, whether you've noticed. And, isn't your company exceptional too? So why all the standardisation?
Communicate far more than feels reasonable, effectively. Whatever you think you're telling customers, double it, then double it again. People don't much mind waiting; they mind waiting in silence, with no idea what they're waiting for. Tell them what's happening. Tell them what's next. And communicate inward too, because most of the company has no real idea what the support team absorbs in a day.
Then follow through. If an issue can't be solved on first contact, it needs an owner – a real person who'll chase it, push when it stalls, and stay with it until it's done. The worst thing that can befall a customer's problem is a slow meander into a nameless queue while the customer, remember, is still waiting, and feeling this. Ownership stays with whoever picked it up, even if they're no longer the one working on it right now. That's a pretty decent rule.
And – this one sounds obvious and is broken somewhere every single day – don't grumble about customers. A frustrated customer has a problem with your product or service and wants your help, and more often than not the frustration is something the organisation created for them to begin with. Sure, not all customers communicate effectively, they can be rude, angry even, but that's on them, not you. Use communication training to meet those tricky people with grace (you are giving the team that training, I hope). But a team that holds its customers in contempt will never deliver them a good experience, however clever the machinery behind it or how reasonable the scripts they follow are. Customers the reason the whole function exists – not an interruption to it.
What good support actually feels like
When support is working, it doesn't feel awesome and inspiring. It feels boringly reliable and consistent and effective – and boring, here, is a high compliment for sure. Updates arrive before they're chased. Ownership is obvious. Silence is rare. Problems get solved once and stay solved. The team knows the people they serve and the systems they work inside, and from the outside none of it looks like a glossy magazine worthy editorial. That's actually rather the point. Mad energy and hurried productivity in a support function are usually just a system falling over, with people picking up the slack.
Customers don't expect perfection. They expect honesty, effort, consistency and care. Every product breaks eventually; every service has a part that doesn't meet expectations. What a customer remembers is almost never the thing that broke – it's what happened next. Customer support is the very place where trust is either rebuilt or lost, and trust, once gone, is remarkably expensive to buy back. Customer service is, in almost every regard, the real brand of a business.
Instead of thinking "how do we measure the team better?", it might be worth considering who is this system actually for?
Answer that one honestly, and the three o'clock shuffle never gets invented in the first place.
Quick reference – twelve principles for great customer support
1. Build real relationships.
Support isn't something to get through – it's something to engage with. A short message, a follow-up call, a human explanation. None of it takes long; all of it matters.
2. Configure tools for the customer, not the report.
The fastest way to damage a customer's experience is to arrange your CRM, your issue process and your comms around what's easiest for managers. If you must choose, choose the customer.
3. Solve problems once.
Repeated issues are signals, not just demand. Find the upstream cause, document the fix, tell the team and the customer – and where you can, switch the problem off at source.
4. Don't hang metrics on individuals.
Targets tied to a person's review teach people to move the number, not help the customer. Issues get bounced, half-fixes spread, the dashboard greens while customers suffer.
5. Measure to improve the system.
Cycle time, recurrence, first-contact resolution, cost of churn. Use the data to find patterns and where to invest – as signals, never as a scorecard for individuals.
6. Provide a good environment.
A good customer experience is built on a good employee experience. Broken kit, no information, fear – the customer feels all of it. This is climate, not ideology.
7. Encourage continuous improvement.
The team already know what needs changing. Build the climate where they can act on it without escalating every idea, and listen when they surface one.
8. Build relationships with other teams.
Support sits downstream of every decision and release. Know where your work comes from and where it goes, and make friends at the boundaries before the change lands.
9. Staple yourself to a customer issue.
Follow one end to end. Watch where it waits, where it doubles back over and over, where ownership is missing. Most friction lives in the gaps no one owns.
10. Communicate constantly.
Whatever you think you're doing, double it, then double it again, effectively – inside the business and out. People often don't mind waiting if you tell them what they're waiting for.
11. Follow up on everything.
If it can't be solved on first contact, it needs an owner who'll chase it. Ownership stays with whoever picked it up until it's resolved. Never let an issue rot in a queue.
12. Stop all negativity about customers.
Frustrated customers have a problem with your product and want help – a problem the organisation often created. A team that doesn't respect the people it serves can't give them a good experience.
Where this sits in the Atlas
Orientation·Idea to Value·Communication·Creativity & Climate·Learning