Listening for the Problem Behind the Request

Tuesday, 11:05, at Ashgrove Housing. Ravi picks up the desk phone and Gemma from the lettings team says, without a hello, "Can you give me admin rights on my laptop? Only for today." Ravi has been on the desk eight months and knows the answer to that question is no. He can feel the no forming before she has finished the sentence. He also knows that Gemma is not a person who asks for things she does not need. He knows that "only for today" means something is stopping her right now. So instead of the no he says, "I can look at that. What is it you are trying to get done?" There is a pause. "I need to print a tenancy agreement on the big printer and it has vanished from my list, and Dan said you need admin to add a printer." The printer is pushed out by the directory. Gemma needs to sign out and back in. It takes forty seconds, and nobody has to say the word policy.

Listening for the problem behind the request is the habit of treating what the user asks for as a proposed solution rather than as a description of the fault. It means finding the fault before acting on the proposal. The stated request is what the user said they want: admin rights, a new mouse, the server restarted, their mailbox made bigger. The real problem is the thing stopping them doing their work, which the request was their best guess at fixing. The two are the same often enough that technicians stop checking. They are different often enough that the ones who stop checking spend their afternoons doing the wrong thing well. This article is part of our Soft Skills for Technicians series. And it is about the first of the four skills, the one that comes before anything else can go right.

It covers why the request is not the problem and why people ask for the wrong fix. Next come the repeat-back, letting the silence sit, and the closed question at the right moment. It covers the user who asks for the wrong fix and how to redirect them without a no. Then comes listening in writing, followed by listening when the queue is deep. It finishes with a short war story and the listening checklist to copy, in that order.

The Request Is Not the Problem

Nearly every request that reaches a help desk has three layers, and the user usually says only the top one. The top layer is what they asked for. Under it is what they are trying to do, the piece of work that has stopped. Under that is what is actually in the way, which is the fault. "Give me admin rights" was the top layer. "Print a tenancy agreement before the viewing at twelve" was the second. "The printer has dropped off my list after the directory change" was the third, and the fix lived there. A technician who acts on the top layer is answering a question nobody needed answered.

The request is a diagnosis, made by someone who is not a technician, under pressure, with partial information. That is not a criticism of the user; it is a description of the situation. They saw a symptom, guessed a cause, and asked for the thing that would fix the cause they guessed. Sometimes the guess is right, and the request and the problem are the same thing. Often it is wrong in a way that only somebody who knows the system could see, which is the entire reason the desk exists. The user's diagnosis has one great virtue: it tells you where they looked. It is rarely where the fault is.

The cost of answering the request instead of the problem comes in two shapes. The first is doing the wrong thing well: admin rights granted, mailbox enlarged, laptop rebuilt, and the user still cannot print. The second is refusing the wrong thing firmly: "we do not give admin rights", end of ticket. And the user still cannot print and now also thinks the desk is unhelpful. Both outcomes are technically defensible and both leave the tenancy agreement unprinted. The desk was right about the request. It never found out about the problem.

Why People Ask for the Wrong Fix

People ask for the wrong fix because they have been helped before, and the help they got became the request they make. Somebody once fixed their printer by giving them a different driver. So "I need a new driver" is now what printer trouble sounds like to them. A colleague once got a bigger mailbox and stopped getting the warning. So "can I have a bigger mailbox" is what a full mailbox sounds like. The request is a memory of the last fix, offered helpfully, and it is often two faults old.

They also ask for the wrong fix because somebody told them to. "Dan said you need admin to add a printer." Dan is not a technician either, but Dan sounded confident. The user arrives at the desk already holding Dan's diagnosis and slightly committed to it. The request form makes this worse when it asks "what do you need?" rather than "what has stopped working?" It invites a solution and gets one. Why tickets arrive saying "it's broken" covers the form's side of this. The technician's side is to assume that whatever is on the form is a proposal and read it as one.

The third reason is kindness, which is awkward to say but true. Users shorten their story because they think the technician is busy, and they are right. "Can you restart the server" is quicker to say than "every time I open the stock report it sits there for a minute and then says the connection was lost, and it started on Thursday, and Priya has it too". The user is trying to save you time. They are saving you about twenty seconds and costing you about twenty minutes. But they do not know that, and the only cure is to make the full story easy to tell. (The full story is always more interesting than the request. It is also where the fix is.)

The Repeat-Back

The repeat-back is saying the problem back to the user, in their own words with at most one of yours added, before you touch anything. "So the big printer has disappeared from your list since this morning, and you need it for an agreement before twelve." It takes ten seconds. It is the single most effective listening behaviour on a help desk. And it is skipped more than any other, usually by people who are already typing. The repeat-back does three things at once. It checks that you heard what was said and tells the user they were heard. It gives them a chance to correct you before you spend ten minutes being wrong.

The correction is where the value is, and it comes in three forms. "Yes" means proceed. "No, actually" means you had the wrong problem, and you have just saved yourself the time you would have spent on it. "Yes, and also" means there was a second sentence the user had not got to. It is nearly always more useful than the first. "Yes, and also it only happens on the agreement template" turns a printer fault into a template fault in one breath. A repeat-back that only ever gets "yes" is either very good or is not leaving room for the other two. Listen to how fast you move on.

Keep the repeat-back short and keep it in their words. "So your print spooler is failing to enumerate the directory-deployed queue" is not a repeat-back. It is a translation, and it tells the user that their words were wrong and have been replaced. Say it the way they said it, add one technical term if it genuinely helps them later, and stop. In writing, the repeat-back is the first line of your reply. For example: "The big printer has dropped off your list since this morning and you need it before twelve; here is what I am doing." Written or spoken, it goes before any action. The technician who does it last is doing it for themselves rather than for the user.

Letting the Silence Sit

After the repeat-back, stop talking, and keep stopping for about two seconds longer than is comfortable. The user will fill the silence, and what they fill it with is usually the sentence they left out. It might be the detail that embarrassed them or the thing they tried that made it worse. It might be the fact that it also happens to the person at the next desk. The second sentence is the real one. The first sentence was the one they had prepared.

Technicians fill the silence because silence on a phone feels like failure, and because the queue is counting. The urge is to say "right, let me have a look" and start clicking. That ends the user's turn and closes the door on the second sentence. Resist it for a count of two. On a chat, the equivalent is not sending the next message until the user's typing indicator has stopped, and then waiting once more. At a desk-side visit, it is looking at the screen rather than the keyboard, with your hands off both. The silence costs two seconds. The sentence it produces is often worth the rest of the call.

There is a version of this for the end of the conversation too. "Is there anything else?" gets "no" almost every time, because it is a question that invites no. "What else has been annoying you?" asked with a pause after it, gets the small fault the user had decided not to bother anyone with. That is frequently the early warning for a bigger one. The queue will not thank you for the second question. The user will, and the problem record will, eventually.

The Closed Question at the Right Moment

An open question is one the user can answer in their own way, at any length: "what happens when you try to print?" A closed question is one with a short fixed answer, usually yes or no or a single fact: "is it the big printer by the lifts?" Both are necessary, and the skill is in the order. Open questions first, to find out which problem you are looking at. Closed questions once you know, to pin down the specifics without making the user tell the whole story again. Most listening failures on a desk are a closed question asked too early.

The closed question too early narrows the conversation to the thing the technician already assumed. "Have you restarted it?" asked first tells the user two things: that the technician has a theory, and that the user's story is not needed. The user answers yes, and the theory is tested. The fault, which was never about restarting, is still there. Now the user has stopped volunteering information because they have learned the desk works from a list. The restart question is a fine question. It is a terrible first question.

The open question too late wastes time at the other end. Once you know it is the directory-deployed printer, "tell me more about your printing" is no longer useful. At that point, what you need is "which printer, which document, and has anyone else at your desk got the same?" Those questions are closed and quick. The table below sets out the stages and the kind of question that belongs in each. It is not a script. It is the order in which the two kinds of question do the most good.

The User Who Asks for the Wrong Fix

When the request is wrong, the move is to redirect without a no. The sentence that does it is "I can look at that; before I do, what are you trying to get done?" It does not refuse the request. It does not question the user's judgement. It simply opens the second layer. Once the second layer is open, the request usually dissolves on its own. That is because the user wanted the agreement printed, not the admin rights. Admin rights were only ever Dan's idea. Ravi never told Gemma no. He never had to.

Never ask "why do you want that?", even kindly. It sounds like a challenge. Dan has already told the user that this is what they need. The user will defend the request instead of describing the problem. "What are you trying to do?" asks about their work. "Why do you want that?" asks about their reasoning, and people guard their reasoning. The difference is three words and the whole temperature of the call.

Sometimes the wrong fix is also a risky one, and admin rights is the usual example. Here the real problem matters twice. Solving it makes the user happy. It also makes the request go away without a refusal. If the request survives the real problem being solved, if Gemma can print and still wants admin rights for something else, then you are in a different conversation. The series on saying no professionally owns that one. Most of the time it does not survive. The request was a means, and the end has been met.

The honest edge is that the request is sometimes right. The person who asks for a new mouse because the scroll wheel has stopped needs a new mouse. A technician who responds to "can I have a new mouse" with "what are you trying to achieve?" is being insufferable. The test is cost: if the request is cheap, reversible and plausibly the fix, do it and ask one closing question. If it is expensive, risky, or the third time this month, find the problem first. Listening is a skill, not a ceremony, and a skill knows when it is not needed.

Listening in Writing

A ticket is listened to as well as read. And the first rule is to read all of it before deciding what it is about. The subject line is the request. The body is where the problem hides, often in the last sentence, after the user has worked up to it. "Need admin rights" as a subject and "the big printer has disappeared and I have a viewing at twelve" buried in the fourth line is the same ticket as Gemma's call. A technician who triaged it from the subject would have sent it to the access queue. Translating the vague ticket is the craft of reading a thin ticket for what it means. The discipline of asking for everything once, rather than in five replies, is gathering the right information up front. This article leans on both rather than repeating them.

Written listening leaves a trace the spoken kind does not, and the trace is worth making deliberately. When the real problem turns out to be different from the request, write it down in one line. Put it where the next technician will see it before they see the subject: "Request was admin rights; actual problem is the directory printer missing after sign-in; fixed by sign-out and in." In QuerySolv that line is an internal note on the ticket, invisible to the requester and read by whoever picks it up next. Most tools have an equivalent. Without it, the next person reads "admin rights", sighs, and starts the whole conversation again.

Listening in writing also means hearing the request that arrived by a side door. The hallway version of Gemma's call is "can you give me admin rights?" said over a partition. The honest answer is the same one Ravi gave. Follow it by logging the real problem as a ticket on the spot so that it exists. A desk where the hallway request, the chat message and the e-mail all become the same kind of ticket in one queue is a desk that can listen to all of them. See the hallway request, handled well, the article for that door.

Listening When the Queue Is Deep

Listening is the first thing to go when the queue is deep. It is the wrong thing to drop, because the time it saves is larger than the time it costs. A proper listen, repeat-back, pause, two open questions, costs about fifty seconds. Answering the request literally and discovering ten minutes later that it was the wrong request costs ten minutes and a second contact. On a bad day the fifty seconds feel unaffordable. They are the cheapest fifty seconds in the afternoon.

The pressure is real, though, and it is worth naming so that it can be resisted on purpose. A deep queue makes the technician want to close contacts, and the fastest way to close a contact is to do what was asked. The desk's own numbers often reward it: a granted request is a resolved ticket. And the reopen three days later is a separate line on a separate report. Nobody designed the queue to punish listening. It simply does, slightly, every day, and the technician has to decide that the user's problem matters more than the counter. The counter has never once printed a tenancy agreement.

There is a middle path for the genuinely bad hour, and it is the repeat-back on its own. If there is time for nothing else, say the problem back and wait two seconds. Those twelve seconds catch most of the wrong requests, because the "no, actually" and the "yes, and also" arrive in the pause. The open questions and the closing question can be skipped once in a while. The repeat-back cannot, and a desk that teaches one listening behaviour should teach that one.

A Short War Story: The Admin Rights at Harbourview Clinic

At Harbourview Clinic a ward manager called Beatriz raised a ticket asking for administrator rights on the ward laptop "to install the label software". The desk declined it the same afternoon with a polite line about policy. Beatriz escalated that to the clinic manager, who escalated it back to the desk lead. The argument about whether ward managers could have admin rights ran for three weeks across eleven messages and two meetings. During those three weeks the ward wrote its specimen labels by hand. That was because the ward's label printer had been replaced and the new one had never been mapped to the laptop. Nobody on either side had asked about that real problem. A colleague had told Beatriz that "installing the software" was how you got a printer back. A technician called Omar finally visited the ward to argue the policy in person. Omar asked "what are you trying to print?" on his way through the door. Omar had the new printer mapped in nine minutes. The clinic counted the cost as three weeks of handwritten labels on a ward, a formal complaint from the ward manager, and two meetings nobody needed to attend. The lesson was written into the desk's checklist the following week. The request had been answered correctly on the first afternoon. The problem had not been heard until the fourth week.

The Listening Checklist

The checklist below is the one Harbourview's desk wrote after the labels, and it is short enough to sit under a monitor. It runs in order. The three layers are the thing to find, and the behaviours are how to find them. And the two lines at the end are what goes in the ticket so that the listening survives the call. Use it on the phone, in chat, at the desk and on a written ticket, where the repeat-back becomes the first line of the reply. The point of writing it down is not that technicians forget to listen. It is that under load everyone forgets to listen, and a card is cheaper than a complaint.

THE LISTENING CHECKLIST — BEFORE YOU TOUCH ANYTHING
Ticket: ________   Channel: phone / chat / e-mail / form / walk-up

THE THREE LAYERS (find all three)
  What they asked for:        ______________________________
  What they are trying to do: ______________________________
  What is actually in the way:______________________________

THE BEHAVIOURS (in this order)
  [ ] Repeat the problem back in their words, before acting
  [ ] Wait two seconds; let the second sentence arrive
  [ ] Ask one open question: "what are you trying to get done?"
  [ ] Ask closed questions only once you know which fault it is
  [ ] Before acting: "if I fix that, is it the whole problem?"
  [ ] After the fix: "what else has been annoying you?"

IF THE REQUEST IS THE WRONG FIX
  [ ] "I can look at that; before I do, what are you trying to get done?"
  [ ] Never "why do you want that?"
  [ ] Solve the real problem first; then ask if the request still stands
  [ ] Cheap, reversible, plausible request: just do it, ask one closing question

IN THE TICKET (for the next technician)
  Request as stated: ______________________________
  Real problem found: ______________________________   (internal note, one line)

Ravi's ticket for Gemma reads, in its entirety: "Asked for admin rights. Actual problem: directory printer missing after this morning's change; sign-out and in restored it. Told her the sign-out step for next time." It took him longer to write than the fix took to do. The next week two more lettings officers rang about the same printer. The technician who took the calls read Ravi's note first and asked no questions about admin rights at all. Each of them was printing inside a minute. Three calls, one listen. That is what the note was for.

Frequently Asked Questions