Re: Oracle Support Getting Worse?

From: John Thomas <jt2354_at_gmail.com>
Date: Mon, 11 Mar 2019 22:49:07 +0000
Message-ID: <CAOHpfbE9o_w2kwvKQBb3o7GQMFwC4LdfM6aHvkq8tffVGrvGfw_at_mail.gmail.com>



Tim,

It makes perfect sense from a customer point of view, but Oracle have not demonstrated that as a high priority.

It does not seem like rocket science to you an me, but Oracle have had about a quarter of a century to figure this out, and so far have not done so.

About a decade ago I remember raising a Sev 1 before there was an option to downgrade it to 8x7. I raised it the Friday before Australia Day, and had to phone them on the Monday to ask why there had been no progress on a problem critical to my customer... The Aussie support office were experts on the subject matter and it had been transferred to them on the Friday night.

Since then, some responses have got worse, instead of better.

Regards

John T

On Mon, 11 Mar 2019, 14:53 Tim Gorman, <tim.evdbt_at_gmail.com> wrote:

> My point is how the Sev1 mechanism is designed to last indefinitely with
> no single person responsible, resulting in less accountability than the
> normal mechanism.
>
> To fix this, the customer executive who authorizes the Sev1 escalation
> must become an equal partner on the SR, with equal responsibility for
> resolution, working the escalation 24x7 alongside the technical person.
> This executive must be working directly with an Oracle support manager or
> director, holding them responsible for progress. There is no roadmap or
> formal process for this, the executive must earn their pay to figure out
> how this is done. Now the technical people are freed up to focus on
> working the problem. Customer executives are obtaining status directly
> from Oracle Support, so there is less need to pester the technical folks so
> frequently.
>
> Hope that makes sense?
>
>
>
> On 3/11/19 09:54, Chris Taylor wrote:
>
> Tim,
>
> Wouldn't the Sev2 engineer that gets assigned also be dealing with Sev1
> tickets as well? (Potentially?)
>
> Chris
>
>
> On Sun, Mar 10, 2019 at 5:55 PM Tim Gorman <tim.evdbt_at_gmail.com> wrote:
>
>> 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> 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>
>> 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 Mon Mar 11 2019 - 23:49:07 CET

Original text of this message