3 ms·
i think you have to play it by ear. you certainly don't want to over-apologize or under-apologize. that hosting company apologized with the wrong apology. a goo
by drusenko 18y ago
i think you have to play it by ear. you certainly don't want to over-apologize or under-apologize. that hosting company apologized with the wrong apology. a good, sincere apology explaining what happened and why it's not going to happen again can go a long, long way to gaining devoted customers.
somewhere in marketing 101 we read this study that showed that customers of a company that makes a mistake and handles it well are actually more loyal than customers of a company that doesn't make any mistakes.
if that hosting company had made no apologies at all and ended up with a techcrunch article about their downtime, with "no comments" from the company, you bet they would be worse off than had they posted a quick status update and then made a sincere apology with extended analysis after a certain threshold had been met (say, 2 hours of downtime).
look at amazon and ec2 for an example of why silence isn't always the best option.
- palish 18y agoYeah, that's valid. It seems like we're talking about two different issues though. And you're completely right about having to play it by ear. This situation is unique because Davis is a founder of a company and his comment could possibly impact that company. It's not a case where the company has made a mistake in its service. In other words, if someone decides to not use Ticketstumbler over this, it's because they hated his comment, not because Ticketstumbler failed them. So in this scenario, there's no reason to draw attention to the initial act with a public apology because it's not likely to happen again. Whereas if Amazon EC2 went down, that would (by definition) have an impact on customers, and it might happen again in the future. So in that case, it would be valuable to reassure the customers that it won't happen again, to provide reasons why it won't, and to communicate the measures being taken to prevent downtime in the future. So the situations seem similar, but they're actually very different.