What Info Should A _good_ Service Ticket Contain?

Hey Ray,

Good scenario. Very sloppy documentation. This statement says everything: "Without a detailed and accurate service history, how can you distinguish between a series of unrelated problems, and a recurring problem?".

But, I see this more as a failure on the operations/svc mgrs part more than on any individual techs part though.... techs are fireman - running around in vans between fires all day. And their bosses are always reminding them to try and battle more fires each day...etc.

If there was even a rudimentary system in place that mandated what information was required to close a 'ticket', then techs would use it - and customers would remain informed.

The integrator has a support entity that tries to troubleshoot stuff over the phone first before they roll a truck, no? Why can't the field tech (who generally has a laptop) just have creds to log into the same tracking system the support person uses to enter details of the onsite trip? Set required fields (at least) and mandate detailed comments. Then, the integrator could answer your questions regarding this service call - and what the heck was going on with Cameras 2 and 12...! :)

Notes:

1. The 'video server' most likely needed to be 'reset' because some idiot pointed Camera 2 to record to the same local disk (C:) that the OS runs on - which filled it up, causing the OS to lose the ability to do pretty much anything. (I'm fluent in Fieldtech Scribble)

2. Changing Camera 12 to FT Record will do exactly as you described. Needs documentation. Documentation avoids culpability arguments later.

3. 'Adjusting Motion Detection' makes no real sense.... unless the tech assumed (illogically) that cameras weren't recording because the motion detection sensitivity was set too low. (I'm fluent in dealing with illogical techs)

4. Giving the tech the benefit of the doubt, I'm gonna say 'servers' was a typo. :)

I coach our customer service people who take inbound trouble ticket service requests and then process the tickets for billing to try and follow these guidelines for populating the invoice description:

1. Describe what the customer initially requested

2. Describe what the tech found when arrived on site (not usually the same as 1 and what is presented as a problem is in fact a symptom of an underlying problem)

3. Describe the testing, and troubleshooting done to find the problem. What was the actual problem.

4. Describe what repairs were done, parts replaced that fixed the problem and final resolution.

I have found analysis of trouble tickets for underlying causes not to be very fruitful and does not yield any trends to act upon that we don't already know (devices with high failure rate). To train techs to develop trouble shooting skills, we get the techs to contribute to our troubleshooting guide which is populated with a list of unique symptoms as they encounter them. The same symptom can have multiple causes. For the cause, when the problem was eventually fixed, what was the test or procedure to confirm or eliminate that as a cause and if it is that cause, what is needed to repair.

Hope that helps.

I second Robert's recommendation of reporting guidelines and troubleshooting guide / symptoms. I think this will help but also feel this is an uphill battle against two more severe problems, specifically:

• A lot of junior people in technical roles are unfortunately very vague, especially in writing. They, for whatever reason, do not even realize that their 'analysis' of the problem is incredibly superficial and of very little help.
• Likewise, many lack the underlying conceptual understanding to allow them to recognize things that are out of place. If you do not know how a device is designed to work, it's incredibly hard to figure out what is wrong (especially if it does not fall neatly into a list of common problems).

Seeing these types of reports infuriates me as that type of approach is incredibly inefficient and may never solve the problem (without getting someone else involved to redo it).

I suspect it's an educational system issue as most schools allow students to be sloppy with their word choices but in solving technical problems small details make huge differences (server vs servers, how did something crash, was a hard or soft reboot done, etc.).

So while I think some structure will help compensate (like training wheels), the underlying problems are far deeper.

I was at an ASIS Infrastructure group meeting a few years ago and the subject of change management came up. As an IT professional I proposed that the Security industry should take a closer look at ITIL. This stands for Information Technology Infrastruture Library. It is basically a set of best practices for IT service management. It's a well tructured and mature methodology of performing services. There are many components that could be adopted by the Security industry to standardize on service management.

I saw this all the time at the Integrator and IMO it's a failure in Management. Usually service techs are over worked and their paperwork suffers from it. That and a lack of training on how to do it right. Never assume someone automatically knows the best way something should be done, you have to provide the proper training.

At the integrator I came from, a substantial portion of work was performed by subcontracted installers and service techs. One of the conditions to pay an invoice was 'proper documentation' of the work performed.

The method that was used: the techs did not fill out their own summaries. Ever. Rather, a clerk would call them an play the game of 21 questions until 'good' information was fleshed out. No pencil whipping job documentation, just the tech and a clerk (usually this clerk was someone cross trained as a troubleshooter) on the phone. The clerk entered details into the job notes. We figured an extra 30 minutes of labor into a typical service call for this call, and it proved useful in improving job notes.

With a large accumulation of details in a database, the raw data could then be searched by keyword, platform type, location, or a range of dynamic search terms to uncover useful details in future work. Think 'micro-Google'.

Brian does describe a workaround that seems practical. I can see even an experienced technician prefering the call approach to having to write concise and accurate notes about the problem and the work done. The service call could be closed out immediately following the call (providing the issue was sufficiently addressed), and in the event the service tech had to get more information to close out the ticket, the tech would still be on site—much better than discovering it after a 1-hour drive back to the office.

It would seem to be more efficient to have an online system to log into, that by form or prompting would ask for the pertinent information. Lots of techs could report at once, whereas the phone call approach would be subject to peak load issues. A drawback might be that the QA on the report may follow immediately, which might still have the tech going off site before all needed information was captured.

The Search aspect would be very valuable. This is an intestesting approach, and could be implemented quickly regardless of the current method of data capture (docs, ticket system, or database application).