Rick, I long for the day that BMC recognizes the amount of resources that we (the customer) devote to troubleshooting their product. When we identify a true BUG(flaw) then I really believe that they OWE us a discount on the next years support bill. Please do not misunderstand me. We call up and "complain" about all kinds of things that are not bugs. However, when we find a true problem, some behaviour that they can reproduce that is counter to the stated operational procedures of the product, then they at least FAILED TWICE (Dev and QA) and we expended resources to help them identify their DOUBLE failure. The customer that finds it first should get the discount. AND if Tech Support fails to identify the second, third, forth customer that also reports it [in a reasonable time frame, say.... three days], well, then they should get a partial discount too.
I also think that Alpha/Beta programs would be except from the discount program. (But the "most abused tester" of the program should earn some discount for their effort in the program.) Just to throw out a few numbers.... First customer to report the repeatable bug ==> 1% off next years support bill. Nth customer to report the same bug ==> 0.1% of next year support bill. Under such a model I see it as BMC's best interest to do all of the following: 1) Produce a product that matches the documentation. 2) Produce documentation that matches the product. ( Which is not exactly the same thing as the above. "Bugs" can be found in the docs too. AND "missing" information is a BUG too. :) 3) FIX bugs before other customers find them. :) 4) Not introduce new bugs to fix old bugs. And I think the above model also makes it in the CUSTOMERS best interest to: 1) Know the product design well enough to identify bugs 2) Know the BMC processes well enough to document and report inconsistencies in the products 3) Work with BMC to prioritize bugs that are found 4) Keep up to the current code line ASAP And please do not misunderstand me. Getting a BugID issued should not be an automatic discount. The Bug needs to be repeatable, and reviewed by Engineering to show a true error in the BMC product. A bug in the RDBMS/OS/Hardware/Network does not get you a BMC discount. A "bug' that is published by BMC first is a "free bug". No 1% discount here, but I do think that a customer that identifies it in their PRODUCTION environment should still be entitled to the 0.1% discount. And I think there should be a clause in this logic too that accounts for the release of a patch for a known bug too. If there exists a patch that actually resolves the issue (before the customer reported the issue) then the customer does not get a discount. BMC might have produced and released a flawed product, but they fixed it and it is available for the customer to adopt as soon as they can in their environment. And just to be 100% clear. Any bug found in any supported version of the product counts. So if your using the "current-1" or "current-2" version and you find a new bug, then you get that 1% discount the next year. (and BMC will be compelled to fix those bugs.) Oh.. and let us not leave the partners out of this conversation too. I think they would be in a similar position to the end customers too. (But maybe they get 0.5% for a "first bug". They are more likely to find bugs as they SHOULD be more technical than the average customer.) [And for those who do not know it... they have an annual "bill" to pay to maintain their partnership.] I would love to see a "no limit" to the discount (up to the total bill) per year, but the count can not be carried forward from year to year. So if you find 30 "first bugs" in a year then the next year is free. However you found 8 (ish, assuming a 22% support rate) bugs that you effectively get no "value" from too. So BMC could make out by working with their "more senior customers" in two ways. You get to give them deeper discounts, and you get to develop your product with a wider QA base than you could afford any other way. I can even see an opportunity for a "most abused partner" of the year title that could be used to highlight the partner that has most improved the quality of BMC products. And to be clear... RE:"only one thing to do": We have many other alternatives. There are dozes of competitors, and maybe a few good open sourced options too. BMC needs to keep customers, and maybe get a few new ones too. The way to do that is with CUSTOMER SERVICE. The fastest way to lose customers is to not meet their expectations. Thoughts? -- 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 2/19/07, Rick Cook <[EMAIL PROTECTED]> wrote:
Matt, I wonder if long-time Remedy pros have simply outgrown (to varying degrees) what Remedy can provide for us. I mean, until we get to engineering, only the Senior Support techs there generally know more about the product than we do, and why is that? They have access to information that those outside of the company don't. So that leads us to the next question: What do we do about that? I don't see BMC adjusting their support rates to allow for the fact that they can provide less actual support to some vs. others. I don't see levels of expertise dramatically increasing for the average tech, especially with all of the outsourcing going on. So that leaves only one thing to do - adjust our expectations, and only send things to support when we simply have no other recourse, or when we have reason to believe that the additional in-house knowledge base will be enough to resolve the issue. Thoughts? Rick
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
