Field Service Records That Pay Off: Questions to Answer Before the Technician Arrives
When a technician walks into a small office, shop, or clinic to fix something, the visit itself is often the easy part. The hard part comes days or months later, when someone asks what was changed, which device was touched, or why a cable now runs across the ceiling. Field service documentation is the habit of answering those questions in advance. It does not require expensive software or a dedicated administrator. It requires a short list of facts, collected at the right moments, and stored where someone can find them. This article describes a practical method for building that record, with specific questions to ask and a checklist you can adapt to your own operation.
Start with the problem statement, not the fix
Most visit records begin with what was done, but the most useful entry starts with what was wrong. Write down the symptom as the person experiencing it described it: the printer drops off the network every afternoon, the point-of-sale terminal freezes during card processing, the back office Wi-Fi is slow after lunch. Record who reported it, when they first noticed, and whether the problem was intermittent or constant. These details are often lost once the technician begins working, and they matter later when you are trying to tell whether a problem is truly resolved or only quiet for a day.
Ask the reporting person three questions before the visit: what were you doing when it happened, what changed recently, and what have you already tried. A new router, a software update, a moved desk, or a restarted machine can each explain an odd symptom. A short note capturing those answers gives the technician a head start and gives you a baseline to compare against after the work is finished.
Capture the environment before anything moves
Before a technician opens a cabinet or unplugs a device, a few photographs are worth more than a page of description. Photograph the front and back of racks, switches, and wall-mounted equipment with enough detail to read labels. Photograph the area around a workstation, including where cables enter the wall and what sits on the floor beneath the desk. These images show the starting state, which is useful if someone later needs to understand why a device was moved or why a patch cable has a particular route.
Keep these photos with the visit record rather than in a general phone camera roll. Name the files with the date, location, and asset identifier if you use one. A folder per site with subfolders per visit is enough for most small operations. The goal is retrieval: six months from now, you should be able to find the picture of the closet as it looked on the day of the visit without scrolling through hundreds of unrelated images.
Record equipment identity, not just equipment names
Names such as 'front desk PC' or 'the big printer' stop being useful the moment staff changes or a device is replaced. Record the make, model, serial number, and any asset tag affixed to the hardware. For network equipment, note the management address if one exists and the firmware version shown in its interface. For computers, note the hostname as it appears on the machine and the user it is normally assigned to. These identifiers let a later technician match your written record to the device in front of them without guessing.
When a device is replaced rather than repaired, record both the old and new identifiers in the same entry. Note what happened to the removed unit: returned to a vendor, stored, or disposed of. Disposition records are often skipped, and they become important when someone asks where a drive containing business data went.
Write down what was actually changed
A closeout note should describe changes in terms specific enough that a stranger could reproduce or reverse them. 'Updated network settings' is not a usable record. 'Changed the printer's static address from 192.168.1.40 to 192.168.1.50 and updated the two workstations that map to it' is. Include configuration changes, software installed or removed, accounts created or disabled, and any password resets performed. If a password was changed, record that it was changed and who now holds it, but never write the password itself into an informal note.
Also record what was tested and how. A visit where the technician confirmed that printing works from three workstations is different from one where the technician simply reports that the printer is fixed. A short list of checks, with the result of each, gives you something to compare against if the problem returns.
Obtain a sign-off that means something
A sign-off sheet is most valuable when it separates what the technician completed from what the customer accepted. Include a line for work completed, a line for any work deferred or requiring a follow-up visit, and a line for the person who confirmed the result on site. Date and time should be written by hand or entered at the moment of signing, not reconstructed later. If the technician leaves with items open, list them explicitly so they are not lost between visits.
Keep a copy of the signed sheet in the same place as the photos and notes. A signature that lives in someone's inbox while the photos sit on a phone does not form a coherent record.
A practical checklist and a simple comparison
Before the visit, confirm the symptom description, the reporting contact, any recent changes, and the access instructions for the site. Confirm who is authorized to approve changes and whether any systems must stay untouched during the work. During the visit, photograph the starting state, record identifiers for every device touched, and note each change as it happens rather than at the end of the day. After the visit, file the photos and notes together, record the sign-off, list any open items with owners and dates, and schedule a short check to confirm the fix held.
Compare two approaches. In the first, the business relies on memory and a verbal summary from the technician, with records scattered across texts and email. Six months later, nobody can confidently say which firmware was running on the firewall or who approved the last password change. In the second, each visit produces a dated folder containing the problem statement, starting photos, device identifiers, a change list, test results, and a signed closeout. The second approach takes perhaps twenty extra minutes per visit and saves hours of reconstruction when something goes wrong later. Use whichever format your team will actually maintain, but make the choice deliberately rather than by default.