The Three R's Checklist That Prevent Callbacks - Technibble
Technibble
Shares

The Three R’s Checklist That Prevent Callbacks

Shares

When a client calls you back after you repair the computer, it’s a sign they’re dissatisfied with your work. We’re not talking about a new problem, but something they think you caused. Callbacks were causing problems in my computer repair business until we discovered a checklist with the 3 Rs: Reboot, Retest, and Re-confirm with the client.

Why Is This Checklist Important?

Clients expect the computer fixed right the first time. Lots of businesses claim to do that, but the clients don’t always see it that way. Fixing the problem, one time, isn’t enough. Your company needs to make sure it stays fixed. Probably the most dreaded call we get is “It’s still not fixed” or “I need you to look at the computer again.”

Sometimes it’s a simple misunderstanding or an unrelated problem. Each of these calls costs you time to explain the situation to the client. If you need to go onsite or put the computer back on the bench, you’re giving away non-billable time. Regardless of how much time you’ve spent, the most painful loss is the customer’s trust. They might tell others about the negative experience or leave you with a bad review. Even when you do everything right and fix the problem, if they perceive you made a mistake then the impression stays with them.  Using a checklist like this keeps the clients satisfied.

Restart: Restart 3 times

I learned early in my career to do this. Someone taught me “Once is random, twice is a coincidence, three times is a pattern.” Apparently this is a modification of a “Moscow Rule.” I think most techs know to restart once and maybe even twice. I don’t see many going through that third restart. That’s where the Issue occurs, though. You might have gotten lucky those first two times. After three restarts, though, any problems should show up. I don’t consider it resolved until I get to that third restart and it works.

Retest After Every Restart

During each of those restarts, you’ll want to test to make sure you fixed the original problem. Does the program crash? Does the malware show up? Is the error message gone? You get the idea. This procedure again goes back to the “three times is a pattern.” Once or twice isn’t enough to make sure you fixed the problem.

Reconfirm With the Client

This part is the most important step, particularly important for in-shop repairs. Showing the client it’s working isn’t enough to prevent a callback. You need to get the client involved and demonstrate to them it’s working. Before we started the 3R program, we had clients claim they didn’t remember seeing it working. If the client isn’t technically inclined, they won’t always understand what you’re showing them. That’s why you need them to experience it working. Let them open the program and see it isn’t crashing or that they have a clean browsing experience. You’ll do that after every restart and retest. Yes, the client will need to test it three times. They can always decline the retesting (we mark it in the file), but at least you gave them the opportunity. This testing makes them a partner in the repair.

Based on callbacks I tracked over an entire year, we found a few things we also need to reconfirm with the client. We get the most calls backs for these unrelated problems:

    1. Sending and receiving email
    2. Printing
    3. Using their preferred browser

We focus on those three issues because it fits with the 3R philosophy and just remembering three things. We’ll combine them a little by printing an email. If the client uses web-based email, we’re combining 1 and 3. These are essential functions to most clients: can they get on the web, get email, and print? We avoid having the technician do these things. We ask the client to do it. Again, this makes them a partner. When our techs forget to have the client do this, that’s when we get the call “It worked for him, but it isn’t working for me.”

When we have the client do the testing I also have a hidden agenda. We often work with non-technical clients and some of them are unsure of even performing these three basic functions. After discussions in the forum, I realized the importance of this quick test of gauging the client’s skill level. They may call back about printing or browsing because they don’t have enough practice or get confused easily. These clients might get a proactive callback. That call isn’t just to make sure things are working, but suggesting tutoring or other training.

Developing Your Own 3 Rs Checklist

This short mnemonic worked for my business but yours might be different. The first thing I suggest is reading The Checklist Manifesto by Atul Gawande. That’s what got me started on my journey to reduce callbacks. Gawande focuses on keeping checklists short and simple. All you need is to remember a few key things and the rest falls into place.

After reading the book, track your callbacks and the reasons why. I created a spreadsheet to track them and the patterns developed after just a few months. Pick the top three problems you see in your business. I continue to track these callbacks because I know this problem is a mix of my client base, the technology and my technical team. We use a simple Google form to track this but I’m eventually moving it to our new CRM system.

Your solution should always include involving the client in the process. If the client doesn’t see it fixed or working, you can’t be sure they know it’s fixed or working. They’re satisfied you got it all right the first time, and you’ll reduce non-billable time with the client.

Written by Dave Greenbaum

  • Mike Tanis says:

    This is a great post and a great idea. It helps build a professional relationship with the customer.

  • Charley Rouse says:

    This ! For a while I stuggled with the Metric that 15% of all Calls were for follow-up works, this is unpaid obviously and time dedicated to making other clients lives & technology better was wasted redoing/fixing same tasks.. Implemented a similar solution:

    We use a web-based invoicing solution ,
    1) raised Invoice online (Internet and browser);
    2) send invoice to clients email facility, (checks email, send copy of recieved email back to ourselves (!) confirms IMAP / POP & SMTP working)
    3) Print Invoice (Confirms Printer working)

    Request Payment : )

    We found that Browser, Email and Printer testing reduced callbacks to less than 3% over a year : )

    • I’m moving towards more of a web-based solution in my business too. How do you handle situations with equipment failure at the client location. For example, if you determine the problem is with the ISP and they can’t get online? Or what if the printer is broken? I’d like to be more web-based but I can’t see an easy way to handle invoicing and payment on-site that way.

      • JCFI says:

        Bring your cell phone with data connection and a USB cable, tether to their computer or use your own laptop tethered to your phone. You should always have some kind of data connection available to you.

        I’m not so sure about the security of using a customers computer to sign into any accounts that you hold, especially if you are dealing with a malware or virus infection, so send the invoice from your own laptop and phone connection but have them check it using their browser, email and printer.

        You could bring a portable printer too but that’s a bit of overkill, and you’ll likely have to come back to setup their new printer if the current one is broken.

  • This is great advice for all IT personnel. I plan on putting into practice in my day-to-day work.

  • >