Since it is always difficult to predict how long it will take to fix a problem, the question for the PR people always is: Do you say as little as possible, hoping it will be over soon? The problem with this strategy is if your problem continues for a long time, you look incenitive or even incompetant. Do you confirm you have a problem, and provide customer updates? The problem with this strategy is you draw attention to minor issues, which few people would have noticed otherwise. After four days, Microsoft finally added a statement to their MSN Messenger web site. I guess Microsoft's PR people decided they couldn't make things worse at this point.
July 6, 2001/8:00 pm PST
MSN Messenger is currently experiencing a service outage for many customers on a worldwide basis. We wholeheartedly apologize for the inconvenience you may be experiencing. Our operations team is working diligently to restore full service (including restoration of all personal contact lists) as soon as possible. We are working around the clock to have MSN Messenger up ASAP. We expect to have the service restored by the end of the day today. Please continue to check back for updated status reports. Thank you for your patience.
The MSN Messenger
I admit the following view is highly subjective but everything is nowadays :) Personally I respect companies a lot more for more disclosure of problems. Small ISP's run by mainly techie's are very good at this (most of the time). If something goes wrong they like to let their customers know what went wrong and when they expect things to be back. I wouldn't expect a "Oops we accidentally pulled a cable out of the back of a modem in ourrack but everything's back now and we only disconnected one customer". I would however (in the case of MSNM) have prefered somethign to have been released at the latest one day after the incident (which is evidently a major issue with them) to say something like: "Oops, the cluster that hosts the MSNM softwarewas hit by a power outage and the UPS's unfortunately failed. This resulted in servers going tits-up and we're currently trying to recover all data. Sorry." (that's not what happened - I don't know what happened, just giving the above as an example). Yes, it's difficult to predict how long things will taketo fixand thus your process below fails. Instead why don't they class inicents by "Who is affected?" rather than "How long will it take to fix and who might notice?" On 6 Jul 2001, Sean Donelan wrote:
Since it is always difficult to predict how long it will take to fix a problem, the question for the PR people always is:
Do you say as little as possible, hoping it will be over soon?
The problem with this strategy is if your problem continues for a long time, you look incenitive or even incompetant.
Do you confirm you have a problem, and provide customer updates?
The problem with this strategy is you draw attention to minor issues, which few people would have noticed otherwise.
After four days, Microsoft finally added a statement to their MSN Messenger web site. I guess Microsoft's PR people decided they couldn't make things worse at this point.
July 6, 2001/8:00 pm PST
MSN Messenger is currently experiencing a service outage for many customers on a worldwide basis. We wholeheartedly apologize for the inconvenience you may be experiencing. Our operations team is working diligently to restore full service (including restoration of all personal contact lists) as soon as possible. We are working around the clock to have MSN Messenger up ASAP. We expect to have the service restored by the end of the day today. Please continue to check back for updated status reports. Thank you for your patience.
The MSN Messenger
Since it is always difficult to predict how long it will take to fix a problem, the question for the PR people always is:
[rest of setup snipped] I am of the opinion that degree of difficulty has nothing to do with the obligation to customer. We try very hard to tell all we know as early as possible. Sometimes that is in the form of "At hhmm TZ on month, day, year we are going to xxxxx. We expect this to take estimate, but experience teaches that you should plan on longerestimate." Sometimes it is in the form of "We have [noticed|been told] that xxxx has failed. Outages of this type usually take estimate because explanation of longer steps. We will provide updates here at the shorter of half-estimate and 2 hours." And once in a while it is in the form of "We have [noticed|been told] that xxxx has failed. At this time we have no idea what is going on--we will provide an update here as soon as we know something." These announcements are made to a mailing list (jaynet-alert@creighton.edu) and to a telephone recording (402 280-1116). Our experience teaches that telling all we know as early as possible reduces sharply the number of calls, and the number of escalations. Early on here I said "We try very hard to tell all we know as early as possible." Some of us are better at that than others of us. I am convinced that I can see the difference in customer response, but at the time of the incident and over time after it. The problem is now that sometimes everybody assumes we already know, and nobody calls us to tell us about something we didn't know. We have enough alarm mechanisms in place that that doesn't happen often, but it does happen. I would say "try it, you will like it", but it is one of those things that you have to make a long-term committment to because you have to teach your customers that they are getting the straight scoop. Depending on your past practices, that can be a long and painful process. -- -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- . . - L. F. (Larry) Sheldon, Jr. - . Unix Systems and Network Administration . - Creighton University Computer Center-Old Gym - . 2500 California Plaza . - Omaha, Nebraska, U.S.A. 68178 Two identifying characteristics - . lsheldon@creighton.edu of System Administrators: . - 402 280-2254 (work) Infallibility, and the ability to - . 402 681-4726 (cellular) learn from their mistakes. . - 402 332-4622 (residence) - . http://www.creighton.edu/~lsheldon Adapted from Stephen Pinker . -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
participants (3)
-
Av -
Larry Sheldon -
Sean Donelan