SendGrid 的 Processed、Deferred 與 Delivered 描述不同階段，不能全部翻成顧客已收到。先找同一位收件者、同一筆訊息的事件時間線，再看原因與最終結果；若顧客仍找不到信，Delivered 之後還需要收件端位置證據。
別用整批活動的總數查單一顧客
同一封活動可能對不同地址有不同狀態；只看活動面板的總接受數，無法回答某張訂單通知發生什麼。請以可用的訊息識別碼、收件者及時間縮小範圍。若團隊使用事件接收機制，應由既有管理者查資料，不需要為本次排查新建整套整合。
- 記錄應用程式交付的時間與 SendGrid 的訊息識別，確認問題不是尚未呼叫寄件服務。
- 取得相關事件，分清已處理、暫時延後、遠端接受及最終拒收；保留原因文字，不只存顏色。
- 若有 Deferred，檢查後續重試與最終狀態，按目前官方規則及帳號資訊判斷，不另行連按重送。
- 若顯示 Delivered，請收件者搜尋原信；只有拿到該封信才能進一步比對資料夾與驗證結果。
假設案例：前後兩個事件不矛盾
假設臺灣票券服務先看到某收件者 Deferred，稍後同一事件變成 Delivered。前者代表當時未完成，後者代表後續遠端接受，兩筆可以同時成立。這個假設不表示信件第一次就進垃圾郵件，也不能從後來接受推論使用者已讀。
如果店員另外按了重新寄送，系統可能建立新事件。排查時要將新舊識別碼分開，不要拿新信的成功填回舊事件。顧客若收到多封，還需協助分辨版本與操作時效，避免重複付款或誤用已失效的通知連結。
遠端接受之後可以查什麼
請持有人在網頁信箱確認原始位置、個人規則與垃圾郵件；企業地址則可能需要管理者查隔離。沒有拿到原信時，不應宣稱分類正常。開信與點擊事件也不必然等於真人閱讀，追蹤受到用戶端與自動處理影響，不適合拿來替代收件端查找。
若 Deferred 原因指向暫時性驗證、來源或流量問題，將完整回應交給 SendGrid 或管理者，不要立刻停用驗證或換來源規避限制。共享來源的狀況尤其需要平台資訊，單一店家通常看不到整體佇列與其他租戶情況。
本篇不固定承諾任何重試時長與保留期限，因平台文件及帳號可見範圍可能更新；請以當前官方說明為準。若資料已超過你能查的期間，記為未取得，不要從最新一次測試猜測過去事件。原始時間線是比對的基礎。
對外回覆可使用精確說法：平台已處理、曾延後、遠端已接受、收件位置待確認。這比一句已送達更能讓客服和技術人員各自接手。外部樣本工具只能補一組觀察，不能代替 SendGrid 原始事件，也不表示已支援任何臺灣本地收件服務。
資料依據與後續觀察
請同時保留原始狀態與內部中文說明，避免不同部門翻譯成不同意思。若平台事件尚未完整顯示，先註記資料待補，不用人工猜測後續成功，也不將另一位收件者的事件代填。
完成上述檢查後，可用去除個資的同版內容開始郵件測試；先確認當下可選的收件服務，結果僅描述本次樣本，不能推估所有臺灣顧客。測試方法與限制說明觀察範圍；工具不會代查商店後台或收件者私人設定。