IT Troubleshooting Fundamentals: Think Like an IT Pro

Learn a structured approach to diagnosing problems, testing solutions, documenting results and escalating effectively.

Created byIntelligence Gain

Last updated 11/2026

English

What you'll learn

Use a six-step workflow (define, scope, hypothesize, test, verify, document) to solve IT problems instead of guessing
Turn a vague complaint like "the internet is broken" into a clear, scoped problem statement
Ask better questions and find out what changed to narrow down the possible causes of a problem
Isolate where a fault lives: the user's account, the device, the application, the network or a shared service
Choose safe, reversible tests, change one thing at a time and avoid common traps like confirmation bias
Verify a fix with the user, write a clear ticket note and escalate with the evidence a senior colleague needs

Course content

4 sections • 12 lectures • 1h 9m total length

The Troubleshooting Mindset6:07
Stop guessing and start investigating. Learn the difference between a symptom, a possible cause and a verified cause, and meet the six-step workflow used throughout the course: define, scope, hypothesize, test, verify and document. An offline label printer at Larkfield Supply, the fictional company in every lesson, shows why random fixes waste time and how evidence finds the real cause.
Define the Problem and Ask Better Questions5:54
Turn a vague complaint into a problem statement you can act on. Ask what should happen, what actually happens, when it started and whether it can be reproduced, then capture exact error messages and recent changes without leading the user. Practice on a classic ticket: "The internet is broken."
Scope the Issue and Judge the Impact6:09
Find out who and what is affected before you choose an action. Compare one user with many, one device with many and one application with several, weigh impact against urgency, and learn the signs of a wider outage and when to escalate. The case: one person can't open email while their colleagues can.

Find Useful Clues: What Changed?5:32
Use timing and comparisons to narrow the possible causes. Build a short timeline of changes to accounts, devices, applications and networks, compare working and failing conditions, and remember that correlation is a clue, not proof. The case: printing stopped after an update, but only on one floor.
Isolate the Problem Logically5:34
Choose comparisons that point to the failing layer: the user and account, the device, the application, the network or the service. Use known-good comparisons where you're allowed to, and narrow the fault without changing several things at once. The case: an application works for the same user on another device.
Build a Hypothesis and Choose a Safe Test5:55
Pick the test that teaches you the most with the least disruption. Write a testable hypothesis and its expected result, weigh tests by information value, risk, effort and permission, and change one thing at a time with a way back and a point to stop. The case: a restart might interrupt an active business process.
Interpret Results and Avoid Common Traps5:29
Learn to change your explanation when the evidence doesn't support it. Tell an unsuccessful test from an unhelpful one, spot confirmation bias, repeated fixes and early conclusions, and keep a workaround separate from a real resolution. The case: a workaround restores access, but the fault is still there.

Case: A User Can't Sign In5:37
Work an account-access ticket from start to finish. Pin down the application, the exact message, the scope and the last successful sign-in, compare account, device, authentication and service explanations, and respect identity verification and escalation boundaries. The user can sign in to email but not the expenses application.
Case: An Application Is Suddenly Slow5:19
Investigate a performance complaint without jumping to a hardware diagnosis. Find out what "slow" means, which operations and times are affected, compare user, device, network and service patterns, and document the limits of what you found. The order-entry screen slows down for a group of users after lunch.
Case: Several Users Lose a Service5:52
Recognize a shared incident and respond the right way. Look for common dependencies and who's affected, check for known incidents, avoid duplicate disruptive fixes, escalate early with evidence and share only confirmed facts. Several departments can't reach a shared business application.

Verify Recovery and Write a Useful Ticket5:11
Confirm the original problem is really resolved and leave a record the next person can use. Retest the task with the user, check for side effects, and record symptoms, scope, evidence, actions, results and current state, plus open questions for a clean handoff. Compare a weak ticket with a clear, evidence-based resolution note.
Final Challenge: Explain Your Next Step6:21
Put the whole method to work on a new scenario with several plausible causes: a remote employee reports that one internal application fails now and then. Choose and explain the next safe, useful test, review the six-step workflow, and build your own personal action checklist.

Requirements

Basic computer skills: you can use a computer, a web browser and email
No IT job, technical background, software or special equipment needed. Every lesson explains its terms in plain English

Description

This course contains the use of artificial intelligence.

Something stops working. The ticket says "The internet is broken." Where do you start?

This course teaches the method experienced support professionals use to find out what's really wrong before they fix it. Instead of trying random fixes and hoping one works, you'll learn to define the problem, narrow the possibilities, choose a safe test and explain what the evidence supports.

You'll follow one fictional company, Larkfield Supply, through realistic support situations: an offline label printer, a user who can sign in to email but not the expenses app, an order-entry screen that slows down after lunch, and several departments losing a shared application at once. Each scenario pauses at a decision point so you can choose your next step before the reasoning is explained.

What you'll practice

A six-step workflow: define, scope, hypothesize, test, verify and document
Asking better questions without leading the user
Judging scope, impact and urgency, and knowing when to escalate
Finding what changed and comparing working and failing conditions
Isolating the problem by layer: account, device, application, network or service
Choosing low-risk tests and changing one thing at a time
Avoiding traps like confirmation bias and workarounds that become permanent
Verifying the fix with the user and writing a ticket the next person can use

About this course

This is a short, narrated presentation course: 12 lectures in about 70 minutes. There are no labs or software demonstrations, and it's vendor-neutral, so the method works whatever tools your team uses. It focuses on diagnostic thinking, not hardware or operating-system repair, and it isn't tied to any certification exam.

Every IT term is explained in plain English the first time it's used, so you don't need an IT job or a technical background to start. If you're the person people come to when technology stops working, this course gives you a method to rely on.

Who this course is for:

Aspiring help desk and IT support technicians getting ready for their first role
Junior IT support staff who want a structured, repeatable way to diagnose problems instead of trial and error
Career changers moving into IT who want to think like an experienced support professional
The person in a small office everyone asks for help when technology stops working

IT Troubleshooting Fundamentals: Think Like an IT Pro

What you'll learn

Explore related topics

Course content

Foundations3 lectures • 18min

Investigate and Test4 lectures • 23min

Guided Cases3 lectures • 17min

Close and Communicate2 lectures • 12min

Requirements

Description

Who this course is for: