In my last post, I discussed the need to have a “downtime plan”. Part of your downtime plan should include an Escalation Procedure.
As I mentioned in my previous post, I like to assign responsibility of key technology support components to an “Expert”, , , the person I want to empower to own that particular area of support. In the post, we identified e-mail as one of these areas.
Another key area is telecommunications or your Wide Area Network (WAN). When a remote office loses connectivity, your team needs to resolve this issue as quickly as possible, , , your company loses thousands of dollars in lost productivity every hour the remote office is down.
To minimize your downtime and the impact it has, you need an escalation procedure that kicks in as soon as we know an office loses connectivity.
Below is a sample Loss of Connectivity Escalation Procedure:
Problem ownership is clearly defined and specific communications to managers and vendors are spelled out. We have a point person in IT and also in the remote office that has lost connectivity. The point people identify themselves to their manager and make them aware of the problem and advise as to what the status update procedures will be.
In this escalation procedure, we have time limits set up so additional steps are put in motion at 30 minutes, 1 hour, 2 hours, and every hour after until the problem is resolved.
A big part of your escalation procedure is keeping management informed. When you have a formalized escalation procedure, everyone knows who will be providing status updates and when. Keeping your client in the loop and out of the dark is key.
It is simple and easy to develop an escalation procedure for dozens of support issues you might have and that will need some level of escalation if they occur. Here are the steps I would use:
1. Assign “Expert” responsibilities for the technical support areas you deem important.
2. Have your Experts identify possible situations that need an escalation procedure.
3. Review and agree on the set of issues needing escalation procedures.
4. Have your Experts develop a first cut draft of the troubleshooting and escalation steps that should take place.
5. Review the procedures and fine tune them with your Expert.
6. Create an Escalation Procedure Binder and add completed procedures as you develop them.
Your escalation procedures do not need to be lengthy or complex, , , in fact, your goal should be to keep them to 1-2 pages and simple.
If you focus on this and distribute the work to several Experts, you can create a binder of a dozen or more escalation procedures in a week. You may want to distribute them to affected managers of the company and communicate what they are and how to use them; I would certainly share them myself, but it is your call as to whether you want to.
The key is that you are providing managers with information so they know what will be taking place in the event of a problem, , , i.e., what you are doing to resolve the issue. IT still retains responsibility to resolve the problem.
Escalation procedures worth considering include:
- Loss of connectivity
- Natural disaster situations (snow day, flood, hurricane, etc.)
- Mission critical business applications
- Mission critical servers
- Internet and Intranet access
- Phone system outage
Putting escalation procedures in place demonstrates to others that you are organized and thinking proactively, , , strong images for your clients and senior managers to see in their IT organization.
ITLever™ 