Support
Part of Small office IT support
Keeping a record of recurring technology faults
Keep a useful fault history with dates, symptoms, workarounds, case owners and follow-up so repeat IT problems can be investigated.
Record every occurrence of a fault that keeps interrupting work, including times when a restart appears to restore service. Linked entries show when the symptom returns, which workaround staff use and who owns the next step.
Use the existing support system where possible, so the record stays connected to requests people already follow.
Record each occurrence consistently
Where the ticket system cannot link related cases, use a controlled shared log with a named owner. Give each occurrence its own date and local time, then link cases that may be related. Do not merge different symptoms solely because they involve the same device.
Field / What to record
- Affected task
- What the worker could not complete
- System and location
- Device or service identifier and where the fault appeared
- Timing
- When it began, when work resumed and any uncertainty
- Reach
- People or roles affected, if known
- Symptom
- Exact error or observed behaviour, separate from a guessed cause
- Action and result
- What was tried, by whom and what happened
- Case and owner
- Support reference, next action and responsible person
Keep personal information to what the case needs. Store sensitive screenshots or diagnostics in an approved support channel with appropriate access controls.
Distinguish a workaround from a fix
“Printer restarted; job succeeded” records what happened; it does not establish why printing stopped. If the cause remains unknown, record a follow-up owner. When the same issue returns, add a new occurrence and link the earlier case so support can see the sequence.
After a technician changes a setting or replaces a part, record the change and ask an affected worker to repeat the original task. If the result is uncertain, keep a follow-up action open. A period without symptoms alone does not prove the underlying fault is resolved.
Review patterns before changing anything
At a regular support review, group entries by task, service, location and timing. Look for repeated interruptions, workarounds that take staff effort and cases passed between suppliers.
Give the provider relevant examples and case numbers. Ask what evidence could distinguish a local fault from a service fault and what action is justified.
A fault log can inform repair or escalation. It does not by itself prove that equipment needs replacing.
Route suspected incidents separately
Send a suspected compromise or data loss through the organisation's incident process promptly. The ACSC publishes practitioner guidance on cyber security incident response planning. A routine fault record can point to the incident case without exposing sensitive details or delaying escalation.
Give someone responsibility for reviewing open entries, confirming fixes and handling personal details under the business's records policy.
