• Choose a category
• All
• Classic-Fiction

The best way to verify full system functionality is to have the user do whatever she needs to do on the repaired system for a few minutes while you watch. Any minor errors (such as incorrect default printers) will quickly become apparent, and you might learn some interesting aspects of how the user does her job. Knowing what your users do is critical for good techs to help them do their jobs better (Figure 27-16).

Figure 27-16 Ford the Tech sticks around and watches.

If Applicable, Implement Preventive Measures A very smart tech once told me, “A truly good support tech’s work goal should be to never have to get out of his chair.” That’s a pretty tall order, but it makes sense to me. Do whatever you can to keep this problem from repeating. For some problems, there are obvious actions to take, such as making sure anti-malware is installed so a computer doesn’t get infected again. Sometimes there’s no action to take at all: nothing can prevent a hard drive that decides to die. But you can take one more critical action in almost every case: education. Take advantage of the time with the user to informally train him about the problem. Show him the dangers of malware or tell him that sometimes hard drives just die. The more your users know, the less time you’ll spend out of your chair.

Document Findings, Actions, and Outcomes

I think the famous historian George Santayana would have made a great PC technician when he said, “Those who cannot remember the past are condemned to repeat it.” As a tech, the last step of every troubleshooting job should be documentation. This documentation might be highly formalized in some organizations, or it might just be a few notes you jot down for your own use, but you must document! What was the problem? What did you do to fix it? What worked? What didn’t? The best guide to use for documentation is: “What would I have liked to have known about this problem before I walked up to it?” Good documentation is the strongest sign of a good PC tech (Figure 27-17).

Figure 27-17 Ford documents a successful fix.

Documenting problems helps you track the troubleshooting history of a machine over time, enabling you to make longer-term determinations about retiring it or changing out more parts. If you and fellow techs fix a specific problem with Mary’s machine several times, for example, you might decide to swap out her whole system rather than fix it a fourth time.

Documenting helps fellow techs if they have to follow up on a task you didn’t finish or troubleshoot a machine you’ve worked on previously. The reverse is also true. If you get a call about Frank’s computer, for example, and check the records to find other service calls on his computer, you might find that the fix for a particular problem is already documented. This is especially true for user-generated problems. Having documentation of what you did also means you don’t have to rely on your memory when your coworker asks what you did to fix the weird problem with Jane’s computer a year ago!

Documenting also comes into play when you or a user has an accident onsite. If your colleague Joe drops a monitor on his foot and breaks both the monitor and his foot, for example, you need to fill out an incident report, just as you would with any kind of accident: electrical, chemical, or physical. An incident report should detail what happened and where it happened. This helps your supervisors take the appropriate actions quickly and efficiently.

Tech Toolkit

Way back in Chapter 2, “Operational Procedures,” you learned the basic parts of a tech toolkit—a Phillips-head screwdriver and a few other useful tools, such as a Torx wrench and a pair of tweezers. Any good tech makes a point to carry around at least these tools (Figure 27-18). Over time, you’ll add more tools as your experience grows. But your toolkit won’t stop at Phillips screwdrivers and Torx wrenches. You should include two other types of tools in your tech toolkit: utilities and field replaceable units (FRUs).

Figure 27-18 Typical technician toolkit