Guides
ICT Maintenance: Write a Useful Fault Report Without Sending Passwords
Prepare an ICT maintenance report with observed symptoms, business impact, a clear timeline and a safe evidence index before arranging support.
DETIAN ICT · Tanzania & East Africa
Discuss your ICT project with DETIAN.
DETIAN ICT supports audiovisual, security, network and smart-building projects in Tanzania and East Africa, with design, equipment supply, installation and maintenance services.
Share your site location, required systems and available drawings or equipment list. Start a discussion about the work scope and the information still needed.
Start with the function that stopped working
A useful maintenance request tells the receiving team what people cannot do, where it happens and what evidence is available. Start with the affected task: a workstation cannot reach an application, a display shows no selected input, or a door reader does not respond as expected. Record what was observed before naming a failed component.
For an office, factory or project site, keep one report owner and one issue reference. That person can collect updates from users, the local facilities team and existing suppliers without creating several conflicting accounts. The worksheet below is for the initial support discussion; it does not diagnose the fault or authorise changes to a live system.
Cisco’s guidance for opening a support case asks for the affected service, user impact, duration, software or firmware version, reproducibility and occurrence time. Those are useful checks on the clarity of a report. Cisco support entitlement and procedures apply to its own cases; citing that guidance does not establish DETIAN brand authorisation or a manufacturer support agreement.
Use a report header and an observation record
Report header — assign an issue reference; identify the country, town, site and exact room or area; name the report owner and the person who can arrange site access. Use an equipment label that can be matched to your records. If the label or model is unknown, say so and identify who can check it safely.
Observation record — describe the expected task and the actual result in separate fields. Add the relevant visible message, affected locations, known working locations and the operational consequence. Distinguish an observed count from an estimate: “three reported failures among eight desks checked” tells the reader more than “everyone is offline”.
Do not convert an untested area into a working area. Mark it “not checked”. A desk that still works is a useful comparison only when the report says what was tried and when. Avoid declaring a whole network healthy because one website opened on one device.
Keep the wording understandable to both the site contact and the technical reviewer. For example, “the reception computer displays the application sign-in screen, then shows the attached error” is more precise than “server broken”. A suspected cause can be recorded separately with the reason it is suspected.
Keep a timeline that separates events from explanations
Write the time with its date and time zone. Include the last known successful use, the first observed failure and subsequent changes in the symptom. If an equipment clock differs from the observer’s clock, record that difference as an uncertainty instead of silently adjusting the evidence.
Use four columns for updates: time; person or evidence reference; event observed or action already taken; result. A power interruption, scheduled maintenance or software change may be relevant, but happening earlier does not by itself prove the cause. Identify which events are confirmed and which were reported by someone else.
Record actions that authorised staff have already taken and their actual results. Do not repeatedly restart, reset, update or alter settings merely to make the report look complete. Ask the responsible technical owner to agree any further checks, their operating impact and the permitted access before work starts.
See how an incomplete report becomes a usable handoff
The following is an invented documentation example, not a DETIAN customer incident or a diagnosis. A site coordinator initially writes, “The network is down again.” The revised record says: “Issue EX-01, reception area. At 09:10 EAT on 13 October, three of eight checked desks could not open the shared scheduling application. The remaining five opened its start page at 09:15. Other rooms and functions have not been checked.”
The impact entry says: “Reception staff at the three desks are recording appointments using the site’s approved temporary process. The report owner will confirm whether later reconciliation is required.” The timeline adds: “The application was last confirmed working at those desks at 08:40. A facilities contact reports a power interruption at 08:55; the IT owner has not confirmed a relationship.”
The handoff adds two open questions: “Which equipment and application versions apply?” and “What authorised check should the local contact perform next?” Screenshot EX-01-A is listed with its capture time and a note that personal details were removed. No password, full configuration archive or remote-access code is included.
This version lets the receiving team see the observed boundary, business consequence and missing information. It still leaves the cause open. The working comparison and reported power event are clues to review, not proof that any particular device should be replaced.
Send an evidence index before a collection of sensitive files
List each available item with a short reference, what it shows, when it was captured, its owner and whether it has been reviewed for sharing. Examples include a cropped error screenshot, a photo of an equipment label, an approved site drawing or a log excerpt held by the administrator. Mark items that have not yet been collected.
Keep passwords, recovery codes, private keys, session tokens and remote-access codes out of the initial message. Review screenshots for account details, personal records and confidential business content. An equipment photo should not reveal a password label or unrelated screens. Do not assume an exported log or configuration backup is safe to attach in full.
When a reviewer requests a diagnostic file, first agree the exact item, purpose, authorised recipient and approved transfer method with the system owner. Retain the original in its controlled location; share an approved copy with any redactions identified. If redaction removes information needed for diagnosis, agree an appropriate restricted transfer rather than posting the original to a broad group.
Support access is a separate decision from sending a report. Have the authorised administrator agree the person, scope, timing and termination of any access under the organisation’s procedures. A request for help should not quietly become permission to change accounts, reset equipment or interrupt service.
Agree ownership and the next update
Attach the relevant support or warranty reference if one exists, without assuming that every connected component is covered by the same supplier. Name the owner of the affected application or system and identify any other provider already handling a related case. Keep their case references with the issue so duplicate instructions can be spotted.
Ask the receiving team to confirm the next information needed, who will supply it and how updates will be recorded. Discuss remote assistance and site attendance in light of the actual location, access conditions, authorised contacts and agreed service scope. Record response arrangements from the applicable agreement rather than inventing a universal deadline.
When service appears restored, record the exact task checked, location, time and person who confirmed it. Keep remaining restrictions or intermittent symptoms visible. A device becoming reachable does not alone show that the original business task works again.
Contact DETIAN with the site and support requirement
For a maintenance discussion, send the project country and town, affected system, concise symptom and impact, existing support arrangement, site contact and evidence index. State what help you are seeking and which details remain unknown. Send sensitive technical material only after the recipient and transfer arrangement have been agreed.
DETIAN’s public pages describe AV and collaboration, security and access, networks and data rooms, and smart building solutions, with design, supply, installation and maintenance services. Use the official contact page or [email protected] to discuss the specific site and required scope. Availability, site attendance and response arrangements need confirmation for that enquiry.
