Friday, April 06, 2012

SOP Friday: Third Party Tech Support - Documenting Calls

Last week we talked about calling third party tech support - the rules of engagement. We talked a bit about documentation. Today we'll cover documentation directly.

One of the key tools you need is the Troubleshooting and Repair Log. This is a paper log so you can keep it on your desk and add notes very easily as needed. At some point you might scan this into your PSA system (Autotask or ConnectWise), or transcribe some of the highlights. See the post just cited.

Documentation is Critical
There are several pieces to documenting an outbound tech support call. First, you need to get all the relevant information into your PSA system. This includes information on the vendor, their contact information, SR(x) numbers, service contract information, etc. You need all this in the PSA, within a specific ticket, so that all time can be logged to this ticket. Having everything in the PSA also allows you to have more than one technician on your staff work on the issue, and for you to put the project down and pick it up again.

Second, you need the paper TSR Log mentioned above. Please read that blog post! I can already hear people whining that everything should be electronic and not paper, blah, blah, blah. But it is just not practical to think that you will keep a service ticket open all the time, on a portable device, and keep that device in your hand at all times while working on this service call.

You need to be able to have instant random access to this document. This is true in large part because you have to coordinate with the other tech team. So you might need to add something to that document while you're between clients, at home, when the Internet is down, while the client's systems are offline, etc. Paper works anywhere, 100% of the time.

In a perfect world, everything is 100% electronic instantly. But many people are doing little or no documentation now, so the argument about waiting for an electronic option just doesn't float. Something is better than nothing.

Of course you will transfer some highlights from the TSR Log into the ticketing system when appropriate.

Third, you need to have some standard processes for describing how you deal with vendors. See last week's post. Also, you should have at least one ticket status specifically for vendors. Because there just aren't that many vendor calls, I would not create a whole series of statuses. One - "Waiting on Vendor" - should suffice. But you need to be very good about documenting WHY you're waiting.

Sometimes, with 3rd party support, you need to arrange a specific time when they can get into the client's system. You need to inform the client, arrange the time, and have one of your technicians available for the call.

Because you'll be shadowing the vendor (or they'll be shadowing you) most of the time, coordinating multiple connections can be hassle. Keep good notes and make sure time gets allocated to the right service ticket.

If you do this consistently, you'll be able to figure out how much time you spent on each vendor at the end of the year. For example, if all calls to Symantec go into service requests specific to their products, then you can just add up the hours.

Working with vendors can be very time-consuming. There is often a long wind-up to getting funnelled to someone who can actually help. You need to coordinate access to machines. If they end up sending a part for you to install - or a tech to install it - there's more coordination. Then, in the middle of your support cycle, someone needs a day off. Or you need to wait three days to see if the fix worked. It can be very time-consuming, and you need to document everything.

Reproducible Success

One of the most powerful elements of documenting your calls with tech support is the ability to get a free education! Once you are involved in solving an issue, you may very well be able to fix it by yourself next time. The odds of success go way up when you take excellent notes.

In all of the sample cases discussed last time, YOU need to keep great notes about what you did. You need time stamps for all activities, in 15 minute increments.

It can save a lot of time if you can tell the escalated support what you've already done. This includes backtracking your steps (for example, when you change an IP, test something, change the IP back to what it was). Tell them everything.

If you can email your notes to the tech, that sometimes helps tremendously.  Keeping excellent notes will help you escalate to the right level of support as quickly as possible. You always want to be working with someone who is more knowledgeable than you.

When the third party takes over, you also need to keep notes on everything they do. Very often, these people write up their notes after the fact. In other words, they don't document in real time. That means you will be relying on their perfect recall, which they won't have.
You need to log emails and get them into the ticket notes.

If the "fix" is related to a product that you have installed on more than one client, you need to make sure that notes get into the knowledgebase you keep for that product. If you're not doing this in your PSA system, learn how and do it!

No matter which third party vendor you're dealing with, ask for their notes and put them into your service ticket or knowledgebase. This is critical for documenting what you did and might help with future problems.

There's one very frustrating category of problems you can't solve yourself: Secret patches. Nothing is more irritating than to have someone on a paid support call say "We only distribute this patch to people who ask for it." What? So after an hour of scouring your online database, you tell me I would never have found this without calling you? Grrrrr.

But even with this, you can download the patch, document how you used it, and have it available as needed.

As I mentioned, you probably don't have THAT many 3rd party support calls. If you have a high number for one product, you should consider alternative products! But because you don't have a lot, you'll need to have good processes in place so that you can deal with them as successfully and consistently as possible.

Your Comments Welcome.

- - - - -

About this Series

SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.

Find out more about the series, and view the complete "table of contents" for SOP Friday at

- - - - -

Next week's topic: Setting Up a New Managed Service Client (Checklist)


Check Out the #1 ranked Managed Services book at Amazon: Managed Services in A Month by Karl W. Palachuk Buy it as a printed book, Audio book, or ebook!

No comments:

Post a Comment

Feedback Welcome

Please note, however, that spam will be deleted, as will abusive posts.

Disagreements welcome!