[j-nsp] Juniper support vs. Cisco TAC - experiences?

[David Ball]

  Another thing which I (and surely most of you) try to do is inundate
them with data when opening a case right at the get-go, in hopes of
avoiding the mundane questions Richard alluded to.  Not just a 'req
sup info', but attach any core files (/var/crash I think), many of the
log files found in /var/log/ (not just 'messages'), the 'traceoptions'
log for the problem/protocol/interface you're working on, a network
diagram, and a rediculously detailed explanation of precisely what
you're seeing, what else you've tried during troubleshooting, and what
those results were.  It will take much longer to open the ticket, but
in my experience it shaves days off the resolution time.  I've even
had a JTAC person reply with 'wow, thanks for all the great
information when opening the ticket...I'm escalating to ATAC now' when
they realized the issue was clearly out of their comfort zone.

David


2008/7/9 Richard A Steenbergen <ras at e-gerbil.net>:
> On Wed, Jul 09, 2008 at 10:56:22AM -0600, David Ball wrote:
>>   I agree with Stefan on the knowledge of the initial ticket handlers.
>>  I've had great support for the most part, but far too often the
>> ticket (and attachments) aren't read thoroughly, and as such I need to
>> explain myself several times.  Once that's done though, things seem to
>> go pretty well, especially if the ticket is escalated (which happens a
>> lot).
>
> There are two JTAC groups, regular JTAC and advanced JTAC. You can tell
> "regular" JTAC (which seems to really be "outsourced JTAC") by their
> e-mail addresses, which are always @jtac.juniper.net, vs advanced JTAC
> which has regular @juniper.net e-mails.
>
> In my experience, regular JTAC is poorly trained, not particularly
> familiar with Juniper products, has extremely poor reading comprehension
> (exactly as you described, I end up repeating myself or explaining things
> that have already been explained several times), and generally returns
> wrong answers about 90% of the time. Of course, I don't open cases that
> they have any hope of figurig out, so my experience is probably somewhat
> biased.
>
> I'm sure they serve some useful function (like blocking RTFM questions),
> but the real issue with regular JTAC isn't when they don't know an answer,
> it's when they don't KNOW they don't know an answer. If you don't insist
> on an escalation, they will HAPPILY sit on a case for months, popping up
> only often enough to ask completely irrelevent question which make the
> customer do a lot of legwork, returning completely wrong answers, and not
> escalating the case even when it is absurdly clear that it is beyond their
> experience and abilities. Once you get to advanced JTAC they have some
> excellent people who really know their stuff (and some less experienced
> people too), but having to go through regular JTAC adds days or weeks of
> frustrations for anyone who is a experienced network operator.
>
> I'm not sure if this is actually the case, but it seems to me that regular
> JTAC's performance metrics are based entirely on statistics like "how long
> did the case sit before they answered it and reset the ticket state to
> waiting for customer", rather than how helpful they were in resolving the
> problem correctly. They will respond to a case in seconds, but only to ask
> a completely irrelevent question which takes hours to gather the data and
> answer. As soon as you're done answering that question, they'll come up
> with a completely incorrect answer and if that does't make you go away
> they'll ask another irrelevent question. Anything to keep that ticket
> state set to "waiting for customer response", and to not escalate unless
> the customer asks.
>
> One other thing that I find interesting, I have NEVER received a JTAC
> survey for a case that had to be escalated (which is 99% of my cases). If
> I had, I would have been happily pointing out the many countless ways in
> which regular JTAC failed me before the case got escalated to somebody who
> knew what they were talking about. If anyone from Juniper is reading this,
> and wants to get this fixed, I'm sure your customers will happily give you
> a better understanding of the level of service we're seeing from regular
> JTAC if given the opportunity.
>
> --
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
>