最近，我從供應商和我自己的應用程式中獲得了許多應用程式停機的經驗。這讓我思考，盡我所能谷歌搜索，在停機事件期間管理客戶溝通並沒有真正好的或標準的方法。
我已經看過很多處理這個問題的方法“責怪所有人，除了我們”的方法“我們搞砸了，我們很抱歉”方法。
所以我的問題是......當你搞砸了一個應用程式並導致停機時：
- 你立即承認錯誤嗎？ （從法律上講，你應該這麼做嗎？）
- 您向客戶提供了多少有關問題所在的資訊？ （「一個問題」與「我們的一個 SQL 查詢中的程式碼語法錯誤」）
- 你會帶著後續的預防計畫回來，還是只是停留在「這已經解決了」？
- 你們提供即時更新嗎？多常？透過 Twitter 或面向公眾的網站？
您發現其他成功的最佳實踐嗎？
答案1
這是我所做的：
- 非常清楚地說明什麼結果是（現在和不久的將來）。強調可能的永久性後果或缺乏（資料遺失、員工工時損失）。
- 保持語氣非常中立。不要把精力花在責備/內疚上。理想情況下，這傳達了「我想向您提供訊息，但其他地方也需要我的注意力」。
- 您的通知將轉發給許多人，請確保您的執行長理解前半段的要點。通常我會提供“執行摘要”。技術細節可以為其他技術人員提供背景資訊。
- 提供詳細的聯絡方式（最好是在停機期間有時間的人）以供進一步詢問，並用同一句話請求耐心（這通常很有效）。
- 當情況改變時承諾更新。
當有好消息時，在辦公室關閉時間之前發送更新（「所有員工將繼續整夜」 - 如有必要，請考慮時區）並在辦公室開放時間前後再次發送。
問題解決後（對於該詞的任何定義），發送：
- 包括後果發生時間的摘要
- 短期採取的和未來計劃的行動/改變（“經驗教訓”）；基於：
- 技術根本原因分析
將任何指責、內疚或私刑的呼籲放在單獨的郵件中，最好是在一段冷卻時間之後。
在停機期間不要承諾任何事情，除非你真的非常確定你可以交付。不知何故，兩個單獨的「壞消息」情況比一個長的情況更糟。
我更喜歡使用在每個訊息上推播通知的媒介（郵件、Twitter，..）
答案2
我發現，作為服務提供者和服務使用者，最重要的是主動承擔責任。重要的不是你說了什麼，而是你什麼時候（多久）說的話。
如果您收到問題發生並已修復（或正在處理）的通知，這比您自己發現問題並嘗試聯繫供應商以了解到底發生了什麼要好得多。它還有助於解決相互指責的問題，並節省大量故障排除時間（是我們還是他們？）。
就細節而言，我發現對所發生的事情進行簡單的總結是很好的，除非用戶特別要求更多資訊。有些人總是想要盡可能多的細節，但大多數人只是希望事情能正常運作（即使它們技術性很強）。
最後，能夠解釋你採取了哪些措施來避免這種情況再次發生，對未來的善意和信任大有幫助。
答案3
不了解有關您的特定應用程式、其許可方式、您提供服務的領域等的更多資訊；不猜測就不可能回答你的問題。
- 承認自己的錯誤通常是一條路。如果您所在的領域適用許多法律、SLA 或詳細合同，請諮詢您的律師。
- 太多細節和太少細節之間只有一線之隔。一般來說，夠詳細，一般使用者會覺得他們理解。
- 如果這是一個小錯誤並且很快就能改正；不要糾纏它。如果這是一個非常大的失誤，你就需要進行損害控制。
- 小錯誤，當發生故障和修復時通知。大錯誤，當達到解決方案的任何里程碑時發出通知。
我希望我的供應商提供太多有關停機的資訊。但許多企業就是做不到，或是被律師拉上拉鍊。如果您有任何疑問，請諮詢您的律師/保險公司。