Escalation

Published 2003-03-31
Just ranting about escalation….
The objective of escalation is to bring something into higher priority and focus resources. In small business escalation is not usually an issue, there are usually only a few people to inform and everyone knows everybody. In enterprise class systems escalation becomes much more complex. Escalation is usually associated with problems but not necessarily(you can escalate good news). There are 2 sides… the escalator(person escalating a problem) and escalatee(person problem is being escalated to for investigation). 
When talking about problem escalation I find many enterprises lacking. Some have done wonderful jobs but most need work. Many shops have binders with contact lists, memos and hand written notes. Half the time is spent contacting the wrong people and often required contacts are never made. Other shops have rigid rules for escalation that often create excessive escalation. One shop I worked for used memos that would say something like…

If you have problems…
    Call 416-999-2222 Sun-Thu between 11pm-7am. No more than 4 rings!
    Call 705-555-1212 on the weekend
    Call 416-555-2244 at all other times.
I am unavailable Mon-Fri from 6-7pm, I will call you back after 7pm if paged.    

That was just the first level support contact, then you had to contact business and suppliers that each had their own escalation… And people were wondering why escalation took 90+ minutes at times.

Escalation needs clear guidelines – Rules are inherently inflexible and escalation requires extreme flexibility. Even if your internal escalation is rigid you have no control over external escalation.

Escalation Intervals – How long do you wait for support to call back? How long do you give first level support before escalating to second level? You need an escalation matrix that considers priority and impact. Example: Critical problems need faster escalation than others.

Does the problem need escalation? Some businesses escalate everything immediately. Although this may sound good it easily creates problems. An impact assessment should be completed before escalation is implemented. Perhaps the problem can wait to avoid costs like over-time. Others only escalate when everything crashes around them.

Once it is determined a problem should be escalated the escalation process should have structure to provide 1st, 2nd,3rd… level contacts for customer, internal support and suppliers but allow flexibility to “skip levels” as needed. Often internal support escalation is handled correctly but the ball is dropped when contacting customers and suppliers. How many times have you missed informing the right people? The escalation process must ensure ALL related contacts are informed.

Don’t call Jim “because he knows the solution”. Call the appropriate support and inform them that Jim has the solution. This ensures that bugs are worked out quickly… no one wants to be called at 3am. Another common problem for effective escalation. If you call Jim and bypass the escalation process the real issue of having the wrong contact never gets addressed. Next week(or day) Jim will get called again. Jim is probably not going to be very happy. Escalators must follow escalation as defined to ensure bugs in the process are addressed.

Escalation process should allow a flexible contact solution. Requiring specific contact types(like pager) are limiting and should be avoided. The contact person should have the ability to maintain how they are to be contacted(home,pager,cell…) but the process should not attempt to support memos like noted above.  Since contacts have the ability to maintain their contact details they assume the responsibility for the information.

Escalation requires constant reviewing to ensure the appropriate contacts are defined. Some companies think that once their escalation is defined they are done. Wrong! Escalation constantly needs fine tuning. I have seen many great systems fail because the data became outdated. A distributed ownership model is critical to a successful implementation. Contacts own their personal information, management owns the resources. Each is responsible to ensure their data is accurate.

Escalation requires ownership/responsibility. One of the most frequent problems I have seen is the lack of ownership when problems arise. A clear path to ownership must be maintained. Owners are responsible for the resource, they didn’t buy it! Ownership ensures at least someone is prioritizing the issue… they may not be the ones to do the work.

Escalation process must be accessible from various platforms(mainframe, PC, server, PDA…). No use having a great system that escalators can’t access. In addition it needs an API to integrate with standard business management tools like problem management.

I can go on and on about this subject… I think you get the idea so I will stop now.