伺服器正常，落單仍會出錯：分銷商應量度的三項服務指標

先界定怎樣才算落單成功

設想一家已有訂貨 App 的分銷商，零售客戶每天在截單前補貨。畫面一直轉圈，客戶不知道有沒有落單，於是致電跟單員再試一次；另一張單雖然入了系統，卻把「箱」變成「件」。這是用來討論的假設情境，並非實際客戶事故。管理層要決定的是：儀表板能否指出哪些訂單仍未完成、哪些需要人工跟進。伺服器在線只能回答其中一小部分。

先寫清楚計算範圍，才談達標百分比。以下建議以已登入客戶提交、並通過既定業務驗證的購物籃為起點。同一次落單即使重按或因網絡重試，也沿用同一流程識別碼。示例把觀察上限定為三十秒：期間須有且只有一張已保存的訂單，App 亦要顯示相符的訂單編號，才算成功。這裏的確認只代表已收妥訂單，不代表已留貨或承諾送貨。超時後補救成功可另外記錄，但不應倒過來抹去原來的失敗。

三項指標，各有負責人

這份小型記分表是試行方案，並非已錄得的表現，也不是供應商保證。建議每天更新最近二十八天的數據，涵蓋全日，並以香港時間劃分日期。另外抽出公司真正繁忙的截單前時段檢視，避免非繁忙時間的好表現蓋過問題。由營運經理確認定義，再把表內職位換成實際姓名及候補人。每個百分比旁須列出分子、分母、資料覆蓋率與最後更新時間。

包括三秒及三十秒在內，全部門檻均為待商議的本地假設。正確率按訂單建立日期歸組；尚未到核對期限的訂單列為待核對，逾期仍未配對的訂單不得算作正確。

核對甚麼，必須由跟單與倉務一起決定，例如客戶帳戶、貨品編號、數量、計量單位、議定價格及要求送貨日期。比較時用客戶提交獲接納的快照，以及員工修改前的首份倉務紀錄；否則人手執漏會令系統看來比實際可靠。客戶其後改單應另作記錄。若暫時只能抽查，便列明抽樣數量及選取方法，不要把抽查正確率當成所有訂單的表現。

資料不齊，不能當作一切正常

用同一流程識別碼串連 App 提交事件、確認畫面事件與訂單紀錄。斷線時若可行，可先暫存事件，稍後補傳；未能對齊前，儀表板要顯示資料缺口。收不到確認事件，不等於已成功。測試帳戶及確實不符合業務規則的購物籃可排除，但須列出原因和數量；若是驗證服務故障，就不能藉「資料無效」把失敗排走。既然量度範圍涵蓋全日，計劃維護造成的影響亦須保留。

用假設數據試算：二十八天內有一千次合資格流程，資料完整，其中九百九十次成功，成功率就是 990 ÷ 1,000 × 100 = 99%，低於試行的 99.5% 目標。若只有九百四十次在三秒內顯示有效確認，確認速度達標比例便是 94%。即使成功個案本身很快，也不能忽略其餘客戶。這些數字只是算式示例，不是香港企業的實測結果。交易少時應同時列出失敗宗數；完全沒有合資格流程的期間，應顯示沒有數據，而非百分百成功。

內部目標與對客承諾要分清

Google 的服務水平目標章節把三件事分開：指標用來量度、目標訂出期望水平，而協議涉及達標或未達標的後果，並建議選取少量與用戶需要相關的指標。分銷商可用上述試行門檻安排內部改善優先次序。若要向客戶作服務承諾，便要另行談清楚量度範圍、報告方式及未達標時的處理。不要直接把儀表板數字抄進銷售承諾，也不要把主機供應商的在線承諾當成整個落單流程的保障。

預算有限，並不一定要先買新監察平台。只看基建狀態容易起步，卻不知道客戶有沒有落成單；客服工單有助了解經過，但未必記到沒有投訴就離開的客戶。定時測試單能在低流量時找出故障，不過要與真實交易分開呈現。可先利用現有事件匯出及共用記分表，收集繁忙與清淡時段的基準，再按客戶可接受的等待、執漏工作量及已安排的支援時段調整目標。

下星期便可開始的檢視安排

下一次工作會議，請跟單主管、支援主管及 App 負責人一起追查一張正常單、一宗逾時及一宗單位不符個案，先確認事件起訖和缺少的證據，再啟用儀表板。每週檢視記分表，但當天未完成的訂單應每天交到有人值守的支援渠道，不必等二十八天的比例跌穿目標才處理。重複問題須有具體改善工作與驗證日期；即使整體正確率達標，一宗已確認的數量錯誤仍要跟進。