In the past two years there has been an increasing trend among my own clients for requiring that the appropriate Security and IT contacts receive a copy of all security system service tickets. For major deployments such as at airports, this has been a typical requirement for over a decade.
However, outside of critical infrastructure projects, I often see this kind of report:
Video recorder not working
Work Performed in Detail:
Reset video server, adjusted motion detection, confirmed recorded video plays back in client software.
There is no root cause analysis. The customer said "video recorder not working", but of course that's a guess as the actual symptom was, "Recorded video is not available in the client software."
How many problems were actually found? The video server was reset. Motion detection was adjusted. That sounds like two problems.
Why was the motion detection reset? Was it in the VMS or in one or more cameras?
When I called to suggest that this was not really a report "in Detail", the following expanded description was provided:
Re-set video servers, adjusted motion detection, and confirmed video was able to play back on work station up-stairs. Set camera 12 to cont. recording per customer request. Camera 2 was recording to C drive, switched camera to record to video storage drive I that all other cameras were recording too.
So now there are two video servers? Why did the customer want Camera 12 set to continuous recording? This could reflect a change to the risk picture. If it is just for temporary investigation purposes, it may need to be changed back so as not to reduce the retention period. It depends upon how assurance of video retention is currently being achieved (i.e. per-camera setting or just disk space allotment).
It is odd that Camera 2 was set to record to some special location. Service records don't show that change.
Why weren't the server logs and operating system logs checked before or after the reset? Does "reset" the video server mean a soft or a hard reboot? Was the server O/S running or was the server machine completely crashed?
It turned out that there were multiple problems, and certainly more should be known about them.
Without a detailed and accurate service history, how can you distinguish between a series of unrelated problems, and a recurring problem?
The Electronic Security Association (ESA) has a Troubleshooting, Service and Maintenance online course whose first section is called "The Troubleshooting Mindset". When I first got involved in security technology nearly 30 years ago, such a mindset was common among service technicians. Now it seems to be a rarity.
So I'm looking for what might be accepted as "good practice" for information that should be included in a service ticket or service report that goes to the customer.