Escalations vs. Severity Increases

The Customer Support Management team travels the country speaking at UserGroups, Conferences, onsite and online with customers. The Support topic of greatest misunderstanding is that of Escalation.

My objective is to bring this subject into greater awareness.

First, Escalations are NOT Severity Increases.  Allow me to expand that statement.  Severity is a definition of business impact.

Severity 1 = down production environment or mission critical application that is severely impacted.
Severity 2's, 3's and 4's are lesser degrees of business impact.
Customers tend to artificially increase severity as opposed to escalation.
There are distinct differences between the two.

Second, Escalations are defined as Bringing Management Attention to your Service Request.  This is very important.  Oracle Support and the management team take a lot of pride in the fact that we are accountable to our customers and made accessible to them.

Third, Escalations are a positive experience.  Nobody is getting in trouble. The engineer who owns your issue is not getting punished, nor is the customer's organization being singled out.  Escalations exist to place our customers in a direct, two-way dialogue with the Manager for the team that owns your issue.  That dialogue has 1 goal - to get your issue back on track and closer to resolution.

Customers can escalate any Service Request, for any Severity, at any time.
The process for Escalation is very simple.

  1. Initiate escalation by calling the respective 800# for your Product Support Team
    1. Feel free to update your SR/Case by documenting that you've requested escalation, however do not initiate escalation via electronic means.
    2. Do not Escalate by calling your account/sales team - common mistake.
  2. Provide the Support Engineer who answers your call your existing Service Request/Case number and request "to speak to the Escalation Manager"
    1. Do not ask for an update in the SR/Case - this is the #1 mistake.
    2. Do not ask for an increase in Severity/Priority - this is the #2 mistake.
  3. The Manager will be identified and notified and will contact you back - typically in less than 30 minutes.
  4. During that discussion, express your concerns, develop an agreeable action plan and commit to open communication with that manager on an ongoing basis.
There are more best practices to Escalation than just those 4 parts I've included here.  My objective is to be clear and concise on this subject. 
For more details on Escalation, including RE-escalation to senior levels of Support Management, please use these links.
Oracle Support's objective is customer service and satisfaction.  Escalation exists to provide a Superior Ownership Experience to our customers.  Oracle Support is an award winning Support organization because we have an effective escalation process.

Comments are welcome.  Have a great day/week.
Chris Warticki
Sr. Customer Support Manager

The CSM team can provide your organization free training on this topic and many more subjects.
Please contact us at to arrange a session for your company.


Chris, another 'common mistake' is to escalate an issue immediately (or shortly) after creating it. Although you write a SR can be escalated any time, I would never recommend escalating within the first two days after SR creation, or when there is NO lack of progress in the SR.

Posted by Bit on July 18, 2007 at 06:14 PM EDT #

Absolutely.  I agree.  I would never recommend, nor encourage Escalating an SR/Case shortly after its creation.  Give Oracle Support a chance to review it, research it and troubleshoot it.   If Support is actively engaged and is working diligently on the issue, escalation is not necessary.

Finally, Escalation doesn't have to be viewed upon as only when dissatisfaction arises.  Use Escalation to let the manager know what a great job your engineer is doing and that you want to recognize them for their efforts!

Posted by Chris Warticki on July 19, 2007 at 12:55 AM EDT #

In response to Fadi's reply, I would not recommend asking the engineer to have an SR/Case reassigned to another engineer. 
Reassignment of issues should only be done with management involvement.  Use the escalation process to open that dialogue with the support manager and ask the manager if reassigning the issue can be done.  Most often it will.

Posted by Chris Warticki on July 19, 2007 at 12:58 AM EDT #

Thank you for your feedback.  I'm happy to know that you have observed improvements from Support in your career working with Oracle products.

Synchronization is key! (soon to be another blog post)

Allow me to re-clarify from experience as an Escalation/Duty Manager:
We have many engineers scattered throughout the globe, staffed to capacity for incoming volume.  Just because the engineer is in Country-X doesn't mean that they necessarily work those business hours only.  I've managed a global team of over 35 engineers all staffed for US business hours. Customers escalated to me all the time requesting it to be moved to a closer timezone, when in fact the engineer was working 3rd shift in their geography to cover US capacity.

Also, requesting within the SR that your engineer be in your timezone is not recommended.  Our engineers cannot reassign their own work.  (nothing would get done).  Also, just because a customer is in timezone 'A' doesn't mean they don't work 2nd or 3rd shift for their own company.   So, timezone alignment isn't always the solution.

What I do recommend is is to escalate the Service Request, using the escalation process as defined.
Just because you escalate an SR, doesn't mean it will be worked in your timezone.  Support may not have anyone in EST, therefore the Escalation Manager and customer will discuss at that time.  AND - this request shouldn't be made in the Service Request itself, only through the Escalation Process, during your discussion with the manager over the telephone. 

Posted by Chris Warticki on June 04, 2008 at 01:14 AM EDT #

Post a Comment:
Comments are closed for this entry.

Chris Warticki
Support Specialist, Presenter Extraordinaire, Toastmaster & self-proclaimed Support "spokesmodel".

Chris has been working for Oracle for over 16 years. Chris educates customers how to maximize their Support investment and leverage the support tools and available resources as part of Premier Support.

Chris works for Global Customer Management and speaks with customers on all topics regarding Oracle support services


« March 2015