We're an ISO27001:2013 Certified Supplier


It should be easy, but sometimes reporting IT problems – and getting the results you want  from your IT support department – doesn’t seem to be as straightforward as it should be.

You’ve explained the problem to them, but somehow they don’t seem to get it. As the journalist William Whyte observed, “The great enemy of communication is the illusion of it”, and sometimes (attempted) communication with IT folk just seems to underline that.

Quick Guide

Here’s a really simple guide to reporting IT problems that will help both you and them get those problems resolved as soon as possible. It comprises five pieces of information:

  1. What you were trying to achieve
  2. How you were trying to achieve it
  3. What happened
  4. How what happened differed from what you expected
  5. Any other information

What You Were Trying to Achieve

Define the end result you are trying to achieve. Take care to define the problem, not your chosen solution or one of the steps along the way. A good test is to take your definition and ask, “Why?”. The answer to that will usually tell you whether or not you’ve defined what you are trying to do rather than how you are trying to do it. If the problem is intermittent, also give as accurately as possible the date and time your problem occurred.

  • Good example: “I want to print a letter I’ve typed in Word”
  • Bad example: “Can you reboot the file server, please?”

How You Were Trying to Achieve It

This is where you state what you did. Don’t embellish it or add detail: this should be a factual account of actions taken.

  • Good example: “I clicked on the “print” icon in the toolbar”.
  • Bad example: “Marie said that we have to…”

What Happened

Another factual description. Avoid adding your interpretation of what is going on: just report what actually happened.

  • Good example: “The print dialog appeared, and I clicked on OK. Nothing seemed to happen after that”.
  • Bad example: “I got an error, and it looks like there’s a problem with DNS”

How What Happened Differed From What You Expected

Yet another factual statement. The reason this is important is that sometimes what happened was exactly what should have happened given what you did, but it may not be what you want. In other words, it did what you said rather than what you meant.

  • Good example: “I expected the letter to print on the printer next to Marie’s desk”
  • Bad example: “It should have just worked”.

Any Other Information

This is your opportunity to fill in any gaps and yes, if you want, hypothesise about the problem. There are no “bad” examples: you can say what want here.


  • “My PC was rebuilt last Tuesday by Adam, and this problem has only happened since then”
  • “The same problem seems to be affecting everyone in Accounts”
  • “I think this is a DNS problem because …”

They Are Only Trying To Help

Most IT people cite solving (IT) problems as one of the things they enjoy most about the job so, despite the impression you may get from time to time, they do want to help. Sometimes there’s a communication breakdown between users and support staff that leads to frustration on both sides. The guidelines above will help avoid that frustration.

If you’re not sure, ask your IT people if reporting problems in this way would be helpful.

How Could This Article Be Improved?

Let us know in the comments below.