有些錯誤很輕，重新整理就好；有些錯誤牽涉到錢，系統說的每一句話都必須更負責。最危險的不是外部動作失敗，而是網站內部已經先把它當成成功。
兩個系統，不能各自宣布結果
付款或退款通常同時存在兩個世界：網站裡有一筆紀錄，外部服務也有一個真實狀態。如果網站先把數字改了，外部服務最後卻拒絕，團隊看到的就會是一個看似完成、實際沒有發生的動作。
這類問題讓我重新理解成功的順序。不是按下按鈕就成功，也不是本機多了一筆資料就成功；要等真正負責交易的地方確認之後，網站才有資格往下走。
好的失敗處理，不只是阻止錯的事情發生，還要讓下一個接手的人知道剛才發生了什麼。
錯誤訊息是營運流程的一部分
一句「發生錯誤」對程式也許足夠，對隔天要處理帳務的人卻幾乎沒有幫助。是暫時不能做、條件不符合，還是需要人工確認？不同原因會導向完全不同的後續。
所以錯誤需要被翻譯，也需要留在正確的工作紀錄裡。不是把內部細節全部倒給使用者，而是留下足以判斷下一步的原因。
保護不是多一個確認視窗
真正的保護不是再問一次「確定嗎」，而是即使有人操作、網路中斷或外部拒絕，系統都不會製造一個假的結果。必要時寧可停住，也不要自信地往前。
高風險流程的失敗，也要被當成產品的一部分設計。這通常比再加一個成功畫面，更能替營運現場省下成本。