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.
- Initiate escalation by calling the respective 800# for your Product Support Team
- Feel free to update your SR/Case by documenting that you've requested escalation, however do not initiate escalation via electronic means.
- Do not Escalate by calling your account/sales team - common mistake.
- Provide the Support Engineer who answers your call your existing Service Request/Case number and request "to speak to the Escalation Manager"
- Do not ask for an update in the SR/Case - this is the #1 mistake.
- Do not ask for an increase in Severity/Priority - this is the #2 mistake.
- The Manager will be identified and notified and will contact you back - typically in less than 30 minutes.
- During that discussion, express your concerns, develop an agreeable action plan and commit to open communication with that manager on an ongoing basis.
For more details on Escalation, including RE-escalation to senior levels of Support Management, please use these links.
- MetaLink - Note 364290.1
- Customer Connection - Solution ID 201007520
- Siebel Customer Support - MetaLinkv3
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 support-training_us@oracle.com to arrange a session for your company.
Comments (4)
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 | July 19, 2007 1:14 AM
Posted on July 19, 2007 01:14
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 | July 19, 2007 7:55 AM
Posted on July 19, 2007 07:55
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 | July 19, 2007 7:58 AM
Posted on July 19, 2007 07:58
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 | June 4, 2008 8:14 AM
Posted on June 4, 2008 08:14