Re: Oracle Support Getting Worse?

From: Tim Gorman <tim.evdbt_at_gmail.com>
Date: Sun, 10 Mar 2019 18:54:39 -0400
Message-ID: <3dffed85-dcdd-bf8f-7075-1861f3333b6a_at_gmail.com>



Escalating an Oracle Support SR to "severity 1" means it will "follow the sun" from one Oracle global support center to another to be processed 24 hours continuously until resolved.  The SR will be in the hands of each global support center (i.e. North America, Australia, India, EMEA, etc) for about 6-8 hours each before it is handed to the next global support center.  For an operation as big as Oracle Support, processing so many Sev1 cases daily, there is no guarantee that an SR will come back to the same analyst in the same support center again.

This gives 6-8 hours for each analyst to be assigned by a manager, to come up to speed on the SR, research, think, and respond.  Each analyst is juggling a couple of these, and at times an SR will end up just floating for 6-8 hours without response and then be handed off with no changes.  Every 6-8 hours, it could be a completely new person, with no previous context, with only a narrow window of a few hours to do anything.  During that time, they could do everything up to the point of responding, but then run out of time.

In contrast, when an SR is at "Sev2", it stays with the same analyst for 8 hours out of every 24.  This person is also working several cases, but they only have to "come up to speed" on an SR once, not each day.  If an analyst gets to the point of contemplating a response, but runs out of shift, they just come back the next shift.

It sounds counter-intuitive, but if faster resolution is desired, I believe there is a better chance with Sev2 over Sev1.

It's kind of a weird "Oracle Support corollary" to mathematical "game theory";  if you push harder, you trigger behavior that actually makes it more difficult for something positive to be done, not unlike when a manager demands a status update every thirty minutes.  More time is devoted to the procedure than the process.

If it is a problem serious enough that it politically requires Sev1, then the customer's manager or director who provided their contact information to obtain the Sev1 status must work concurrently and actively alongside the technical person who opened the SR, constantly staying in touch with the Oracle Support escalation manager(s) to ensure that forward progress is made and obtaining status, preventing the SR being bounced from shift to shift like a beach ball at a rock concert, allowing the technical folks to focus.  Simply providing their contact information to get the Sev1 escalated, then sitting back and waiting for results, does not work.

My US$0.02...

On 3/10/19 17:58, Andrew Kerber wrote:
> Update.  They just transferred it for the fourth time.
>
> Sent from my iPad
>
> On Mar 10, 2019, at 12:09, bhavani d <bhavani021_at_gmail.com
> <mailto:bhavani021_at_gmail.com>> wrote:
>
>> We had a horrible support for one of the sev1 sr and it was crazy. 
>> No matter how many times we escalated the situation didn’t change
>> —-then we escalated to account manager and they are still working on
>> it. They put the sr in work in progress for couple of days and came
>> back asking for alert log which was uploaded on Day 1
>>
>> On Sun, Mar 10, 2019 at 1:05 PM Andrew Kerber
>> <andrew.kerber_at_gmail.com <mailto:andrew.kerber_at_gmail.com>> wrote:
>>
>> I believe Oracle support is going seriously down hill.
>> We opened a case (ODA patching)  yesterday around 1130. Sev 1,
>> production node down.
>>
>> After 3.5 hours, no response, we called and escalated.  They
>> transferred it to someone else, and he asked for more information.
>>
>> Their first suggestion of something to try was this AM at 403. 
>> About 15 hours after we opened the SR.
>>
>> I am thinking asking for a refund of our oracle support payments
>> would be appropriate.
>>
>> --
>> Andrew W. Kerber
>>
>> 'If at first you dont succeed, dont take up skydiving.'
>>
>> --
>>  Thanks,
>>   Bhavani Prasad.

--
http://www.freelists.org/webpage/oracle-l
Received on Sun Mar 10 2019 - 23:54:39 CET

Original text of this message