Troubleshooting Questions to Ask
For help desk technicians, IT support agents and customer support reps with a user on the line and a one-line report in the ticket. The list opens with the basic troubleshooting questions to ask on every call, then follows the order a diagnosis takes: the symptom in detail, when it began and what changed, how far it reaches, error messages and earlier fixes, and finally how urgent it is and how to close. Stop as soon as the answers point to a cause, since no caller should have to sit through all of them.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
The basics
What exactly happens when you try to do it?
Why ask it
Reports arrive as conclusions, such as 'email is broken', and this asks for the observation underneath. Listen for a verb you can test: it freezes, it closes, it says something, nothing happens at all. If the answer is still a summary, ask what they see on the screen at the moment it goes wrong.
What did you expect to happen instead?
Why ask it
Sometimes the system is doing what it was built to do and the gap is in the expectation, which makes this a how-to request and not a fault. When the expectation is reasonable, it also gives you the test for done: the ticket is finished when that happens.
When did it start?
Why ask it
A time lets you line the fault up against whatever else happened then: an update, an outage, a password expiry, a change someone on your own team made. 'This morning' is enough to start with. If they say 'a while', ask why they are reporting it today, because something usually got worse.
Has anything changed since it last worked?
Why ask it
A fault that appears overnight usually follows a change, and the user is often the only one who knows about the new monitor, the moved desk or the app they installed. Expect 'nothing' as the first answer and do not take it as final. Ask again with examples, such as an update, something newly plugged in or a different desk, and the answer often changes.
Is there an error message, and what does it say word for word?
Why ask it
The exact text is what you can search in the knowledge base or the vendor's support pages, and a paraphrase such as 'it said something about a server' is not. Ask them to read it aloud slowly or send a screenshot. If the message has already been dismissed, ask them to repeat the step so it comes back.
Does it happen every time, or only now and then?
Why ask it
Every time means you can test a fix on the spot and know whether it worked. Now and then means you need a record, so ask the user to note the time and what they were doing at the next few occurrences, and tell them the ticket will stay open while they do.
Is it only you, or are other people having the same problem?
Why ask it
One person is a device, an account or a habit. Several people at once is something shared: a service, a network segment, a license, a recent rollout. If others have it too, check for an open incident before going further, and link this ticket to it so nobody diagnoses the same outage five times.
What have you already tried?
Why ask it
It saves you from walking someone through the restart they did twice before calling, which is the quickest way to lose their patience. It also tells you the machine is no longer in the state it failed in, so note each attempt in the ticket. Take the list as a lead, though, and recheck anything the diagnosis depends on.
What is this stopping you from doing right now?
Why ask it
Priority comes from the effect on the work, and two identical faults can deserve very different speeds. A printer that will not print matters more on payroll day. Set the ticket's priority by your own desk's rules, using what they tell you here.
The symptom
Can you walk me through it step by step, starting from before the problem appears?
Why ask it
The cause is often in a step the user thinks is too ordinary to mention: which icon they open, which saved link, which account they pick. Have them do it while they talk if they can, and stop them at anything you would not have done the same way.
What is the end goal here, in case there is another way to get you there?
Why ask it
The goal matters more than the broken step. Someone who cannot attach a file may only need to get a document to a client, and there may be a route you can give them in a minute while the real fault waits. It also catches the case where they are using the wrong tool for the job.
Which device, app or account is this on?
Why ask it
People with a laptop, a phone and two accounts tend to report 'my email' without saying which. Get the device name or asset tag, the app, and the sign-in they use, because the same symptom on a personal phone and a managed laptop goes to different places. Check your desk's rule on personal devices before promising anything on one.
Has it stopped working completely, or is it working but slow or behaving oddly?
Why ask it
'Not working' covers dead, slow, wrong and intermittent, and each sends you somewhere else. Dead usually sends you to power, sign-in or the connection first. Slow or odd sends you to load, storage or a setting, so ask what normal looked like and how far off this is.
Can you show me, with a shared screen, a screenshot or a photo?
Why ask it
Seeing it once can replace five minutes of description, and you will notice things the user would never think to report, such as a second monitor, an old version number or a full disk warning in the corner. A phone photo of the screen is fine when the machine will not start or will not get online.
Is it all right if I connect to your screen, and is anything open that I should not see?
Why ask it
Consent for remote control is good manners everywhere and a written requirement in many workplaces, so follow your own desk's rule on how it is asked and recorded. Giving people a moment to close a payslip, a medical form or a private chat is what makes them say yes next time. Tell them when you have disconnected.
Can you make it happen again now, while I am watching?
Why ask it
Watching it fail yourself gives you the order of events and the timing, which a description flattens. If it will not misbehave with you watching, do not treat that as the user being wrong. Note exactly what they did this time, since the difference from their usual routine may be the clue.
What is the last step that still works before it goes wrong?
Why ask it
This draws the line between the part of the chain you can stop thinking about and the part you cannot. If they can sign in and open the app but the report will not load, the laptop, the network and the password are probably fine, and you can start at the report.
Which version of the app or operating system are you on?
Why ask it
Few users know offhand, so be ready to tell them where to look, usually an About entry in the menu or the settings. A version behind everyone else's can explain a fault only they have, and one ahead of everyone else's can mean they got an update early. Compare it with what your team currently supports.
Timing
When was the last time you know for certain it worked?
Why ask it
Together with the start time this gives you a window, and the cause sits inside it. A window of one night is easy to search. If it runs from Friday afternoon to Monday morning, ask whether the device was off, asleep or traveling in between.
Has it ever worked for you on this device?
Why ask it
A no changes the whole call: you are finishing a setup or granting access, and nothing has broken. Expect it from new starters, people with replacement laptops and anyone who has just changed teams. If it works on their old device, compare the two before looking anywhere else.
Was anything installed, updated or plugged in around then, even something that seems unrelated?
Why ask it
Naming the kinds of change jogs memories that the general question does not. Listen for a browser extension, a new docking station, a phone update or an app that 'just asked to restart'. Whatever they mention is the first thing to undo as a test, if it can be undone safely.
Has your password, your role or your access changed lately?
Why ask it
A changed password leaves old copies saved on phones, in mail apps and on mapped drives, and those can keep trying until the account locks. A new role or a move between teams can drop a permission. Check the account's status on your side while they answer; it is often faster than the conversation.
Just before this started, did you click a link, open an attachment or approve a sign-in request you were not expecting?
Why ask it
A sudden lockout, a slow machine or odd pop-ups are occasionally the visible end of a security problem, and most users mention the email only when asked. Ask it flatly, as one more routine question, so nobody feels caught out. If the answer is yes, stop fixing and report it the way your organization handles a possible security incident, before anything is cleaned up.
Is there a pattern to when it happens, such as a time of day or just after the laptop wakes up?
Why ask it
Offer examples, because users rarely volunteer a pattern unprompted: mornings only, in one meeting room, on battery, with a certain file open. A pattern tied to a place points you at the network there. One tied to a time is worth checking against scheduled jobs such as backups and scans.
Has this happened before, and what fixed it then?
Why ask it
A repeat fault with a known fix gets the user working quickly, and then deserves a second look, because a fix that has to be reapplied is treating the symptom. Search the ticket history for the earlier case; do not rely on their memory of what the last technician did. If it keeps returning, raise it as a recurring problem the way your desk handles those.
Scope
Does it happen on another device, or in a different browser?
Why ask it
If the problem follows the person to a second device, look at the account or the service. If it stays behind, look at the first device. A different browser is the quickest version of this test for anything web-based, and it doubles as a way to keep them working.
Are your other apps and websites working normally at the moment?
Why ask it
'The internet is down' from someone who is talking to you over an internet call is really one site or one app. This sorts a general connection problem from a single service in ten seconds. Ask them to open one internal page and one public one, which gives a first idea of whether the trouble is inside your network or outside it.
Does it happen with every file, page or record, or only one?
Why ask it
A single spreadsheet that will not open is a different job from a spreadsheet program that will not open anything. When it is only one item, ask where it came from, how big it is and whether someone else can open the same one. That usually separates a damaged file from a permissions gap.
Where are you working from, and how are you connected?
Why ask it
Office cable, office Wi-Fi, home broadband, a hotel network and a VPN each put different equipment between the user and the thing that is failing. If they are at home, ask whether the VPN is on, since a shared drive that has 'disappeared' is often just a VPN that is off.
Does it still happen on a different network, such as a phone hotspot?
Why ask it
This one earns its place with remote workers, where you cannot see the router or the provider. If everything works on the hotspot, the home or hotel network is the suspect and the laptop is mostly cleared. Keep the test to a minute where the user pays for mobile data, and check whether your organization allows work devices on personal hotspots at all.
If a colleague signs in on your computer, do they get the same thing?
Why ask it
Trying a second device changes the machine and keeps the account. This does the reverse, so a colleague who gets the same fault clears the user's profile and permissions. Only suggest it where shared sign-ins on one machine are allowed, and never by having anyone hand over a password.
Does it behave the same in a private or incognito window?
Why ask it
A private window starts without the saved cookies and cached pages, and usually without extensions, so a site that works there has a problem stored in the normal profile. The next step is clearing that site's data or switching extensions off one by one. Warn them before clearing everything, because it will sign them out of other sites.
Errors and fixes
Is there a code or a number anywhere in that message?
Why ask it
Wording changes between versions and languages, while the code tends to stay the same, which makes it the better search term. Have them read it character by character and say whether an O is a letter or a zero. Paste it into the ticket exactly so the next person can search on it too.
What did you click or press just before the message appeared?
Why ask it
An error with no trigger is hard to reproduce. Pin it to a click and you can test it yourself on another account. Watch for messages that appear at startup or on a timer with no action at all, since those tend to come from something running in the background, not from what the user was doing.
Are there any lights, beeps or warnings on the device itself?
Why ask it
For hardware that will not start or connect, the lights are the only error message there is. Ask for the color, whether it is steady or blinking, and which label it sits beside, then look the pattern up in the maker's guide for that model. Do not go from memory, because the patterns differ between models.
Have you restarted it since the problem began, using Restart and not just closing the lid?
Why ask it
Closing a laptop lid, locking the screen or tapping the power button all feel like a restart to many people, and none of them is one. Name the menu option you mean. If your tools show uptime, look there instead of pressing the point, and when a restart does clear the fault, note it in case the same thing comes back after a few days of uptime.
Could you check for me that every cable is pushed in at both ends?
Why ask it
Phrased as a favor to you, it gets checked. Phrased as 'is it plugged in?', it gets an offended yes without anyone looking. Ask them to pull each lead out and push it back, which reseats a loose one and gives them a reason to look at the far end.
Did anything you tried make a difference, even for a minute?
Why ask it
A fix that worked for ten minutes is a strong clue, and users leave it out because it did not last. Also listen for anything that got worse after an attempt. A cleared cache or a reinstalled app may have added a second problem on top of the first, such as lost saved sign-ins.
Has anyone else already looked at this, and is there an earlier ticket?
Why ask it
Users who have been passed between people tell the story shorter each time, and details drop out. Find the earlier ticket and read it before asking them to start over. If a colleague or a relative has been fixing it informally, ask what they changed, without judgment, because the settings may no longer be standard.
Have you found any way around it for now?
Why ask it
The workaround a user invents is diagnostic information. 'It works if I use the website instead of the app' clears the account and the service at a stroke. Record it in the ticket as well, so the next caller with the same fault can be given it while the cause is still being found.
Urgency and close
Is there a deadline this is putting at risk?
Why ask it
A hard time, such as a client presentation at two or a filing due today, changes what you do first: get them working by any safe route, and find the cause afterwards. Write the deadline at the top of the ticket. If you cannot meet it, say so now so they can make other plans.
How many people are held up by this?
Why ask it
One person's inconvenience and a whole team's stoppage are different priorities on any desk, and the user may be reporting on behalf of twenty others without saying so. If the number is more than a handful, tell whoever handles incidents on your team straight away. Do not keep working it as a single ticket.
If this is not fixed until tomorrow, what happens?
Why ask it
It gets a more honest answer than asking whether something is urgent, to which nearly everyone says yes. Sometimes the answer is 'nothing, I can use the other printer', and you have just learned where this sits in the queue. Sometimes it brings out a consequence the user had not thought to mention.
Was anything open or unsaved when it happened?
Why ask it
Ask before you restart, reinstall or close anything, because the first fix you try can turn a nuisance into lost work. If there is unsaved work on screen, deal with that first: a photo of the screen, a copy and paste into another app, whatever keeps it. Do not promise that a file can be recovered until you have seen how that app keeps its autosaves.
What is the best way to reach you, and when will you be at the device?
Why ask it
If the fault is email or the phone, the contact details on the ticket may be the very things that are down. Get a second route. For anything that needs hands on the machine, agree a time window now, so the ticket does not sit through three days of missed calls.
Can I read back what I have, so you can tell me what I got wrong or left out?
Why ask it
A summary in two sentences catches the misheard detail before you spend an hour on the wrong problem. It also shows the user they were listened to, which buys patience if the fix takes a while. Whatever they correct goes into the ticket in their words.
Is it working the way you expect now?
Why ask it
Have them do the original task themselves, start to finish, before you close anything. Your test shows the fault you found is gone, and theirs shows the fault they called about is gone, which is not always the same one.
How to run a troubleshooting conversation
Practical guidance for the conversation itself
Before you ask anything
Read the ticket and its history first
Whatever the user typed into the form, and whatever earlier tickets say about the same device or account, is information you should not make them repeat. Open with what you already have: 'I can see the shared drive stopped opening this morning. Can I ask a few things to narrow it down?' Then skip any question on this page the ticket has answered.
Let them tell it once, uninterrupted
Give the user a minute to describe the problem their own way before you start steering. The order they tell it in shows what matters to them, and the detail you need is often in a throwaway remark near the end. Take notes and hold your questions until they stop.
Say why you are asking
A run of questions can feel like being quizzed about a mistake. One sentence at the start fixes that: 'I am going to ask some quick questions so I do not waste your time on the wrong fix.' People answer more fully when they know the questions are about the fault and not about them.
Confirm who is calling, by your desk's rule
Anything that touches an account, such as a reset, an unlock or a change of access, needs the caller's identity confirmed first. How that is done differs from one organization to the next, so learn your own procedure and follow it even when the caller is senior or in a hurry.
Narrowing it down
Aim each question at halving the possibilities
A fault lives somewhere along a chain: the person's account, the device, the network, the service at the far end. The questions under Scope are built to rule out a whole link at a time. Before asking the next one, know which link a yes would clear and which a no would clear. If both answers leave you in the same place, pick a different question.
Separate what they saw from what they concluded
'The server is down' is a conclusion. 'I click Save and the wheel spins until I give up' is an observation. Users report conclusions because that is how people talk, so thank them and ask what they saw that led them there. Put the observation in the ticket, not the conclusion.
Change one thing at a time
When you start testing, alter a single thing, check the result, and put it back if nothing changed. Three changes at once may fix the fault, but you will not know which one did it, and you will have nothing to tell the next caller with the same symptom.
Start with the quick and likely, not the interesting
Check things in an order that weighs how likely each cause is against how long it takes to rule out. A loose cable, a VPN that is off, an expired password and a full disk each take about a minute. Rare and fascinating causes can wait until the ordinary ones are cleared.
See it for yourself when the diagnosis hangs on it
Take the user's account in good faith, and still look at the one or two facts everything depends on. 'Yes, it is plugged in' and 'yes, I restarted' are sincere and sometimes mistaken. A screenshot, a remote session or a glance at your management tools settles it without anyone being doubted aloud.
Wording that keeps the user with you
Ask about the machine, not the person
'What did you do?' puts the user on trial. 'What was on the screen just before?' asks the same thing and blames nobody. People who feel accused leave out the embarrassing detail, and the embarrassing detail is frequently the cause.
Use their words for things
If they call the dock 'the box under the monitor', call it that for the rest of the call, and keep the proper term for the ticket. Asking someone whether their DHCP lease renewed ends with a guess. Asking whether the Wi-Fi symbol has a line through it gets an answer.
Ask them to read, not to interpret
'What does it say at the top of the window?' gets you data. 'Are you signed in?' gets you what they believe. Whenever a question can be turned into reading something off the screen, turn it.
With an upset caller, start at the end of the list
Someone who is locked out ten minutes before a meeting does not want to be asked which browser they use. Open with the questions under Urgency and close, say what you will do about the deadline, and come back to the diagnostic ones once they know you have understood the stakes.
Writing it up and handing it on
Put the answers in the ticket as you go
Notes written during the call hold the exact error text, the times and the user's own description. Notes written an hour later hold your summary of them. A fair test is whether a colleague could pick up the ticket without phoning the user to ask anything on this page again.
Know when to stop asking
Once the questions under The basics and Scope are answered and you have tried what your level is allowed to try, a longer interview seldom finds the cause. Escalate by your desk's process, and tell the user that is what is happening and what they should expect next.
What an escalation should carry
The next person needs the symptom in one line, when it started, what changed, who else is affected, the exact error, every step already tried with its result, and how urgent it is. Add how to reach the user. That is the first group of questions on this page, answered, plus your own test results.
Close the loop with the person who called
Before closing, have the user confirm the fix on their own task, tell them in a sentence what the cause was, and say what to do if it returns. If the fix was a workaround, say that too, and leave the ticket in whatever state your desk uses for a problem that is contained but not solved.