01
Turn the complaint into a testable symptom
Replace “email is broken” with a specific failure such as “Outlook desktop cannot send, but Outlook on the web can.”
Everyday IT · Troubleshooting Worksheet
The first 10 minutes should reduce uncertainty, not create more variables.
Good troubleshooting does not begin with a fix. It begins by making the problem smaller, clearer, and safer to test.Define the symptom. Prove the scope. Compare known-good. Identify the likely layer. Preserve evidence. Choose one safe next test.
What the first ten minutes are for
The goal is not to solve every incident in ten minutes. The goal is to stop guessing, avoid making the problem harder to diagnose, and leave yourself with a defensible next step.
02
Measure how wide the failure is
One user, one device, one office, one resource, or everyone? Scope often tells you which layer deserves attention first.
03
Find a known-good comparison
Change one dimension at a time: user, device, network, browser, resource, path, or workflow.
04
Choose the smallest safe next test
Do not make a broad change when a narrow observation or comparison can answer the next question.
First 10 Minutes
Use this worksheet in order
Write down the answers. A short record is more reliable than memory once several people, devices, systems, and tests become involved.
1 · Symptom
What exactly is failing?
Record the user-visible action, the expected result, and the actual result. Capture the exact error text or code when available.
Write: What were they trying to do? What happened instead?
2 · Time
When did it last work?
Record first-known failure, last-known good, whether the issue is constant or intermittent, and whether a change occurred near that boundary.
Write: Last known good, first known bad, recent change if known.
3 · Scope
Who and what are affected?
Test whether the issue follows the user, device, location, application, resource, or shared service.
Write: One user or many? One device or many? One resource or many?
4 · Known-good
What still works?
Find a comparison that changes only one useful dimension. A successful path is evidence, not just good news.
Write: Same user elsewhere? Another user here? Browser vs desktop? Another network?
5 · Layer
Which layer best fits the evidence?
Choose the most likely current layer: identity, client/device, network, service, policy, permissions, data, or hardware. Treat this as a working hypothesis, not a verdict.
Write: Most likely layer and why.
6 · Evidence
What must be preserved before change?
Save relevant timestamps, screenshots, IDs, logs, paths, policy results, event details, device state, or exact configuration values before they disappear or are changed.
Write: Evidence captured and where it is stored.
7 · Next test
What single test reduces uncertainty most?
Choose a test that separates two plausible causes. Prefer observation or comparison before reset, rebuild, disablement, or broad configuration change.
Write: If this test succeeds, what does that prove? If it fails, what does that prove?
8 · Safety
What is the risk and rollback?
Before a change, identify who could be affected, what could break, whether access or data could be lost, and exactly how to return to the previous state.
Write: Blast radius, rollback, and approval boundary.
9 · Verify
What result will count as fixed?
Define the business workflow that must succeed. A service starting, tunnel connecting, profile opening, or policy saving is not enough if the required workflow still fails.
Write: Verification test and expected result.
10 · Escalate
What would make you stop and hand off?
Escalate when the next useful step is unsafe, requires authority you do not have, crosses a security/compliance boundary, threatens data, or needs specialist/vendor access.
Write: Escalation trigger and evidence package.
Fast comparisons that remove branches
These are not universal fixes. They are controlled comparisons that help isolate the layer.
User vs device
Same user, another device
If the failure follows the user, move toward identity, policy, permissions, mailbox/account state, or user-specific data. If it stays with the device, move toward local client, profile, cache, device policy, or hardware.
Device vs user
Another user, same device
If another user succeeds on the same device, the device may be healthy enough to move attention toward the affected identity or profile.
Client vs service
Browser vs desktop
If the browser path works while the desktop app fails, avoid assuming the cloud service is down. Move toward client state, cached identity, local policy, profile, add-ins, or device-specific conditions.
Network
Same workflow, another network
A different result across networks can move the investigation toward DNS, routing, proxy, filtering, firewall, VPN, ISP, or location-based policy.
What not to do in the first ten minutes
Early broad changes destroy evidence and add variables. Save them for when the evidence justifies them.
Do not reset everything at once
Password reset, MFA reset, profile rebuild, application reinstall, policy exclusion, and device removal at the same time may make the symptom disappear without proving why.
Do not copy a working configuration blindly
A known-good comparison is evidence. It is not permission to duplicate groups, ACLs, policies, routes, or security settings without verifying the intended design.
Do not restart shared infrastructure casually
A restart can clear symptoms while hiding root cause, interrupting users, and creating a larger incident. Establish scope, dependencies, approval, and rollback first.
Do not call a workaround a resolution
If the user can work only because you bypassed the normal path, document it as a workaround and keep the root cause open.
Turn the worksheet into the next troubleshooting path
Once the first ten minutes have narrowed the problem, move into the deeper method instead of starting over.
Need better scope?
Need a stronger comparison?
About to make a risky change?
Need to hand it off?
Think it is fixed?
Need the whole method?
When the next step becomes risky
Some problems stop being routine troubleshooting when the next useful action could affect shared infrastructure, privileged access, security controls, production data, backups, mail flow, identity architecture, or several users at once. That is the point to slow down, preserve evidence, confirm rollback, and bring in experienced help if needed.