How to troubleshoot an IT issue without guessing
A ticket is a report of a problem. It is not proof of the cause. The first useful move is to turn the report into a question that evidence can answer.
Useful default: What do we know, how do we know it, and what is the smallest safe test that could prove us wrong?
When a user says “the VPN is down”, “payroll is broken”, or “my computer does not work”, the explanation may be right. It may also be a story that happens to fit the symptom. Treating it as confirmed too early produces the usual bad outcomes: broad resets, unnecessary changes, lost transient evidence and a recurrence that nobody can explain.
The method below is not an excuse to delay urgent recovery. When a critical task is blocked or an unsafe condition is possible, notify the right people, use an approved workaround and preserve what evidence you can. It is a way to make the next technical action deliberate rather than merely busy.
The Seven Decision Points
- Triage the impact and safety first. What work is blocked? How urgent is it? Could continued testing affect information, access, production service or safety? A one-user issue may still stop payroll approval, medication dispensing or a time-critical statutory task.
- Describe the symptom, not the conclusion. Record the task, exact message, time, last known working state and known scope. “Sam sees access denied after signing in to payroll at 09:12” is useful. “Payroll is broken” is not yet a diagnosable problem.
- Find the edge of the problem. Compare a working and failing case: another user, device, account, location, network or service path. A comparison does not prove every other difference is irrelevant. It narrows the next useful boundary.
- Label facts, reports, hypotheses and unknowns. A user saying an update caused the issue is a report. A successful sign-in on another managed device is an observation if you saw or reproduced it. Keep those categories distinct so a plausible story cannot silently become root cause.
- Choose the smallest safe discriminating test. Ask what result would strengthen one explanation and weaken another. A fresh browser profile can distinguish likely session state from a wider device or access-policy path without deleting the original profile.
- Recover proportionately. Make one approved change that matches the evidence. Record the before state where practical and say what result you expect. Recovery may be urgent; it is still not automatically proof of cause.
- Verify the original task and record the limit. Do not stop at a green dashboard or “it seems okay.” Confirm the user can perform the original task. Record what recovered, what the evidence supports and what remains unproven if the issue returns.
A Short Example
A user cannot approve timesheets in payroll on their work laptop. A colleague can sign in from the same office. The affected user can sign in from an approved shared device. Those comparisons make a total payroll outage and a simple account lockout less likely, but they do not prove the laptop is faulty. Browser state, device posture and policy differences remain possible.
A safe next test is to use a fresh browser profile on the original laptop without removing the existing one. If the fresh profile works, the original profile becomes a stronger candidate; it does not prove a particular cache item caused the issue. That result justifies a bounded recovery under the approved support procedure, followed by user verification and an honest record.
What This Method Prevents
- Resetting an account because the ticket says “access denied”.
- Restarting a service before collecting the exact error and timeline.
- Calling a company-wide incident “one user’s browser issue”.
- Declaring root cause because a recovery action happened to work.
- Escalating a pile of screenshots instead of a clear decision record.
Read the complete worked scenario: the free HTML scenario applies this method to a company-wide DNS degradation and shows when a ticket becomes an incident. A PDF version remains available for offline reading.