Some comments in line ...
Some of your comments I don't agree with and some points are very valid. But in summary I think what you are saying is you want to see the results. These changes are things we are working on. We'll have to wait to see the results.
-----Original Message----- From: sirbruce@ix.netcom.com [mailto:sirbruce@ix.netcom.com] Sent: Monday, September 20, 1999 12:45 PM To: diptish.datta@netapp.com; armijo@cs.unm.edu Cc: toasters@mathworks.com Subject: RE: tech support waits Importance: High
On 09/19/99 21:35:17 you wrote:
Steve, I can see how the "proactive" response to a disk failure
autosupport would leave
you rather unimpressed when the call back is after you have
already acted on it
yourself! Fact of the matter is, that is indeed the way it
is today. Autosupport
is filtered by a script and the ones needing attention (eg
DISK_FAIL) are
forwarded to CSRs for attention. A call is logged and the
customer is contacted.
Now, the info in the autosupport is not very CS-friendly
because the info that
we need to locate the customer is not mandatory. So, often
it slows down the
process of logging the call, finding the contact information, etc.
In other words, Network Appliance implemented autosupport without committing to the staffing necessary to support all of the events generated. The solution then is either to ditch autosupport, or increase staffing. Productivity enhancements to the process (i.e. automation) are fine, but are not enough by themselves in the long term unless the fundamental issue is resolved.
############# I completely disagree. When autosupport was designed we thought of a lot of benefits we could get from it. Post processing the data to collect install base profile and such is one example. That is still valid. We also designed alerts that CS could trap and respond to proactively. We have a group of Customer Support Reps who are dedicated to processing autosupport alerts. We never claimed this to be a *substitute* for you being responsible for your filers. For example, when a drive fails, we designed the process to alert CS, log a call and RMA a drive. But if you receive the autosupport notification also (which is what we expect) then you will make sure that a spare was available and reconstruction completed.
As a company grows, its success challenges existing processes. That is what we are faced with today. The solution is not increased staffing - the solution is automation. That is the only way we will be able to scale. And that is what we are shooting for.
We are looking at correcting these bottleencks by proposing
changes to
Engineering that would make contact and customer information
mandatory in
autosupport.
So your solution is to shift more work off to the customer?
Shift work to the customer? Entering contact information in a setup screen is that much extra work? Ok ....
Not a good strategy. You should keep it optional so that customers can still get *some* benefit out of autosupport if they chose, even if it means Netapp won't be able to respond their quickest. A simple note in the documentation making it clear that the more information the better would be sufficient.
Agreed. We can't make it mandatory any way because of secure sites and such.
Furthermore, the customer information is not going to be kept up to date by many sites. IT professionals have too much to do as it is; one reason why *you* are paid for *support* is so that *you* do some of that work. It is not unreasonable for support to try to keep their records updated.
Paid or not, I'm not sure how we would keep our database info updated without input from the customers. The NOW site is one channel that allows you to tell us the info - I'm thinking autosupport may be another way for us to keep the info current.
We also have a team engaged right now to scope out automation around autosupport. If, for example, locating a customer
record in our database
was simple and guaranteed (programatically) then a script
could field the
DISK_FAIL autosupport, log a call, check the customer's
service level, issue the
RMA and email you back the call log number and the shipment
info. (Know anyone
that could help us with this project? :-).
This sort of automation should have been done years ago. Doing it now depends a lot on your choice of customer database and may require a new one if your old one was not properly planned. As to who can help you, you're in the heart of Silicon Valley... look out the window and wave some stock options around. Or consider offer existing personnel additional incentives to do the task. (Why do we have to tell you this?)
No - you really did not have to say any of that! :-) I'll pass on the idea of waving stock certificates out the window to the recruiters that are working full time trying to find people the hard way.
We are also thinking about automating the analysis of a
crash - I think we
should be able to suggest patches just based on info in
autosupport ... at least
some percent of the cases. Not sure how successful this will
be. But it would be
really cool even if we were able to auto-analyze and propose
upgrades for 25% of
the cases!
This is a good idea.
Thanks!!!
The wording will have to be careful to distinguish between "This looks like a known bug and we think this upgrade may fix the problem" and "We don't know specifically about this problem, but it may be fixed by going to the latest recommended version" and also catching those cases where the latter advice might actually be unwise. This can help in the response time but in many cases you will ultimately need some actual human intervention to follow-up.
Good points.
This should be possible. Autosupport has a lot of untapped
benefits that we can
take advantage of. It is not straightforward - but you
should see some changes
in the future - for the better.
Look, I know this message sounded harsh. No need to respond. But I recognize corporate PR song and dance when I see it and it pushes one of my hot buttons to see it on this list. Looking at resolving the problem? It's been around for a long time. Considering more automation? I bet you would have said the same thing 5 years ago. Explanations are fine, but excuses are just excuses. Customers want to see results.
Harsh? Naaah! Bruce, I appreciate your input. Honestly, 5 years ago (if we had autosupport 5 years ago - which we didn't) we though that the volume would be manageable. We were wrong. We did not have a problem dealing with the volume then. Now we do. Automation is now necessary.
Results are what matter. Proof is in the pudding and all that. Agreed. I am not in PR - I am in CS. So, this is important to us. I can not tell you what we will end up with - all I am saying is that the areas I mentioned are areas that we are working on.
Bruce
Diptish Datta Director, Product Support Network Appliance
-
Datta, Diptish