IT Support Done Right: A Practical Field Guide

Most IT support work gets judged on speed, but speed without a method just moves the same problem down the hall. A ticket closed in five minutes that reopens in three days costs more than one that takes twenty minutes and actually gets fixed. This guide covers the habits that separate someone who closes tickets from someone who solves problems.

Start with a real intake, not a guess

Before touching a machine, get the user to describe the problem in their own words, then ask three follow-ups: when did it start, what changed recently, and does it happen every time or intermittently. "My internet is slow" could mean DNS resolution, a saturated Wi-Fi channel, a failing NIC, or a browser with forty tabs open. Write down the exact error text if there is one. Screenshots beat descriptions every time — ask for one before you ask the user to try anything.

Resist the urge to jump straight to "have you tried restarting." It works often enough that people default to it, but if you skip intake you'll miss patterns. If three people on the same switch report the same slowness in the same hour, that's a different ticket than one laptop with a bad driver.

Reproduce before you fix

If you can't reproduce an issue, you can't confirm you fixed it. Ask the user to walk through the exact steps on a screen share, or do it yourself on their machine if remote tools allow. Check ipconfig /all on Windows or ip a on Linux for basic network sanity, look at Event Viewer (eventvwr.msc) for application and system errors around the reported time, and check journalctl -xe --since "1 hour ago" on Linux boxes for the same window.

For application crashes, get the exact build number and OS version. "It crashed" tells you nothing; "Outlook 16.0.17726 crashes when opening a calendar invite with an .ics attachment" tells you where to look. Cross-reference against known issues in vendor release notes before assuming it's local.

Triage by impact, not by who shouts loudest

A single user locked out of email is inconvenient. A shared file server unreachable for forty people is an outage. Build a simple severity scale — something like P1 for outages affecting multiple users or critical systems, P2 for single-user blockers, P3 for degraded-but-working, P4 for cosmetic or convenience requests — and apply it consistently, even under pressure from a manager who wants their thing first.

Document the severity decision in the ticket itself. This protects you later when someone asks why their P3 sat for two days while you handled three P1s.

Fix the root cause, not the symptom

Restarting a service that keeps crashing buys time, not a solution. If a print spooler dies daily, check Get-WinEvent -LogName Application -MaxEvents 50 for the actual error before restarting it again. If a user's password keeps expiring unexpectedly, check the group policy applied to their OU rather than just resetting it and moving on.

Keep a personal log of recurring fixes. If you find yourself typing the same PowerShell command or the same registry fix three times, that's a sign it belongs in a script or a documented runbook, not in your head.

Document like someone else will read it

Every ticket resolution should answer: what was the actual cause, what was the fix, and what would you check first if this happens again. "Fixed" as a resolution note is worthless to the next tech, including future you six months from now with no memory of this ticket.

A good resolution note looks like: "Root cause: DHCP scope on VLAN 20 exhausted, new devices got APIPA addresses. Fix: extended scope from /24 to /23, reservation for printer added. Verify: check DHCP lease count monthly, alert threshold set at 90%." That third sentence is the one most techs skip, and it's the one that prevents the repeat ticket.

Escalate with context, not just a forward

When a ticket goes to tier 2 or a vendor, include what you already ruled out. "Checked cabling, swapped port, confirmed VLAN config, still no link light" saves the next person from redoing your first twenty minutes. Vague escalations like "user says it's broken, please advise" just move the delay instead of removing it.

Close the loop with the user

Tell the user what was wrong in plain language, not just "fixed." People trust support more when they understand what happened, and it cuts down on the same person filing the same ticket next month because they don't realize it's connected.

If you want to go deeper on the technical side of any of this — networking fundamentals, Windows event logs, or scripting your own diagnostic tools — Korra Studio has segments on Networking, Systems, and Scripting worth working through next.