When an engineer visits a site you cannot see, the report is your only view of what happened. A report that says "done" tells you nothing. A report with the right photos, test results and asset records lets you close the ticket, answer an auditor and undo the change if you need to.
This article lists what a visit report should contain and how to check one. It applies to remote hands, installs, moves and cabling visits alike. The exact fields depend on the task, so agree them in the scope before the visit.
What is a field visit report?
A field visit report, often called a closeout report, is the written record of what was done on site, by whom, when, and what state the equipment was left in.
It turns a visit into evidence. The remote team can verify the work without traveling, the ticket can close with proof attached, and the next engineer starts from facts. Our glossary entry on the closeout report gives the short definition.
What should the photos show?
Photos should show the location, the equipment, the connection and the result, before and after the work, so a reader who was not there can follow it.
Agree the photo list when you agree the task. A good set covers the following.
Agree the photo rules at the same time, because many facilities restrict cameras. Keep other customers' equipment, screens showing data and people out of frame unless the customer has agreed. State where photos are stored, who can see them and how long they are kept. If photos are not allowed, agree what written evidence replaces them, such as a signed checklist or a live video check with your remote team.
- A wide shot of the cabinet or area before work starts, with the rack ID visible.
- A close-up of each device label, asset tag and serial number.
- The ports or cables involved, with labels readable, before and after the change.
- The status lights after the work, showing the expected state.
- A replaced part with its label, and the new part installed.
- A final shot of the tidy cabinet, with cable management and doors closed.
- Any damage or existing fault found on arrival, shown before touching anything.
Which test results belong in a visit report?
Include whatever result proves the work functions as intended, and name it in the scope so nobody has to guess.
The right evidence depends on the task.
| Task | Evidence to include |
|---|---|
| Copper cabling | Per-link certification result files with pass or fail, the standard tested to, and the tester model and date |
| Fiber cabling | Insertion loss, length and polarity per link, plus an OTDR trace if the scope asks for one |
| Server or part swap | Boot and health status confirmed by your remote team, with the time of confirmation |
| Cable or port change | Link state and speed on both ends, confirmed against the request |
| Move or install | Power-on and connectivity check, plus the user or site contact's acceptance |
Which asset records should a visit update?
A visit should leave your asset records matching the physical site, field by field.
A report that lists changes without updating the records leaves you with two versions of the truth. At minimum, ask for these fields.
- Asset tag, make, model and serial number of every device touched.
- Location: site, room, cabinet and U position.
- Connections: which port connects to which, with cable label IDs.
- Status after the visit: installed, moved, changed, removed or disposed.
- Old and new part serial numbers for any swap.
- For disposal, the sanitization method and a certificate per asset.
What does a report for a drive swap look like?
A drive swap report follows the request from start to finish, so a reader can check each step against the ticket.
This generic example shows the order. Your own fields may differ.
- Request: ticket number, requester, authorizer and the task as written.
- Arrival: time on site, who escorted the engineer, and the cabinet and U position of the server.
- Before: photos of the cabinet, the failed drive's bay light and the drive label.
- Action: the drive removed, its serial number, and the replacement's serial number.
- After: photos of the new drive seated, its bay light, and the cabinet closed.
- Verification: array or health status confirmed by your remote team, with the time.
- Records: asset entry updated with the new serial number, and the failed drive's disposition.
- Close: departure time, open items and the name of the person who accepted the work.
What else belongs in the report?
Add the context that makes the evidence trustworthy: the request, the authorization, the timeline, the deviations and the sign-off.
Include the ticket or change reference, who authorized the work and who escorted the engineer. The authorization line matters most when a facility or auditor asks who approved a change.
Record arrival, start, finish and departure times. State any step that differed from the plan and why. List open items, such as a part on order. End with the name of the person who accepted the work.
Cabling work also needs labeling and records in line with an administration standard, such as TIA-606. For disposal, NIST publishes media sanitization guidance in SP 800-88.
How can I check that a visit report is good?
Test the report with one question: could someone who was not on site say what changed, prove it and reverse it?
Also agree how long reports are kept, where they are stored and who can open them. Reports help with a repeat fault where history matters, a warranty claim where you must show how a part was installed, and an audit where you must show who touched what. Photos can show people and other systems, so treat them as data you protect.
If the answer is no, the report is missing something. Check that the photos show labels and results. Check that test files are attached, not just described. Check that the asset record matches the report. We agree the report content in the written scope, and our remote hands request template and visit checklist show the same fields from the request side.
Key takeaways
- A visit report is evidence, not a status line. It should let a stranger see what changed and prove it.
- Agree the photo list, photo rules, test evidence and asset fields before the visit.
- Attach native test files and update the asset records, so there is one version of the truth.
- Judge any report by one question: could someone not on site say what changed, prove it and reverse it?