How To Create Practical, Procedure Driven Computer Repair Processes

Written by Jeremy Oaks. Jeremy is a computer science graduate who works in managed IT and programs computer utilities in his free time.

How do you organize your repair process? How can you make the whole sequence from intake to pickup efficient and easy to manage? These questions become even more important as your business grows and you have multiple technicians, or if you are multitasking between phones, customers, and on site calls. Transitioning your process to be procedure driven can help you to manage your repair process to ensure quality and consistency.

Let’s talk about the conceptual idea of a procedure. In programming, a procedure is a set of steps that are packaged together. Think about your beginning to end process for a computer, and you’ll see some general phases (intake, diagnostics, recommendation, repair, checkout) each of which can be broken down into individual steps. The goal of procedure driven repair is to organize the process in such a way that it is inherent where the computer is in the process, and to make individual components of the process easy to modify without systemic modifications.

Before I dive into moving to procedure driven repairs, I’d like to explain why it’s worth the switch. Many technicians are top-notch when it comes to understanding issues and fixing them rapidly, and this creates a tend towards jumping head long into an issue–sometimes missing the forest through the trees–especially when under pressure from a customer. Technicians also tend to have multiple repairs going on simultaneously, and it can be a productivity killer to recheck multiple things to figure out where you left off with a particular repair. Some carefully designed procedures can help eliminate issues such as these, as well as making changes to the repair process easier to implement and more targeted.

So, what makes good procedures? In general, good procedures are:

• Specific: A procedure should target a specific task. This helps prevent hard to follow “spaghetti logic” scripts and check lists.
• Self documenting: Procedures should be named descriptively, so any technician could look at your procedures and understand what they are. This makes on boarding new technicians or partnering with other parties easier.
• Widely applicable: Procedures are powerful when everything you do is governed by one. Thus, procedures should be written with the average repair in mind (and let human logic cover the occasional deviation from norm).

So, let’s dive into procedure making. The first place to start is with whatever you already have for procedures. This may be a checklist, or perhaps a script that performs certain tasks for you. Now that you have that, the next task is to analyze it and see what it does–in the sense of how many tasks it does. Your checklist might be for everything from intake to diagnostics to malware removal. Your goal should be to separate each line item into a group of similar items, and to separate the groups.

Hopefully you now have procedures (groups of related tasks). Now it is time to implement them, via scripts, check lists, or your favorite method. Our goal is to make it easy to see where a procedure is at (to prevent lost time figuring out the status of a machine) and to make it easy to figure out where in the over all work flow a machine is at. This means that a single 50 step procedure is bad, and 50 single step procedures are also bad.

All this may seem a bit theoretical and abstract, so here is a short example. Please note the following formatting convention:

• Phase
  • Procedure
• Diagnostics
  • Hardware Diagnostics
  • Software Diagnostics
• Tune up
  • Software cleanup
  • OS Configuration
  • Software install
  • Patching

Now, each procedure should be short and sweet, and not involve any other phase. If we take our tune up phase as an example, we should be able to change our patching procedure (say from Windows Update to WSUS Offline) without affecting the software install procedure. Designing repairs this way makes it easy to manage changes, so one tweak does not require an overhaul of everything. I also find it to be motivating, where once I get one procedure running smoothly I get the urge to work on another procedure.

When working with multiple technicians, the above model also works nicely with change control. Let’s say a new program needs to be installed. It would be very easy to take the script (or check list, etc) for the software and modify it to include the new program if you don’t need to fight the spaghetti logic of a 400+ line all-in-one script or figure out where to add the software install on a convoluted multi-page check list.

Now, I’d like to make an appeal to you: design your procedures with the intent on performing them on every computer you work on. When you go to the doctor, your vital signs are taken with every visit, and when something is wrong the doctor tests for lots of seemingly unrelated things. Similarly, your procedures will pay huge dividends if you include things like mandatory malware scans or hardware checks, even for seemingly unrelated issues. [Checking hard drive health was the biggest up sell at my last job; 20% of laptops had failing drives. A full hardware check was a mandatory part of the diagnostic procedure.] This not only helps to maximize profits, but it also saves the headache of getting the customer to approve a tune up and then having to call back and report that you didn’t catch the failing hard drive at first.

On a practical note, you can implement procedure driven repair in multiple ways. The important factor is the logical construction, not the details of implementing it in your shop. If you have a long single script, you can organize your code and make it procedure driven. If your shop is check list based, you don’t need to script anything to see benefits from procedures. However, procedure driven repair lends itself to scripting, so if you have been thinking about scripting part of your process, this is a great place to start.

At the end of the day, moving to procedure driven repair and creating good procedures that are run on every computer you work on will make management less stressful and produce higher quality repairs as changes are easier and fewer things slip through the cracks (because checking xyz is procedure for you now). With all the benefits, it’s time to look at your process and give it a revamp.