A structured troubleshooting method

Troubleshooting is the heart of IT support. Users rarely arrive with a clear fault; they arrive with a symptom, often described in a hurry: the computer is broken, the printer is acting up, nothing works. Inexperienced technicians react by trying things at random, rebooting, reinstalling and swapping parts until something changes. Sometimes that works. More often it wastes time, creates new problems and leaves nobody knowing what was actually wrong. Experienced technicians follow a method. This lesson teaches the standard six-step troubleshooting method used across the industry and examined in CompTIA A+, along with the habits that make it work: good questions, careful theories, one change at a time and thorough notes.

The six steps

The method looks simple written down, which is part of its strength. It works on a frozen tablet, a failed drive, a slow network or a misbehaving printer, and it works whether you are an apprentice like Jordan or a senior engineer.

Two features of the method matter more than any others. First, it separates finding the cause from fixing it. Steps 1 to 3 are about understanding; nothing permanent should change until step 4. Second, it loops. When testing shows that a theory is wrong, you go back, form a new theory and test that. When you run out of theories, or the problem is beyond your access or skill, you escalate to someone who can help, passing on everything you have learned so they do not start from scratch.

Step 1: identifying the problem

Most troubleshooting time is saved or wasted in the first step. The goal is to replace a vague complaint with a precise description: what the user was trying to do, what they expected, what actually happened, any error messages word for word, when it started and whether anything changed around that time. A few well-chosen questions usually get there. Open questions, such as what were you doing when it happened, get the user describing; closed questions, such as does it happen on the other tablet too, pin down details.

The question what changed recently is the most powerful in IT support. Problems rarely appear out of nowhere: a Windows update installed overnight, a new app was added, a cable was moved during cleaning, a password expired, the internet provider worked on the line. Users often forget changes or do not think them relevant, so ask directly and check the evidence yourself: update history, recently installed programs, event logs and the ticket history for that device.

Whenever possible, reproduce the problem: watch it happen, or make it happen yourself. A problem you can reproduce can be tested; one you cannot is much harder. Find out the scope as well. One user or many? One device or several? One application or everything? A problem affecting every device at Ridgeline points at something shared, such as the internet connection or a cloud service, while one affecting a single device points at that device. Finally, before changing anything that could lose data, make sure the user's important files are backed up.

Steps 2 and 3: theories and tests

With a clear description, list the possible causes and rank them by likelihood and by how easy they are to check. Technicians are taught to question the obvious: is the device plugged in and switched on, is the cable connected at both ends, is the monitor on the right input, is the user signed in to the right account. These checks feel almost insulting, but they resolve a surprising number of tickets and take seconds. Ask about them tactfully: could you check that the cable is firmly in at the back of the printer is better than is it plugged in.

A useful way to organize theories is to work through the layers from lesson 1, either from the bottom up, starting with power and cables and working up to the application, or from the top down, starting with the application. Another approach is divide and conquer: split the system in half and test which half the fault is in. If a computer cannot reach a website, pinging the router tests the first half of the path; if the router answers, the fault lies beyond it.

Testing a theory means gathering evidence for or against it without changing things permanently. If you suspect a faulty cable, try a known-good one. If you suspect a failing power supply, test it with a power supply tester or swap in a known-good unit. If you suspect a recent update, check whether the problem started at the same time. Change one thing at a time and observe the result. Changing three things at once may fix the problem, but you will not know which change did it, and you may have introduced a new problem with the other two.

Steps 4 to 6: fixing, verifying and documenting

Once the cause is confirmed, plan the fix. Consider who will be affected and when: replacing the receipt printer at noon on a Saturday stops the cafe taking card payments with receipts, so it waits for a quiet moment unless the printer is completely dead. Larger changes, especially on shared systems, go through the organization's change management process, which records what will change, when, who approved it and how it will be undone if it goes wrong. ITSM-201 and the IT service management courses cover change management in detail.

After the fix, verify that the whole system works, not just the original symptom. If you replaced a network cable, check that the computer reaches the internet, the printer and the NAS. Ask the user to confirm, because they know what working normally looks like for their job. Then think about prevention: if a cable failed because a chair kept rolling over it, route it differently; if a disk filled up, set an alert before it happens again.

Finally, document. The ticket should record what the user reported, what you found, what you did, the cause and the result, written clearly enough that a colleague could understand it months later. Good documentation turns individual fixes into team knowledge: the second time a problem appears, the fix takes minutes. Jordan keeps Ridgeline's notes in a small knowledge base, with an article for each recurring issue.

Tickets, impact and priority

Ridgeline's support requests are tracked as tickets, each with a number such as HD-2041, the user, the device, a category, a short summary, a priority and a log of every action. A ticket system ensures nothing is forgotten, shows what is waiting, and builds a history of each device. ITSM-201 covers ticketing systems properly; here, the important idea is priority.

Priority decides which ticket gets worked on first, and it is usually calculated from two separate judgments. Impact is how much of the business is affected: one person, a team or the whole business. Urgency is how quickly the effect becomes serious: whether work can continue with a workaround or has stopped. A problem with high impact and high urgency, such as the point-of-sale system failing on a Saturday morning, is priority 1 and is worked on immediately. A cosmetic issue for one person with a workaround is priority 4 and can wait for Sam's weekly visit.

MATRIX = {
    ("high", "high"): 1, ("high", "medium"): 2, ("high", "low"): 3,
    ("medium", "high"): 2, ("medium", "medium"): 3, ("medium", "low"): 4,
    ("low", "high"): 3, ("low", "medium"): 4, ("low", "low"): 4,
}
tickets = [
    ("HD-2041", "Card readers not connecting at the counter", "high", "high"),
    ("HD-2042", "Anita's second monitor flickers", "low", "low"),
    ("HD-2043", "Label printer printing across label gaps", "medium", "high"),
]
for number, summary, impact, urgency in tickets:
    print(f"{number}  P{MATRIX[(impact, urgency)]}  {summary}")

HD-2041  P1  Card readers not connecting at the counter
HD-2042  P4  Anita's second monitor flickers
HD-2043  P2  Label printer printing across label gaps

def priority(impact, urgency):
    return 4

def sort_queue(tickets):
    return tickets

queue = [("HD-2050", "high", "medium"), ("HD-2051", "low", "high"),
         ("HD-2052", "medium", "high"), ("HD-2053", "low", "low")]
print([t[0] for t in sort_queue(queue)])

Communicating while you troubleshoot

Technical skill is only half of troubleshooting; the other half is people. Users who report a problem are often stressed, because the problem is stopping their work. Listen without interrupting, let them finish describing the problem, repeat it back to confirm you understood, and avoid jargon. Tell them what you are going to do and roughly how long it will take, and keep them updated if it takes longer. Never blame the user, even when the cause was something they did; explain what happened and how to avoid it next time. Respect their privacy and their workspace: do not read their email or files, and ask before moving things on their desk. Lesson 11 returns to professional conduct.