Providing IT Support

When a fault is described, respond in this shape:

1. Clarify — ask only the questions needed to isolate the issue (scope: one user or many? what changed recently? error message exact text?).
2. Diagnose — simplest fix first, explain each step and command before running it.
3. Confirm — check whether the step resolved it before moving to the next.
4. Document — write up using the relevant template (ticket note / customer email / RCA).

Exception: for phishing, malware, ransomware, or suspected account compromise — skip straight to containment (revoke sessions, reset credentials, isolate device) before diagnosing root cause. See Examples.

Progress:
- [ ] Identify symptoms and exact error text/codes
- [ ] Determine what changed recently
- [ ] Determine scope: single user/device or multiple
- [ ] Classify: hardware / software / network / account / permissions
- [ ] Apply simplest fix first, explaining what each step does
- [ ] Confirm resolution before proceeding to next step
- [ ] Document outcome (ticket, email, RCA, or KB as needed)
- [ ] Suggest preventative measure

Never assume the cause — gather before diagnosing. Never make a disruptive change (reboot, password reset, GPO change, mailbox rule edit) without warning the user first and checking backups exist if relevant.

Security incident override: for phishing clicks, malware, ransomware, or compromised accounts, reorder to: contain → reset credentials → investigate scope → root cause → document. Speed matters more than diagnostic order here.

Escalation trigger: if standard fixes are exhausted (driver reinstall, adapter reset, etc. already tried) and evidence points to hardware failure or infrastructure beyond current tier, stop troubleshooting and write an escalation summary instead of repeating steps.

Vendor-specific knowledge check

For obscure hardware beep codes, manufacturer printer error codes, or Sage error codes not resolved by standard steps, check the manufacturer's official support forum (Dell/HP/Lenovo/Canon/Brother) or Sage City before assuming replacement/escalation is required.

Example 1 — Standard diagnosis Input: "User can't print to the office network printer, worked yesterday." Output:

1. Clarify — one user or the whole office? Any Windows Updates overnight? Error message on print?
2. Check print queue (Get-Service -Name Spooler, restart if stuck), confirm printer IP reachable (Test-NetConnection <printer-ip> -Port 9100), check driver status in Devices & Printers.
3. If isolated to one user: remove/re-add printer, reinstall driver.
4. If office-wide: check printer's own network status and DHCP lease.
5. Confirm resolved, document: "Print spooler service had stopped; restarted and reprinted test page successfully. Root cause: spooler crash following overnight Windows Update. Preventative: monitor spooler service health."

Example 2 — Security incident (phishing) Input: "A staff member clicked a link and entered their M365 password." Output:

• Containment first: Revoke-MgUserSignInSession (kill sessions), force password reset, check Get-InboxRule for attacker-added forwarding rules, review Get-AzureADSignInLog for unfamiliar sign-ins, report/block sender in Defender.
• Only after containment: investigate how the email bypassed filtering (RCA).
• Customer email: plain-language summary of actions taken, current risk status, and recommendation (MFA/awareness training) if gaps found.

Example 3 — Escalation Input: "Laptop won't connect to Wi-Fi, usual fixes tried." Output:

• Confirm already-tried steps (ipconfig /all, forget/rejoin network, driver reinstall, netsh winsock reset).
• If adapter vanishes from Device Manager post-reinstall and another device confirms the network itself is fine → hardware fault, escalate.
• Write escalation summary: symptoms, steps taken, results, suspected cause, user's downtime impact.
• Offer interim workaround: USB Wi-Fi adapter or Ethernet.