Frequently, I field technical questions where a user wants a quick and easy fix for a complex problem. I understand the desire for this, however, unless the user has spent some time thinking about their problem, they're often unable to phrase the question in an understandable way. Often, I'm completely lost when the other party is done talking.

I'm afraid my standard response of "I didn't understand anything you just said" gets interpreted as "you must not know what you're talking about". This understandably frustrates the user. How can I appropriately turn the question back onto the user when they've come to me without having done the necessary homework first?

Note: My initial attempt to ask this question was poorly worded, just like my users questions are to me. Asking a clear question isn't easy. I'm really looking for a good strategy to help teach users how to ask better questions. I would like to do this in a way that respects the other party's dignity and desire to learn. This strategy isn't obvious to me because the binary machines I work with are unforgiving when I make a mistake and I'm largely immune to repeated failure. Failure isn't as personal for me and I need a way to help others fail without giving up.

There is great irony in that it's very difficult to express this question in a way that doesn't elicit oversimplified answers of "listen harder" or "maybe you should prompt the user". I've tried these at length. The answers being posted are helping me to understand what my users feels when they bring me their questions. I'm asking for an answer to what I perceive as "x" and receiving and answer to something the perceived as "j".

It's possible that this isn't the correct format for asking such a question as a correct answer might be perceived as completely subjective.

  • 1
    What is the context of these questions? Is it a situation like my aunt asking me to fix her internet because I work on computers, or more like a coworker asking about a specific technical subject you are not as familiar with? I imagine the types of responses are very different depending on the context.
    – shenles
    Nov 9, 2016 at 22:38
  • 3
    I'm voting to close the question as unclear. Are you just asking "How should I ask someone for more details?"?
    – Lilienthal
    Nov 9, 2016 at 23:02
  • @shenles It's more like being constantly ambushed by people who assume you know everything about some arcane problem that only they have. I.e. "Why does my wireless not work on full moons on Tuesdays?" I want to avoid saying "You're nonsensical".
    – Chris
    Nov 10, 2016 at 1:42
  • 3
    @Chris That example seems pretty clear. I'm assuming that "on full moons on Tuesdays" is a placeholder for some anecdote of when the wireless was not working. But at least the query is understandable. Couldn't you just say "I don't know"? Is it your job to maintain the wireless connection in the office? Have other colleagues also had trouble with the connection? etc. At least you have a point to begin with this query. Certainly far from "I didn't understand anything you just said."
    – Brandin
    Nov 10, 2016 at 7:31

8 Answers 8


How can I appropriately turn the question back onto the user when they've come to me without having done the necessary homework first?

First, check you're able to communicate as efficiently as possible: make sure you're doing this face to face if possible, possibly in their work environment where they can show you the problem. Over the phone is usually fine too because that's immediate. You're already working to fix 'crossed wires' and a complex problem. Firing back questions one at a time over email is frustating for both of you.

Second, explore the problem with them: the user doesn't know what 'homework' they need to do and you usually can't tell them what 'homework' to do because it's a complex problem that you've only just now heard about. They may even be under the impression that they've thought it through enough, on the basis that they've spent several exhausting hours in meetings with senior stakeholders agreeing what needs to be done. You may need to remind them that you've not been with them on this journey and they you need to be let in on the process. Normally, I'd start with a couple of open-ended questions and focus in on just the important details as you go, then build up a picture of the problem. For example:

Them: I need you to make these changes to the customer database, it's part of Project Maximum Business Value, so by Friday would be good!

You: OK, those are some quite big changes to an important database. Could you tell me a little more about what you're trying to achieve?

Them: We need to store customer satisfaction information. The Sales Director needs this in the database.

You: OK, so where does this information come from?

Them: The survey we're writing.

You: And who fills it in?

Them: Oh, the survey software is going to do that, the Sales Director has got someone lined up to make that happen but he needs the database changed before he can start work. When do you think you can do that?

At this point, I'd establish your conversation goal, something like:

You: OK, before I can give you a timescale I need to make sure I know exactly what you need so I can ensure it's doing what you want.

... before following up few more things about the process, e.g. how do customers get the survey, who needs the data, what do they use it for, when, etc. and identify who holds the information you'll need to complete the request.

So here, rather than dismissing the problem or the solution, you've identified the intention, some motivating factors, some of the interactions that the request will involve. If you simply demanded a better spec, you would have got more detail on a potentially bad solution, you'd have lost a day on an urgent issue, and you might still not have picked up on some of the ominous things you might have spotted in that exchange. Your customer would also be annoyed at you for saying no and making them do more work. The same principle applies - but faster - in conversation: avoid questions which basically say "explain that again but better": keep the conversation moving: if their answer is unintelligible, break the question down or ask from another angle, or just move on and come back to it.

At this stage you're still not directly challenging them on elements of the plan that might be unwise, you're just identifying where they are for your own benefit. This is important because you need to get a complete picture of what's required, and disagreeing at this point may prevent that. It's often a good idea to finish this part of the conversatin by restating what you've been told to check you understand it correctly.

Third, prioritise the challenges: Once you have an idea of the scope of the issue, you will be able to differentiate between inconsequential details - which you can sort out later - and serious shortcomings which will mean the customer won't get what they want or the solution will threaten more important goals. You will also hopefully begin to have an idea of who is involved and why, so you can identify which problems you can solve right now with the person in front of you and which need input from others.

Fourth, explain the hardest challenge, along with steps to meet it:.

You: You've said that you want to track satisfaction so you can identify which distribution channels work, but that information isn't linked to the customer database at the moment. Can you find me the person in fulfilment who can help make this happen?

Depending on the circumstances, you can also start to come up with solutions to other problems:

You: You're talking about adding satisfaction information to the customer table, but you send the survey after each order, so it actually relates more to the order.

By participating in this process, some users will learn to do some of it for themselves, or at least have enough information that they can answer more of your questions next time. By gathering information in front of them and proceeding to use that information, you'll also demonstrate the value of providing information, i.e. that you can do a better job when you know the background. But that only works if you're transparent about what you're doing and why, and explaining things in term that they are familiar with (and, ideally, in concepts that they will value).

Ultimately, however, you are (I presume) paid to help others solve their problems and some of that means working through the problem with them, and some people will always need that more than others. The more people who form your 'customer base' the fewer opportunities you have to 'educate' them and therefore the more you will just have to accept the inevitability of ill-thought-through requests. Just be sure to let people know you appreciate it at times when they do learn.


Usually something like is what I go with.

I am sorry, I would like to help, but I am not very familiar with NNNN, and I need more context here. Can you please elaborate about AAA, BBB, and CCC.

If you were somewhat paying attention to their description, and they don't completely suck at asking a question, then you should be able to give them a short list of things you need more details on. Giving a list, shows you were trying to follow what they said and were paying attention. Being honest, and saying you want to help, but you don't know things usually gets people to help fill you in. Also, getting them to elaborate means you might just be the rubber duck they needed to figure out the problem on their own.

  • This solution solves a single instance of an ongoing problem. What I really want to know is how to help users accept responsibility for at least taking a single shot at rubber ducking the problem before they pass responsibility off to me. I'm trying to understand how to facilitate a cultural shift, not just solve single instance problems.
    – Chris
    Nov 11, 2016 at 15:49
  • +1 for using the term "context." It shows that you're taking their problem seriously, but puts the onus on them to communicate properly. Nov 11, 2016 at 16:29
  • 1
    I think @Chris is looking for an answer to a much broader issue. Perhaps phrasing the questions as 'How do we, as support personnel, promote a shift in workplace culture where those whom we support take an initiative to employ their own critical thinking abilities PRIOR to petitioning us for assistance?' At present, most users seem to put very little thought into the issue, other than the initial 'I want to' or 'I need to' questions that forms in their mind. How do we promote a workplace where users can think and reason out a problem, using logic, before approaching us with 'verbal vomit'?
    – Joe JMC IT
    Nov 14, 2016 at 15:13

From personal experience I remember an IT guy who responded to "improperly" phrased or non-sequitur questions with a WITHERING DISMISSAL followed by begrudging help, and behind their backs he would then complain at how people were idiots (btw these were all masters/phd biologists). It got so bad that staff would do almost anything to avoid approaching this person with a question unless it was critical emergency. As a result, things broke, stayed broke and people didn't get work done as quickly and efficiently as they could have.

Helping coworkers 1-on-1 isn't like stackoverflow. People should not get "de-merits" for a badly worded question. If you're going to help someone in person just be friendly, patient and empathetic to their concerns any way you can. People can sense when they're being treated with respect and understanding.

The best thing to do to avoid out-of-the-blue questions that don't make any sense is to take some control of the the dialog. Ask for relevant details and context as you need it and don't wait until the person is completely done talking, interrupt when you need to stay with them. If you wait until they're done and you then have to start from the beginning that's frustrating for you and them. Over time, they'll understand your point of view and become better at describing things in a way that's actionable for you.

Larger organizations might do better with help ticket systems, but that's a whole other topic.

Another alternative is to delegate others (even users) to help. This can be as simple as appointing an individual who understands what you need in order to be able to answer a question. Users then go to this person instead of you. The delegate may be able completely solve the problem or at least understand it well enough to rephrase it and tell the user how to approach it with you.

  • "> People should not get "de-merits" for a badly worded question". Yes, they really should.
    – RJFalconer
    Nov 11, 2016 at 11:57
  • @RJFalconer, good luck with that, but it's generally better to give folks the benefit of the doubt especially when speaking across domains. There are consequences for dismissing users.
    – teego1967
    Nov 11, 2016 at 15:37
  • @teego1967 Your suggestions are pretty spot on and conform to what I usually do. However, these methods only solve single instances of a recurring problem. This solution can't change the trend and reinforces dependency on me for providing a narrative that belongs to the user. This is exactly what I want to avoid long term, hence the question.
    – Chris
    Nov 11, 2016 at 15:37
  • @teego1967 Sure, I am not advocating "dismissing users", however I would object to someone approaching me (in person / by email) with a problem they're not able to express. It's a waste of both our time. Similarly I will not approach someone else until I've found the most concise way to express my problem.
    – RJFalconer
    Nov 11, 2016 at 16:14
  • @Chris, if you're overwhelmed, maybe it's time for a help ticket system? There are other alternatives as well, will mod answer.
    – teego1967
    Nov 11, 2016 at 16:20

(for software problems, if you have the posibility)

Dear user, could I come to your desk and could you show me what you're doing and what is going wrong?

This could also be done with some kind of remote-desktop tool like teamviewer or VNC.

That way you can exactly see how your user interacts with the computer and easier identify what goes wrong.

The other way is to make yourself "less available". If you are always only one phone call away and always immediately help people. They never have to think about their problems.

If however there's a "cost" involved for your help then people will think twice. Take "cost" in the broadest sense of the word.

Think about:

  • Limiting your hours "everyday between 1 and 3 I'm available for support".(cost is not being able to immediately get an answer)
  • Having people send an email instead of call. (having to write an email makes people think, that's a cost.)
  • Write your hours on the department you help. (this way managers will urge their people call in less for support and is an actual monetary cost).

Just remember, anything that's free isn't really appreciated.

  • Yes, I often say , "I think I need to see what you are talking about" when answering questions if I get lost in the discussion.
    – HLGEM
    Nov 11, 2016 at 14:40
  • @ Pieter B Your suggestions are how I usually end up solving the problem. What I'm really wanting to know is how to get the user to take a hard look at the problem before they assume that I'm the only one who can solve it. We pay good money to have logmein installed on every machine in the organization and we use it daily. Logmein does make solving problems less costly in terms of time and effort but it doesn't get me closer to helping the user assume responsibility for framing their inquiry.
    – Chris
    Nov 11, 2016 at 15:44
  • 1
    @chris the other way is to make yourself "less available". If you are always only one phone call away and always immediately help people. They never have to think about their problems. If however there's a "cost" involved for your help like writing your hours on the department you provide help for. Then people will think twice. Take "cost" in the broadest sense of the word.
    – Pieter B
    Nov 11, 2016 at 16:01
  • 1
    @PieterB - Please put your comment in your answer. That's the bit that's worth an upvote! Nov 11, 2016 at 17:10
  • @PieterB Becoming less available has worked in the past. Turns out that it's perceived as "ducking the problem". Using economics is a great way to get closer to the answer by associating a cost with what is essentially lazy behavior. I've also tried playing dumb with some degree of success, which feels a bit dishonest.
    – Chris
    Nov 11, 2016 at 22:30

You've answered your own question.

"I apologize. I'm very technically able, but I don't have any intimate domain knowledge with XXYYZZ. To get this going, is it okay if we backtrack a bit so you can explain that to me a little better?"


I can tell you the simplest trick that worked with me (in your exact same situation):

I would love to help you with this. In order to make sure I don't miss anything important, can you please write me an email describing the problem? That way I can be sure I understood it correctly and can give you the best response.

I often preface this with an expression of deep contemplation (to avoid giving the impression of simple dismissal which is really what I am after).

The trick here is getting them to write out their problem. Sometimes, doing this in and of itself leads to rubber ducking and often the person will never respond.

If they do respond, they are forced to articulate their problem correctly.

  • Yes, yes, yes. You saved me the trouble of writing this myself.
    – Wildcard
    Nov 26, 2016 at 8:01

Sounds to me like you want the user to make more effort in figuring out their own solution, or at least coming to you once they have gathered enough info to assist you in triaging or resolving it. You'd like to train the user to go through this process first, to make the situation less frustrating for you, and presumably help them learn at the same time.

The thing is, support does not work that way! If users spent the time gathering enough info to solve their own problems, most of the time, guess what? They would solve their own problems!

Support requirement happens when a user wants to save their own time by asking someone who, in their minds hopefully, already knows the answer and can quickly and easily provide it. The whole value to them in having you as support is that they don't have to spend their own time researching the answer. That's the whole point of them asking you.

The only question you have to answer, therefore, is do you accede to these requests, or not? If you bounce it back to them and give them work to do, it defeats the whole purpose of them asking you, or mitigates the value of it to them. Some further info gathering is reasonable and understandable but if the process becomes cumbersome or excessive, this will have the effect of them (1) seeking help elsewhere instead next time (2) complaining that getting support from you is too much trouble

Providing support is a negotiation. They don't know what you need, so they provide incomplete and unclear information at the outset because it saves them time and gives you an opportunity to tell them what you need. If they go off hunting for information first, they might be wasting their time, from their perspective. People vary widely in the amount of effort they are willing to put into this first stage. You will not easily change people's behavior. It can help to have a simple standard process that gathers common information that is frequently required though, as a prerequisite for providing support, but this should be easy for your users to obtain and provide.


Some good answers here but they all think you need to improve.

In an enterprise everyone is super busy and possibly a little lazy and like to dump issues on someone else.

I had a simple plan, for every request ask them do something first. "Hey, that sounds like a tough issue, can you throw a couple of validated examples in a spreadsheet I can reference?".

Most will either realize they don't actually have a problem, figure it out themselves or decide it's not really that important to them.

  • The end result of this is likely that everyone will consider you to be "super busy and possibly a little lazy".
    – Erik
    Nov 26, 2016 at 9:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .