A share of the calls you take are settled before you answer them. Not hard. Settled. Whatever you do in the next eleven minutes, the caller is going to hang up without the thing they rang for.
Training rarely covers those, because there is no resolution path to teach. So agents improvise, and improvising under pressure is how people end up promising things nobody can deliver.
Two of these turn up constantly in technical support. They are worth thinking about before you meet them rather than during.
The known bug with no fix date
Engineering already has it. There is no target date, because nobody internally has one either.
The caller wants a date anyway. You have been handed some version of “I don’t have a timeline available”, and it collapses on contact, because they simply ask again. Then they ask when somebody will know, and now you are making it up.
The thing that unlocks this call is realising what is actually being asked.
Most people demanding a date have already concluded that no date exists. What they are testing is whether you are hiding one. They think there is information in the building that is being kept from them, and the demand is how they check.
So respond to the test rather than the question. Tell them straight that no repair date has been set, and that support would learn of any scheduled patch ahead of customers.
That is the entire move. You have not concealed anything, and you have just said so out loud, which is the reassurance they were actually fishing for.
Look closely at what that sentence avoids. No callback is offered. No notification is committed to. It reports the boundary of your own information and nothing more, so it costs you nothing and ties you to nothing.
Be wary of the warmer-sounding version. Say they will be first to hear and you have made a commitment. If no process exists behind it, you have just made one up. A week later you are the agent who said someone would ring, and nobody rang.
When the fault is not in your product
Their broadband. Their hardware. A router bought elsewhere. A setting they changed last month. Whatever it is, nothing in your toolset touches it.
What makes this call hard has nothing to do with you. They have almost certainly been passed along at least once already, so anything resembling another handover confirms the suspicion they arrived with, which is that nobody intends to own this.
The instinct is to establish the boundary early and clearly. Resist it. Do not declare the limit. Demonstrate it.
Work through the problem as far as your product genuinely reaches, and do it for a real reason rather than as performance. You are trying to understand precisely where the incompatibility sits. Take them with you while you do.
By the time you reach the edge, two things have shifted.
They have seen the attempt, so the limit becomes a place the two of you reached together instead of a rule you recited up front. And you now understand the failure well enough to say something specific about it.
That second part is the difference between a handover and an abandonment. Give them the question to put to the other company, or name precisely which component is clashing with which, and they leave holding something. If all you have is a phone number, they leave with nothing.
What both calls have in common
In each one, the call ends without the thing the customer wanted. No wording changes that, and hunting for wording that does is precisely how agents talk themselves into commitments they cannot keep.
What you are actually managing is narrower. Was the limit arrived at, or was it announced? That is the whole of your influence on calls like these, because the outcome was never yours. The only part that was ever in your hands is whether they watched you establish it.
Why this matters more than it looks
Calls with no solution are the ones that damage agents over a long period, and not because they are stressful in the moment.
They are the calls where you feel useless, and feeling useless repeatedly is what pushes people into one of two habits. Some start over-promising, because a promise makes the call end pleasantly and the consequence lands on a future shift. Others go flat and procedural, because detachment is easier than caring about an outcome you cannot influence.
Neither is a character flaw. Both are what happens when nobody explains that a portion of the queue is unwinnable by design, and that being unable to fix an unfixable thing is not a performance problem.
Knowing which calls those are, before you pick up, is most of the protection.
A way to prepare
Write down the two or three recurring calls on your account where the honest answer is that the thing does not exist. Every account has them. For each, work out what you can truthfully say about what you know and when you would know more, and what genuinely useful information the customer can leave with.
Do that once, calmly, away from the phone. It is considerably better than composing it at minute nine with somebody shouting.
Handling the unwinnable calls well is one of the quieter things leads notice, and whether that counts for anything depends on whether your floor actually rewards the work.
The fuller treatment, including the situations specific to a technical support queue and the wording that holds up when a caller pushes, is in the Technical Support Agent Playbook, written for the agent taking the call.