寄件紀錄與顧客說的時間對不上，先確認各畫面的時區，再比較事件。訂單建立、平台處理、遠端接受和讀者開啟不是同一時刻；若把 UTC 與臺灣時間直接相減，可能製造出不存在的延遲，或把真正的等候時間藏起來。
先保留原顯示，再做換算
不要直接覆蓋原始時間欄位。建立兩欄分別記原值與統一時間，連同時區及資料來源保存。若某畫面沒有標示時區，向平台查明；不能只因帳號持有人住臺灣，就推定所有後台也顯示臺灣時間。手機和電腦系統設定也可能不同。
- 收集同一事件的訂單觸發時間、應用程式送出時間、平台事件與收件原信，保留對應識別碼。
- 記錄每個時間值的來源和時區，有明確偏移才換算；對未明欄位標註待確認。
- 按統一基準排序，分開計算等待觸發、平台處理與傳輸，避免把收件者晚開信當成寄件延遲。
- 若事件來自不同副本或重寄，先拆成不同列，不用同主旨強行配成一條路徑。
假設案例：晚上看到早上的紀錄
假設臺灣活動團隊看到平台時間標為 02:00，店員操作紀錄是同日 10:00，兩者可能只是顯示基準不同。這個假設要先確認時區，不能立即判定平台提早寄出。若換算後仍有差距，再追哪一段等待，而不是用猜測修訂報表。
原信的 Date 是訊息中的一個欄位，不能單獨替整段傳輸時間作證。管理者可參考可信傳遞節點與平台事件，但中間節點也有各自時間與信任範圍。原始檔保留完整結構，比只複製一個看起來最方便的時間可靠。
客服要如何詢問顧客
請顧客提供看到問題的大約時間與使用介面，不必要求他理解 SMTP。若對方願意提供原信，提醒它含個資，使用可信支援管道；公開範例可改成示範值。客服內部把觀察轉成統一時間，回覆時仍使用顧客容易理解的當地時間。
若通知有時效，例如取貨或活動報到，先依既有授權方式協助確認業務資訊，但不要在沒有事件證據時承諾郵件準時送達。應清楚分開「資訊已補充」「原信何時被接受」與「讀者何時找到」，避免時間線混淆。
夏令時間、跨國訂單與伺服器設定可能增加複雜度；本文不提供所有地區的時區表，也不假設每個平台以相同方式儲存日期。需要精確計算時，保留原始偏移或由管理者確認，避免只靠地名猜測。
完成後保存轉換規則與資料來源，讓另一位同事能重現。若只有分鐘精度，不能宣稱精確到秒的延遲；如果只記讀者截圖時間，也不能拿來證明遠端接受時刻。精度和未知範圍應跟結果一起呈現。
外部樣本測試另有自己的開始與觀察時間，不應自動與舊通知合併。使用相同版本重測時仍需新識別碼。這項流程能修正比較方式，但不提供收件匣保證，也不會替商店後台補回已不存在的歷史紀錄。
資料依據與後續觀察
完成上述檢查後，可用去除個資的同版內容開始郵件測試；先確認當下可選的收件服務，結果僅描述本次樣本，不能推估所有臺灣顧客。測試方法與限制說明觀察範圍；工具不會代查商店後台或收件者私人設定。