Friday, March 30, 2012

SOP Friday: Third Party Tech Support - Rules of Engagement

From time to time, you need to call third party tech support. That means HP, Dell, Microsoft, Symantec, etc. It also includes line of business vendors, ISPs, and other folks who are hired by your clients.

You need to have policies regarding third party support for a number of reasons. First, you need to have consistent communications with outside parties. Second, you need to log all time appropriately. Third, you need to manage the vendor relationship. And, fourth, you need to protect the client systems.

As with so many policies, these come from a series of experiences in the "real world."

I'm going to write a separate (non-SOP) blog post on vendor competence. But for now, let's assume that most of the vendors you're working with are 1) Large, 2) Have good processes, and 3) Have competent technicians. Again, everyone has stories about bad support, but I'm amazed at how rare that is.

Today, our focus is on how to maximize performance and documentation when it comes to third party tech support.

You will generally have three types of vendor interactions. One is a direct relationship with your company. For example, you call tech support for equipment you own internally. A second is contacting a company on behalf of your client regarding a very standardized installation such as an operating system or backup software. And a third type involves a company that makes customized software tuned to your client's environment, such as a Line of Business application (LOB).

1. Internal to Your Company
For the "internal" vendor relationship, you need to keep track of contact information, account numbers, telephone numbers, and the standard information you need with any vendor. This information is best kept in your PSA system (Autotask or ConnectWise).

Your policy for direct vendor relationships should state very clearly who may contact the vendor, and who may authorize contact with the vendor. This is particularly important if you are paying for support, such as with an escalated tech support provider such as Third Tier or Dove Help Desk. If it costs you money to use the service, then there needs to be a clear chain of command about who can make the decision to engage, and how you will proceed.

All time spent dealing directly with vendors for you company must be logged as administrative time or internal support time. You need to track for payroll purposes, but you also need to be able to run reports and determine how many hours it takes to work with a given vendor in a year. If a vendor costs you a significant amount of time in a year, it might be worth looking for another vendor.

You need to have an escalation policy. For example, if the third party tech works for an hour without making forward progress, then you request escalation. This requires excellent notes on your part. Many companies, including Microsoft and Zenith, resist escalation at all costs. Hold firm to your policies.

2. Standard-Install Software or Operating System
For standard-install software at a client site, you just need to keep all the information within that client's section of your PSA. With these standard install kinds of software, you can expect to get a different technician every time. The vendor will generally NOT have any kind of account on the client's computer system. You will probably be working on a ticket when you decide to escalate for support.

In such cases, you have to decide whether to continue logging time on the current service ticket or create a new one. This is mostly a matter of personal preference, but it can be very handy to create a separate ticket for the escalated support if you think it will take a significant amount of time. It's sometimes hard to distinguish how much time was spent on the escalated part of a ticket. But if you have a separate ticket, it's easy.

Whenever working with a third-party support team, we prefer to do the work ourselves and not let them work directly on client machines. But sometimes it's their policy to work directly, or it just makes sense. When that happens, we allow them to shadow us. We do not let them have access to client systems when we are not monitoring what they do. Our preference is for them to tell us what to do and have us make the changes.

They know their software, but we know our client machines.
When working with these vendors, remember that you'll often start out with someone who knows less than you. Unfortunately, no one knows that until you've spent some time going over familiar ground. See the comments on documentation and honesty below. If the tech knows less than you, then they're wasting time. Escalate as soon as possible. If you know less than them, sit back and take excellent notes.

Tracking time is critical. There are generally two types of time that can be used here. One is "covered" by managed services and therefore you are losing money. The other is billable to the client as part of a project or hourly job. In one case, you need to know exactly how long it took to fix a problem. In the other case, you need to be able to bill the client for exactly how long it took to fix the problem.

Same escalation policy as above: You need to have an escalation policy. For example, if the third party tech works for an hour without making forward progress, then you request escalation. This requires excellent notes on your part.

3. Customized Software or Line of Business
Unfortunately, this is the area where we run into the least "professional" tech support. Sometimes the Line of Business vendors are very much like standard-install software vendors. But just as often, it's a 1-5 person company and there's only one person who can really fix anything. He might be using old programming languages, and he might not know anything about newer protocols or operating systems.

You need to determine very quickly whether you know more than this person. Be honest (see below). And defend your client's systems.

Unlike the other types of third-party support, the customized programmer or LOB vendor will probably have an actual logon to the client's system. Here's how we handle this.

a) The vendor account is not an administrator unless it is absolutely necessary. Server Operator is probably good enough.

b) The vendor account is disabled at all times when you are not logged in and shadowing them.

c) The client must sign a release stating that your company is in charge of managing vendors. This reduces friction and makes it clear that you are in charge of the server.

d) If possible, the vendor will shadow you and you will do the work. But realistically, they will be much faster with their product than you, so you will probably end up shadowing them.

e) The vendor must walk you through what they're doing. You need to be attentive and make sure they don't make changes that will break something else.

f) All access to the server must be scheduled. You agree (normally by email) when the account will be activated. You coordinate a time when you can both access the server, and you keep great notes about what occurred. Some LOB vendors will send you their amazing notes. Most don't keep any notes.

Escalation may or may not be an option. If you got to the one guy who can actually fix stuff, you may need to just hang in there until he figures it out.

Documentation is Critical
Next week I'll go into detail about Documenting Calls. But here are some key notes:
In all of these cases, YOU need to keep great notes about what you did. You need time stamps for all activities, in 15 minute increments. See the SOP post on Troubleshooting and Repair Logs

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.

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.

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!

Honesty is the Best Policy
When service companies reach a level of true professionalism, they adopt a policy of complete honesty in service calls. That means you admit if you or your client broke something. It doesn't mean you're incompetent. It means you're human. Expect the same from the vendor.

It's okay to say "I don't know about that." It's also okay to educate the vendor rep if you DO know something they don't. Be honest about what you did, the order in which you did it, and how you got where you are. Honesty is the fastest way to getting the system working again.
We all hate it when clients say "I didn't change anything," even when we can see that they installed a program. Don't be like that.

I've mentioned already, but let me say again: You always want to be working with someone who is more knowledgeable than you. That means you need to be honest about yourself. When you get to the limits of your knowledge, go into student mode and start soaking up new knowledge. When you get to the limits of the other technician's knowledge, ask to be escalated.

Again, excellent documentation is your friend.

Learn from Vendor Processes
Just as you have a service board, your vendors each have a service board. You need to document how you will contact them. For example, do you create a ticket online or by telephone? What information do they need?

One very common process that is used by tech support providers at all levels is to define the problem. You can't call a vendor and ask them to spend an hour poking around in your system and fine-tuning everything they find, unless you're paying them for it. No. In most cases, you have a specific problem. You called to fix that problem. They have a duty to define the problem, fix the problem, and close their service ticket.

If you also have another problem with the same software, expect it to be a separate service incident. In some cases, a tech will help you with both. But it is in everyone's interest to work on one problem at a time. So you are likely to have two different service tickets in their system.

Pay attention to processes like these and determine why they exist and how they serve you and the support company. Should you adopt similar policies? Very often, the answer is YES!

Implementing These Policies
Implementing these policies is a little different than other policies. You normally don't call a given tech support company very much. If you do, you might consider selling a different product! So you need to write up a policy that makes sense.

Only create as much policy as you need. When your staff need to escalate calls to outside vendors, go over these policies with them and use the incident to fine-tune your policies.

Especially with LOB vendors and customized software, you might have a specific policy for one vendor. Just make sure that there are clear notes about it in the system and that you have good communication internally, with the client, and with the vendor.

Always be updating documentation and processes.

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: Third Party Tech Support - Documenting Calls


Check Out Erick Simpson's Network Operations Center Operations Guide The Best NOC and Service Desk Operations Book Ever! by Erick Simpson Ships from stock right now!

No comments:

Post a Comment

Feedback Welcome

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

Disagreements welcome!