Write a trouble ticket: date, reporter, symptom, affected systems, tests performed, root cause, fix, time to resolve and follow-up action. A knowledge base of past fixes saves time later.
Sample trouble ticket
| Field | Example |
|---|---|
| Ticket / date | #0142 · 14 March 2026, 10:20 |
| Reported by | Accounts office, PC ACC-03 |
| Symptom | Cannot open websites; email in Outlook still works |
| Affected systems | One PC only |
| Tests performed | ping 8.8.8.8 succeeds; ping www.google.com fails; ipconfig /all shows DNS server 192.168.1.100 |
| Root cause | DNS server address typed incorrectly (should be 192.168.1.10) |
| Fix | Set the adapter back to obtain DNS automatically (DHCP); ipconfig /flushdns |
| Time to resolve | 15 minutes |
| Follow-up | Remove local administrator rights so users cannot change network settings |
Check yourself. When you have finished this unit, try the 9.8 hands-on lab and the 9.9 review questions.
What to write in a ticket
Good documentation turns a one-off save into institutional knowledge:
- Reported problem (user words) and actual impact
- Environment (who, where, IP, VLAN, time)
- Steps to reproduce and tests you ran (commands + results)
- Root cause (not only the symptom)
- Fix applied and verification
- Prevention (monitoring, config standard, user guidance)
Even a short lab notebook with timestamps helps assessments and real jobs. Templates beat blank pages when you are busy.
Sample line: "10:40 – PC Lab2-05 has APIPA. Cable OK. DHCP scope exhausted. Freed unused leases; PC received 10.20.1.45. Documented scope capacity warning."
Remember
- If it is not written down, the organisation will solve it again from scratch.
- Record cause and prevention, not only "fixed".