Define the problem before changing anything
Ask what the user expected, what actually happened, when it started, who is affected and what changed recently. Record exact error messages. “The system is slow” is a symptom, not yet a useful technical definition.
Establish the scope
Check whether the issue affects one user, one device, one location or the whole organisation. Scope helps distinguish a local configuration problem from a service or infrastructure failure.
Develop and test a theory
Start with the most likely causes, but do not confuse familiarity with evidence. Test one controlled change at a time. Multiple simultaneous changes make it difficult to know what resolved the fault and can introduce new risks.
Protect data and service continuity
Before making a high-impact change, consider backups, permissions, downtime and rollback. Follow change-control and escalation processes. A technician’s objective is not merely to remove an error; it is to restore service safely.
Verify the full solution
Repeat the original task, confirm related functions still operate, monitor the result where appropriate and ask the user to verify the outcome. A device restarting successfully does not prove that the original problem has been solved.
Document what happened
- The reported symptoms and business impact.
- Evidence collected and tests performed.
- The root cause, where confirmed.
- Actions taken, approvals obtained and outcome.
- Any preventative work or follow-up required.