The helpdesk ticket nobody owns: bad call audio
Go into your ticketing system and search for background noise. You will find almost nothing — a handful of results, mostly about headsets. Then go and sit in on four hours of your company's calls. You will hear a dog, a leaf blower, an open-plan office, someone's keyboard at a volume that suggests they are angry at it, and at least one person who is completely unintelligible for thirty seconds while they walk somewhere quieter.
Two facts, wildly inconsistent. The gap between them is the most interesting thing in this whole project, because it explains why audio quality is simultaneously one of the most-experienced problems in a modern company and one of the least-funded.
Why the ticket doesn't get filed
It isn't apathy. The category is structurally invisible, for three reasons that compound.
The sufferer isn't the source
The person whose microphone is picking up a construction site cannot hear it. Their audio sounds fine to them, because it is fine to them. The people who can hear it are on the other end, and they have no standing to file a ticket about someone else's laptop — and wouldn't, because it would read as a complaint about a colleague rather than a report about infrastructure.
Nearly every other IT problem is reported by the person experiencing it. This one can't be.
It's social, not technical
“Your dog is on the call again” is an awkward thing to say to a person and an extremely awkward thing to write down in a system that their manager can read. So it gets handled the way awkward things always get handled: a joke, a mute button, and nobody escalating.
The result is a problem that is discussed constantly and recorded never.
It's intermittent by nature
The noise was there on Tuesday because the neighbour was mowing. It isn't there now. Even a motivated user trying to file a good ticket cannot produce a reproduction case, and users learn quickly that tickets without reproduction steps go nowhere. So they stop.
What happens to the tickets that are filed
A few do get filed, and they almost never say what they're about. They arrive as “Teams is bad,” “calls keep breaking up,” “audio issues in meetings.” Read as written, those are network complaints — so they get triaged to the network team, who look at the link, find nothing wrong with the link, and close the ticket as no fault found. Which is correct. It also means the actual problem has now been formally investigated and formally dismissed.
How a real problem becomes a zero in the data
- On the callThe dog, the leaf blower, the keyboard
- The sourceCan’t hear it; sounds fine to them
- The few that are filed“Teams is bad”
- TriageRouted to the network team
- OutcomeNo fault found; closed
- Next timeNo ticket at all
The user, meanwhile, learns the only lesson available: reporting this doesn't help. A week later the same thing happens and no ticket appears at all. The data in your system doesn't just undercount the problem — it actively trends toward zero as people give up, which means the longer the problem persists the better your metrics look.
Where the cost actually lands
Not in IT. That's the whole difficulty. It lands in:
- Sales calls that run long or end early. A discovery call where the prospect asks “sorry, could you repeat that?” four times is not a call that ends in momentum. Nobody attributes it to audio; it gets logged as a slow-moving deal.
- Interviews, in both directions. A candidate who spends an hour straining to hear forms a view of how the company operates. A candidate whose own audio is poor gets read as underprepared. Neither outcome shows up anywhere you'd look for it.
- All-hands and town halls. When a quarter of the audience quietly gives up and reads the deck, the cost is the entire purpose of the meeting, and the feedback form says “good session.”
- Support interactions. Longer handle times and repeated information, on calls that were already someone's bad day.
- The slow tax on everyone. Meetings that need forty minutes taking fifty-five. This is the largest number in the list and the least provable, which is a fair summary of the whole category.
The fix is four lines, and it costs nothing
You don't need budget to make this visible. You need the category to exist and the desk to use it.
- Create a “call audio” ticket category. Today, before any rollout. It takes five minutes and it is the prerequisite for every argument you will want to make later.
- Brief the service desk to route into it aggressively. Anything vague about meetings, breaking up, or not being heard goes in this category first and gets reclassified later if it really was the network. Over-collection is the correct bias when your starting point is near-zero.
- Give the desk three questions. “Was it you they couldn't hear, or them you couldn't hear?” separates microphone problems from output and network problems immediately. “Which app?” tells you whether this is one platform or all of them — the single most important input to whether you need a cross-app layer or just policy configuration. “What was happening around you?” gets you the environmental answer users never think to volunteer.
- Ask one question of the population, twice. “In the last month, how often did background noise disrupt a call?” Once before you change anything, once sixty days after. That's your baseline and your evidence, and it takes ninety seconds of anyone's time.
Do those four things and in six weeks you will have something you have never had: a number. It will be an imperfect number from a category you just invented, and it will still be infinitely more persuasive than the current situation, which is a confident assertion with nothing behind it.
Why this matters more than the tooling
Almost everything else on this site is mechanical — packaging, identity, seat math. That work is well-understood and reliably executed by people who do it for a living. The part that fails is the part before it: getting anyone to agree the problem is real, when the system of record says it barely happens.
A ticket category is not a solution to bad call audio. It's the instrument that lets you find out whether you have a problem worth solving — and, ninety days after a rollout, whether you solved it. Both directions matter. We've seen the category created, measured, and used to conclude that the properly-configured platform levers were sufficient and no purchase was needed. That is a completely legitimate outcome, and it's only available to people who measured.
If you're going to spend money here, spend it on evidence first. The pilot plan has the baseline steps in order, and it starts — deliberately — with this.
No call to action on this one. Nothing in this post requires buying anything, and most of it works better if you do it before you consider it.