Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> support - whether external customers or internal stakeholders - is a game of hot potato

I’d like to shift this a little:

Support who’s primary metric is handle time is in a game of hot potato.

From a business perspective the managers and leaders always feel like there’s too many fires which inevitably leads to either pressure on front-lines to “go faster” and “stop doing unnecessary work” (aka “taking time away from the fires”) or some level of management that’s intentionally blocking higher-ups from seeing those fires so that they look like they are managing the department well (and in this case not only is there the same pressure on the front-lines, but there’s additional pressure about not reaching out to anyone except through that manager.

When the primary metric is handle time, the issues pile up, there’s never enough people to handle it, and the business slowly sinks as no one with a budget sees the “ounce of prevention [that can prevent a pound of cure]”.

However: If the metric is minimum number of departments an issue touches before it’s resolved it’s a whole different thing. Suddenly playing hot potato is a problem and “problem ownership” is praised. There are other metrics too that produce different support cultures (and sometimes different games), but the reason hot potato is so popular is that those other metrics all require top-level execs to be comfortable with spending now to save down the road.



This seems difficult to resolve because staff time is limited and you can’t do everything. That’s why tasks need to be prioritized. But how?

Distributed prioritization seems like a problem; you can get priority inversion if you’re not careful.


How is a question who’s edges are unique to the company but if you’re coming in to a situation like that one generally-solid approach is to accept that things will suck for a while, and might even be worse short-term, the prioritize chipping away at the underlying causes.

Something like reducing staff ticket time by 20%, then using that 20% for feedback, strategy, and structure. Some (maybe even most if you’re lucky) of the front-line staff will have enough experience and insight to be invaluable here (though it is likely they won’t have the language yet to express it in ways that make sense to management). As the company goes through the process of communication, discovery, awareness, planning, and execution (preferably with a tight feedback loop) some of the underlying causes will be addressed, the front-line pressure will ease off, the cascade effect will see ease-off in other departments as well, and that 20% can go down to 5% or even 0 (not recommended lol) which will further reduce the workload to give longer-lasting relief.

Then with staff time “out of the red” the company can start thinking about what they will do in a fire-free future.


It's a classic triage problem. But "tell them to go away" isn't a triage strategy.


> But "tell them to go away" isn't a triage strategy.

The stubbornness of large organization can be maintained for several hundred years, assuming it exists for that long, so this isn't quite true.


Exactly it. I’d like this as a tshirt that people can wear when consulting on support team management.


lol first they came up with the phone menu. Then they came up with complicated phone menus meant to confuse you and get you to give up. Then they replaced those with voice recognition menus that are straight up infuriating. Then they replaced that with AI that tries to act like it's a person.


All because telling you to GTFO isn't an option. Typical customer support is thus a proof-of-work scheme: to get it, you need to waste some significant amount of time and energy up front.


Problem is once its easier to just bypass all that and find ways to bug higher level employees whose time costs the company siginificantly more. If more people realized that then the regular support would quickly be told to actually solve customers' problems.


> There are other metrics too that produce different support cultures

Could you elaborate?


Not them, but I worked at a University in their IT dept, and our chief metric was solely 'customer satisfaction' (and 'customer' meant 'faculty'). We almost never wanted to pass tickets, because that tended to make the 'customers' upset. They wanted white glove service, and that's what they got.

It also meant that some people had "forever tickets", that were a continuous series of tacked-on asks by the same faculty member. HigherEd IT can be crazy (and crazily-laid back).


I've heard IBM used to be the same, if the customer had an unlimited expense account with them.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: