12th May 2011
Sarah Lafferty was left crestfallen after reading Amazon's apology for its Easter outages. So she suggests how Amazon's apology should have read.
Given that the main obstacles to cloud adoption by naturally sceptical people in areas like financial services and the public sector are security and trust, I was crestfallen after reading Amazon’s apology to its customers following the Easter outages. Amazon is the industry’s ‘flagship’ cloud vendor and is therefore responsible for leading the way in communicating cloud and building trust in the wider community.
I don’t doubt for a second Amazon’s good intentions in publishing the apology, but the letter was cack-handed and only further raised the hackles of the vast majority of its customers while setting back the progress of cloud adoption generally. Next time Amazon, I beg you to listen to your communications people when it comes to apology-writing and let your engineers get on with the engineering.
As a public service to the cloud community, I would like to offer my version of how the Amazon apology might have read, followed by some explanatory notes:
Last week we experienced some technical problems that resulted in some of our customers losing access to their files. If you were affected, we are very sorry for the disruption in service and the distress and inconvenience this caused. Please be assured that we have learned from it and are making several changes to our services and processes to ensure we don't make the same mistake again.
The outage happened while we were in the process of upgrading the network in order to provide you with more capacity and better service. During any network upgrade, we need to temporarily move all network traffic to another network while we carry out the work. This normally passes without incident. Unfortunately, this time we made an error and moved all the network traffic to a network which had less capacity than the one we were upgrading. This caused a malfunction and the unfortunate result was that customers lost access to their files.
When we realised our mistake, our main priority was to bring more storage capacity on-line. Without going into complex technical details, the task of restoring these files to another location was complicated and delayed by some advanced security measures we implemented, ironically, in order to safeguard customers’ data.
We are pleased to report that all customer data has now been successfully and safely restored. We have learned some important lessons about large-scale data recovery from this incident and we are very confident that it will not be repeated. Furthermore, the next time this happens we promise to communicate better and more regularly you.
Should you require a more detailed technical explanation of what happened, please visit our technical website on xxx. Please feel free to contact me or a member of my team directly on the e-mail below if you have any further concerns.
Amazon customer service guy, e-mail address
- The apology itself must come at the beginning, not the end of the letter!
- The apology should be short, pithy and timely, respecting people’s time and knowledge levels. The original 5,694 word letter was agonisingly long-winded. No doubt crafting this lengthy response meant that Amazon didn’t communicate fast enough, fuelling panic and speculation.
- Eliminate all the technical jargon and just explain what happened in layman’s terms. Why should a customer have to spend half a day on Wikipedia trying to make sense of an apology letter? Provide a link to the technical stuff for the minority who need to know.
- This incident did not happen to Amazon, it was Amazon’s fault. Therefore the apology should be personal, written in the active voice and in the first person. This shows that Amazon is holding itself accountable and responsible. Put name and contact information on the letter to reinforce this.
- Make some tangible commitments and promises that the incident will not be repeated.
Mistakes happen in every company, especially the most innovative and daring ones. But it’s how companies learn from and handle those mistakes that ultimately determine their fates.
Sarah Lafferty is a co-founder and director at Round Earth Consulting, a communications consultancy for the enterprise software industry. Sarah is passionate about understanding the human side of cloud adoption and usage.