This is more or less what I meant. As someone who has spent so much time on these systems, chances that you raise an issue that could have been resolved by reading the manuals are much less. Chances that you raise an issue without conducting preliminary checks to see if you have done anything wrong before raising that issue are even lesser. I personally think that anyone who has worked with the ARS for more than 4 or 5 years better know basic troubleshooting to eliminate obvious causes for problems he or she is facing. Such a person is a better candidate for having an almost on demand access for tier 2 support.
Some of the tickets I have created in the past, were based on genuine issues or problems that I have faced that are not documented. They were either bugs in the install script or where my install crashed out due to network errors and I had to redo application install so I needed information as to what I needed to delete from the Share Property form etc. If these installations are on UNIX system using readable scripts I even go through the exercise of viewing the script to see whats happening before I raise a ticket. A recent example is a bug I noticed on the installation of the approval server on Sun Solaris version 5.10, where there is a bug with the min version varaible that is read and interpreted by the install script. I called support after reading the script and spotting the bug just to verify the modification I intended to do on that script. How much will frontline support be able to help me with that if this bug has not been reported and documented before? They had to pass it to engineering to verify it for me.. Frontline support staff usually aren't able to give me the sort of support I need to resolve such issues. So they end up using almost as much time I might have possibly spent troubleshooting stuff myself, if not more in going through the same checks on logs etc before they ultimately reassign it to backend support when they reach at the same point I was at when I had decided to call support. Thats where I fail to see why I need to spend that much time with them when I personally know that in the end its very likely to go to backend support sooner or later.. Joe ----- Original Message ---- From: Axton <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, December 11, 2006 3:58:45 PM Subject: Re: BMC Support Doesn't ** "As an RSP I should be able to see more KB, enter KB's, update KB's and have a great deal more access to info on my incidents/bugs than the average customer. I have INVESTED a great deal of time to become "certified" in this stuff and that should mean that I am a good partner for BMC to work with. ( Not that I think I should be able to skip level one, but I should be granted more of what level one has than "just another customer" has too. )" Does this mean that those of us who have not gone down this path are somehow unworthy of additional content; tickets, kb, or otherwise? I too have invested a great deal of time in learning this stuff. Seems such a thing should be driven on individual merit (tickets vs. defects, etc.) instead of a piece of paper. Axton Grams On 12/11/06, Carey Matthew Black <[EMAIL PROTECTED]> wrote: Joe, I here you. I feel that frustration. However the most experienced developers do still make "newbie" mistakes from time to time. And wasting a "experts" time trying to figure out that you really did "leave the caps lock key on" is not good for anyone. (Even if it makes the customer on the other end of the phone feel like they are getting better support.) What I would like is a better "troubleshooting map" of what Level 1 will do when I contact them. That would allow me to complete more (or all) of the "level one steps" (and check them off the list) before I open the issue with BMC. If BMC could provide a "sure fire debugging process" that would let me "skip" level one contacts because they see that "all of those things are already done" would be GREAT in my book. I also fully expect my new incident to be routed through level one, where they verify that I did cross all my t's and dotted all of my "i's", but if it is all in order then they can focus on working with the level TWO and NOT working with ME to get details about what I see in my env. My bottom line would be: If they can not reproduce it, then either I have a local issue, or I did not fully describe it. (And level one needs to work with me to figure that out.) If they can reproduce it, and are unable to explain it, then I need to speak with level two. If they can not explain it, then the docs are lacking and level two has some explaining to do. And do NOT get me started on how RSP/RAC should be factored into this stuff. As an RSP I should be able to see more KB, enter KB's, update KB's and have a great deal more access to info on my incidents/bugs than the average customer. I have INVESTED a great deal of time to become "certified" in this stuff and that should mean that I am a good partner for BMC to work with. ( Not that I think I should be able to skip level one, but I should be granted more of what level one has than "just another customer" has too. ) However, there are days that I think that I am just certifiable for being certified in the first place. :) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On 12/11/06, Joe DeSouza <[EMAIL PROTECTED]> wrote: > ** > > <snip> > What I think would work is if they were to set up level based profiles of > their customers.. What I mean is usually when you have an experienced Remedy > developer or administrator calling Remedy support on some issue, they > usually call when they have covered most bases, and are still at a loss at > solving their problem. What they do not want to deal with after contacting > support is wasting about 6 hours shooting emails back and forth with basic > logs that were already looked at several times before raising some of these > issues.. > > An experienced developer or consultant would rather have liked to talk to a > back end support personnel rather than dealing with the front end. With all > due respect to newer developers or administrators of the Remedy systems, I > think it would be fair to have the backend support more accessible to > seasoned developers and administrators, while the front end support could be > more dedicated to newer or lesser experienced developers and administrators. > <snip> > > Joe D'Souza > Remedy Developer / Consultant, > BearingPoint, > Virginia. ____________________________________________________________________________________ Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
