Choose your language

Choose your login

Support

Blog

The one IT support question you should always, always ask

One of the common frustrations in IT support ā€“ other than customers who donā€™t realise their hardware isnā€™t plugged into the wall ā€“ is spending 45 minutes trying to figure out what the person is actually trying to do. This happens because, often, people will ask for help based on their attempted solution (ā€œIā€™ve tried X, and itā€™s not working.ā€) rather than the underlying problem (ā€œY has gone wrong. Do you know what might be causing it?ā€)

They call this the XY Problem. It was coined by American software developer Eric S Raymond, itā€™s an easy trap to fall into. Both for users and IT professionals.

What is the XY Problem?

The best way to explain the XY problem is to offer an example. Imagine your car wonā€™t start. Instead of calling a mechanic and getting them to diagnose the actual problem, you assume itā€™s a flat battery, so you call your friend and ask for a jump-start. Only it turns out the problem wasnā€™t the battery after all. Youā€™re back at square one, and now your friendā€™s involved too! If anything, youā€™ve just made things worse.

The XY problem is when a user thinks they have a good understanding of their problem (Y), and try to fix it by doing X. When X doesnā€™t work, they ask for help with X, not Y. See the issue?


Eric S Raymond put it this way:

ā€œIf what you want is to do Y, you should ask that question without pre-supposing the use of a method that may not be appropriate. Questions of this form often indicate a person who is not merely ignorant about X, but confused about what problem Y they are solving and too fixated on the details of their particular situation.ā€

How do I get around it?

The first step is not to assume anything. Remember, youā€™re trying to find the underlying problem, then a solution. Never the other way around. If a user comes to you and says ā€œMy Y wonā€™t start, so Iā€™ve tried X, and itā€™s not working. Can you come and help me with X,ā€ thatā€™s a red flag that something else is going on.

Author Laurence Enderson has a good quote thatā€™s relevant here: ā€œWe can be too quick to blurt out what we believe are the correct answers, when more value can be gained by searching for a better question.ā€ What he means is, you must go in with an open mind, and a curious mindset. Donā€™t take anything for granted.

So, whatā€™s the one, important question you need to ask?

The magical IT support question

The magical IT support question isnā€™t ā€œHave you tried turning it off and on again?ā€ (which, weā€™ll admit, solves more tickets than youā€™d expect). The question is: what are you trying to do?

Simple as that. What are you trying to do? Whatā€™s your actual goal? By getting users to explain their fundamental objective, you can quickly trace things back to their roots and start again. Here are some follow-up questions you can add to help the process along:

  • How did the problem first occur?
  • What were you doing?
  • What were the initial symptoms?
  • What happened?
  • What steps have you taken to solve the problem so far?
  • What was the outcome?
  • Can we reproduce the problem now?

These questions are all useful, but without the first one ā€“ ā€œWhat are you trying to do?ā€ ā€“ they can all lead you down the XY path. You need that original objective because thatā€™s the real problem youā€™re trying to solve.

Try and get people to be objective here, too. The only useful information is whatā€™s actually happened, not what a user thinks might have happened. In other words, you need symptoms, not guesses, because symptoms donā€™t lie.

Itā€™s also important to get the user to frame their problem in detail. The more detail the better. Donā€™t just settle for ā€œThe printerā€™s not showing, I canā€™t get it to work.ā€ A better IT call might go something like, ā€œIā€™m trying to connect this printer to the network, but itā€™s not showing up on the list of suggested devices. Iā€™ve refreshed the list and re-started the WIFI, but nothingā€™s changed.ā€

See the difference? The first call lays out a problem, but the second call gives the support worker context, detail, an actual objective, and a couple of solutions that have already been tried. By getting the user to frame the question correctly, youā€™ve already saved yourself time ā€“ and future headaches.

Newsletter

Subscribe for the latest in print management and product updates!

By filling out and submitting this form, you agree that you have read our Privacy Policy, and agree to PaperCut handling your data in accordance with its terms.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.