網店送貨設定實務：香港地址、運費規則與自取安排怎樣測試

網店送貨設定測試集：同一購物籃為何出現兩種運費

網店送貨設定最容易在例外情況出錯：客人加入兩件商品，送往同一個香港地址，卻因為一件商品不可自取、另一件商品超過重量門檻，結帳頁顯示了兩種互相矛盾的送貨選項。假設一間觀塘的小型貿易公司正在開網店，職員用電腦測試單件商品都能落單，手機客人在混合購物籃才發現運費消失。這個假設提醒我們：送貨規則要按整張訂單、每件貨及實際交收方式交叉測試，不能只試最順利的路徑。

以下以測試案例整理香港地址、運費、自取和訂單狀態。具體地區、承運安排、收費和時間必須由商戶依自己的營運條件訂立，再與實際運送夥伴核對。網站可以清楚顯示已設定的政策；它不能替商戶決定哪些地址真的有人送達。

先把送貨政策寫成能執行的規則

把模糊政策拆成輸入、結果和例外

一條能讓人測試的規則，最少有觸發條件、系統結果，以及不符合條件時的處理。例如「某些商品只限自取」仍欠缺商品清單、商品加入其他可送貨商品後怎樣顯示、客人換成送貨時怎樣提示。營運團隊可以先用日常接單語言寫下做法，再由網站負責人翻成欄位和邏輯，最後請前線同事檢查是否與實際交收一致。每次政策更新，都應說明生效時間及已落單但未出貨的訂單是否受影響。

有些規則彼此衝突：例如免運只適用送貨，活動又寫「全單免運」，而商品本身只准自取。遇上交叉情況，先由商戶定優先次序，網站才有明確答案。將不能自動處理的例外列出，比讓程式偷偷選擇一個結果更穩妥。

將「全港送貨」改寫成可核對的範圍

「全港」在宣傳字眼上簡潔，在結帳頁卻不夠具體。先列出可以送達的地區與不能送達的地區；若同一地區有附加安排，記錄觸發條件、由誰通知客人、何時才收取相關款項。地址選單的地區名稱須與出貨流程對得上，不要因為選單出現某個選項，就讓客人以為一定能按一般運費交收。商戶更新配送範圍時，也要同步修改商品頁、購物車、結帳頁和送貨說明。

列清楚商品屬性、計價依據與例外

每件商品可能有重量、尺寸、溫度要求或不能送貨的特性。這些屬性要由營運團隊確認，不應任由程式憑商品名稱猜測。規則要說明按每張訂單、每件商品、每個包裹還是整個購物籃計算；若幾種條件同時成立，哪條優先，以及能否合併出貨。當規則未決定時，與其在網頁硬填一個看似合理的運費，不如先把例外交給職員處理，避免落單後再追收未經解釋的費用。

• 商品資料：重量、尺寸、可否自取、是否需要分開包裝，由誰輸入和覆核。
• 地區規則：收件地址如何分類，無法送達的地址如何提示。
• 價錢規則：免運條件採用哪個金額，折扣前後按哪個基礎計。
• 交收規則：有無時段選擇，自取點有甚麼開放限制。
• 異常規則：送貨失敗、改址、拆單與退貨由誰跟進。

若仍未決定使用哪類網店平台，可以先帶着這份規則表比較候選系統：商品限制、運費條件、地址欄位和後台人手的需要，往往比結帳頁的外觀更能決定合不合用。

案例一：香港地址欄位怎樣填才不誤導客人

填表時的私隱與交收需要一同考量

地址及聯絡電話是完成交付所需的個人資料，商戶應按實際用途決定保留與顯示方式。訂單摘要提供前線需要的資訊，但不等於每位後台使用者都要看見全部資料。若客人選擇自取而不需要送貨地址，便檢查系統是否仍強迫輸入住宅地址。測試環境儘量用虛構資料，避免把真客戶資料複製到開發中的網站或發給外部測試帳戶。

跨區改址尤其要查核：香港島改成新界地址時，系統是否立即換用新運費與新送貨方式？舊的地區代碼會否留在隱藏欄位令後台出現兩個不同地址？測試者可以在確認頁逐字核對客人所見與後台所見，並寫下哪個欄位不一致。

地區和詳細地址各司其職

地區選項供系統判斷可否送貨與使用哪條運費規則；樓宇、街道、樓層和單位資料供職員安排實際交收。不能只用一個自由輸入欄位推算送貨地區，也不要要求客人反覆在下拉選單及文字欄位輸入相同資料。若店舖需要英文及中文地址，先決定後台怎樣向送貨人員顯示，避免某些資料在轉寄時被截斷。資料收集只應涵蓋完成交付真正需要的內容。

地址輸入含糊時，結帳頁怎樣處理

測試者可輸入完整住宅地址、商廈地址、只寫屋苑名的地址、缺少單位的地址，再看系統提示是否指出需要補上哪項資料。若地區未選，運費不應先顯示一個肯定能送達的最終數字；若所在地不在配送範圍，應在付款前說明不能用該送貨方式。提示要保留客人已輸入的內容，讓人修改一欄即可繼續，而不是每次報錯便清空整張表單。

1. 選一個有明確送貨規則的地區，核對運費及說明。
2. 改為不支援的地區，核對選項會否消失及原因是否清楚。
3. 填寫不完整地址，再補齊，確認購物籃沒有突然重設。
4. 改動地區但保留舊地址，核對地區和詳細地址是否互相衝突。

地址設計同時影響手機操作。如果送貨欄位太密、選項過長，客人容易在鍵盤遮住畫面時揀錯地區；版面應容許看到標籤和錯誤提示，不可只靠顏色表達。需要重整結帳頁時，可把這些錯誤情況帶進網站設計的測試，而非只看桌面截圖。

案例二：免運門檻與折扣先後次序

取消優惠和重新計算的次序

先套用優惠、再刪掉商品，或先刪掉商品、再套用優惠，理論上應回到同一條已定的運費規則。若兩個步驟得出不同價錢，可能是購物車保留了舊運費。再測一次瀏覽器返回及重新整理頁面，看看訂單摘要是否重算。若商品金額、運費與應付總額要經不同系統計算，商戶更須確定哪個系統是最終依據，以免付款後才發現差額。

不要在網站聲稱某項免運優惠適用所有商品，之後在隱藏條款中排除大件貨；適用限制應靠近優惠說明。若商戶會推出限時活動，也要測試活動結束的前後邊界，讓結帳前看到的價錢與提交當刻的規則一致，必要時提示客人重新確認。

免運金額按甚麼算，要讓人預先知道

有些店舖會按商品小計決定免運；另一些會按扣除優惠後的商品金額。兩種做法都要先由商戶確定，並在合適位置寫明。測試時設一張恰好達到門檻的購物籃、一張低於門檻的購物籃，再加入優惠碼觀察運費是否按既定方式重算。不要寫「滿額免運」卻在確認訂單後才告訴客人某類商品不計入門檻。

刪除商品與改數量後，金額需要即時同步

客人在購物車加商品、減數量、刪商品或套用優惠時，商品小計、運費、折扣與應付總額須同步更新。若運費要等選定地區才能計，介面應先清楚顯示「待選地址」，不要把未計算顯示成零。確認頁與實際收款資料應由同一組已核對規則產生，否則表面運費和最後應付金額不一致，客服便要逐張單解釋。

• 購物籃只差少量便達門檻，增加與刪去商品各測一次。
• 套用優惠前達門檻、套用後未達門檻，核對採用的計算基礎。
• 測試需分開寄出的商品是否排除免運，並檢查客人能否預先看見。
• 轉換收件地區後，檢查舊運費有沒有留在訂單摘要。

此處與網店開張前的準備互相配合：開張清單提醒商戶把交收政策交給相關同事確認，送貨測試集則把每條政策變成可重複操作的購物籃案例。兩者不能只靠「試過落一張單」代替。

案例三：一張單內商品有不同送貨限制

禮品與預購商品如何影響整單

假設商戶有一件現貨、一件待到貨商品及一件隨單附贈的贈品，網站須有明確答案：是否等齊商品一起交收、是否允許分批、贈品是否計重量。這只是測試情境，不表示所有網店都適用相同規則。若選擇分批，訂單頁要寫清楚是否另收運費及怎樣通知，後台亦須辨認哪件已寄出。先決定交付承諾，才有辦法配置系統，不宜用商品狀態欄位含糊代替實際安排。

測試可把商品依次移除，核對配送選項在限制商品消失後會否回復；再加入相同商品但數量增加，檢查包裹規則是否變動。這樣才能找出規則是跟隨商品、購物車還是過時的畫面狀態。

混合購物籃應先決定能否一併落單

假設一件貨只限自取、另一件可以送貨，結帳頁至少要清楚表明兩件貨能否在同一張訂單選不同交收方式。如果系統不能拆單，應在客人付款前阻止不合規組合或提供明確的替代選項。另一種情況是商品暫時不能出貨但仍顯示有現貨，運費即使計對了，履約仍會出問題；商品可售狀態與送貨規則應一同測試。

多件貨的重量或包裹數應怎樣處理

只用單件重量測試，可能漏掉同一張單跨越重量級距、需要兩個包裹，或某件大型商品不能與其他商品同箱的情況。先請營運團隊定義「加總重量」與「按件分箱」的適用範圍，再給系統一批典型及邊界購物籃。不要假設承運方會照網店寫的包裹數收費；實際規則需要用合作物流安排核實，網站才能照真實流程向客人表述。

1. 兩件一般商品一起買：是否只計一次基本運費。
2. 一般商品加大型商品：是否顯示可用方式及額外安排。
3. 只限自取與可送貨商品一起買：是否能付款，以及怎樣交收。
4. 多件商品跨過重量條件：是否依商戶指定的算法重算。

案例四：自取不是免運的另一個名稱

職員交收需要可核對的資料

客人到達自取點時，職員至少要確認是哪一張訂單、哪些商品已準備好，以及是否按商戶政策需要核對領取人。網站通知中的取貨資料應與後台一致，避免同一客人收到兩個不同的自取點。若安排他人代取，商戶須先決定接納條件及如何記錄，不能由網頁臨時加一句「任何人可代領」便算。

自取點若有容量或時段限制，測試兩張訂單幾乎同時選最後一個可用時段，確認系統會否超額接受；若系統本來沒有即時庫存或時段管理，就應清楚說明須由職員確認，而不是顯示似乎已鎖定的時間。發現交收資訊不準確時，先修通知，再調整版面文字。

自取點、時間和通知方式都要交代

提供網店自取時，客人需要知道地點、可選時間或開放安排、取貨所需資料，以及商品未準備好之前可否前往。若沒有即時可選時段，便寫明何時會由店舖聯絡確認，不要在訂單電郵直接寫「即時可取」。地址或營業安排一旦更改，訂單通知、網站說明和職員使用的交收紀錄都要同步更新。

自取與送貨切換後仍要保留正確資料

先選送貨並填入地址，再改成自取；檢查系統不會繼續計送貨費，也不會在確認頁同時顯示舊的送貨地址。再由自取切回送貨，核對是否要求重查地址與運費。客人已填的聯絡資料可保留，但不能讓過時送貨方式的隱藏欄位意外進入後台或通知電郵。這類交叉測試很適合用真手機完成，因為切換選項後畫面長度會改變。

• 不同自取點是否只供指定商品選擇。
• 遇上店舖暫停自取時，選項會否被及時關閉。
• 未取貨和逾期未取的處理政策是否已向客人說清楚。
• 同事交接時能否從訂單紀錄找到交收狀態，而不用猜測。

案例五：付款前後的送貨狀態能否對上

付款未完成時，別把單當成已準備出貨

下單、付款、確認收款、包裝、交付承運或通知自取，屬不同階段。若客人付款中斷、返回網店、稍後才重試，系統應避免重複建立出貨指示。送貨方式與運費應在付款前確認；付款後若需要改地址或增收費用，先由商戶決定授權及通知流程，不能靠客服自行更改一個欄位而讓訂單金額、收款和送貨紀錄各自不同。

通知內容要由實際狀態觸發

訂單電郵如果寫了「已寄出」，後台卻只是收到付款，客人會誤以為包裹已交付。應分辨收到訂單、確認付款、準備商品、交寄、自取可領，以及送達或完成；有些狀態可能需職員手動確認。可用假設測試訂單核對每個狀態的通知、收件人和內容；不要把測試用客戶資料發到真實名單。付款與出貨之間的銜接，可參照香港網店付款方式的核對思路，確保付款結果與後台狀態一致。

案例六：改地址、送貨失敗與退回商品

改地址申請要有截止點

客人落單後可能想改樓層、電話或整個送貨地區。商戶須先界定哪些狀態可自行修改、哪些要人工審核，以及改動是否影響運費和已安排的送貨。網店不要把所有訂單一直留一個可編輯地址欄，因為貨品交付出運後，畫面上的新地址不代表承運人收到更新。職員應有一處可追查的修改紀錄，客服才知道哪個版本對客人說明過。

送貨失敗後，誰先通知、誰負擔新安排

無人收貨、地址不全、聯絡不上或商品退回，都可能影響再配送。這些不是一條固定程式規則可以代商戶決定的事，必須先寫明聯絡渠道、職員處理步驟及收費政策，並與承運安排對上。測試訂單時可以把狀態設成「待跟進」，檢查客服能否識別，避免系統自動當作已送達而關閉跟進。若日後要自行管理退貨，退款及重新寄件也應分開記錄。

結帳頁資訊怎樣排，客人才不會到最後一刻退單

在選交收方式前放足夠的解釋

商品頁應先讓人知道大方向：是否供送貨、是否只限自取、是否有特殊交收要求。購物車告訴客人運費尚待選地區、或是否達到免運條件；結帳頁列出可選方式、每個方式的已知費用與限制；付款確認前再展示商品、地址、自取點、運費及總額。不同畫面的資料要沿同一份規則更新，不能商品頁寫「可送」而結帳才無端移除選項。

讓人分清楚估算、確定費用與待覆核情況

如果某些地址或商品需由職員報價，應清楚表述「待確認」及接下來的處理方式，並與正式可付款的訂單分開。顯示零運費可能被理解為免費送貨，空白則可能令人以為網頁壞了；這兩種做法都無法解釋待覆核狀態。若購物籃必須先提交查詢，流程應讓客人知道是否已付款、預計由誰回覆，以及確認前可否修改商品。

建立一份可以反覆執行的送貨測試紀錄

把政策修改納入驗收和同事交接

每次新增送貨地區、換一家承運夥伴、調整免運門檻或開放新的自取點，都應由政策擁有人列出改動範圍。網站同事依修改範圍挑選相應案例，營運同事再核對出貨清單和通知內容；任何人都可以從紀錄找到「原本應怎樣、現在顯示怎樣」。上線後如果客人反映金額不一致，先用同一組商品、地址及時間重現，不宜直接在正式訂單改價而沒有保留原始資料。

送貨規則通常會牽動付款和庫存，因此每次驗收都要包含至少一宗付款前更改購物車，以及一宗付款後按既定流程改單的假設測試。若涉及退款或加收費用，先請負責商業政策的人確認，再把結果寫進客服說明；程式只負責執行已批准的規則。

每宗案例同時記錄預期與實際

用一張簡單測試單記錄案例名稱、商品組合、數量、地區、地址、自取選項、折扣情況、預期運費、實際顯示、訂單通知及後台結果。與其只寫「過關」或「失敗」，不如附上客人看到的文字及職員看到的狀態。規則若更改，記錄修改日期及負責核對的人；日後重跑同一案例，便可辨認改動是修好了問題，還是把別的選項弄壞。

用邊界與例外補上平常測試的盲點

測試一張最普通的單，再測免運門檻前後、無法送達的地址、兩種限制商品混購、送貨改自取、訂單付款中斷及地址修改。每種案例至少試一次桌面和手機操作，特別留意選擇地區、輸入詳情、看總額時畫面會否跳回上一段。網站正式上線前，再由負責出貨的同事按紀錄實際走一次流程，確認後台欄位足以執行交付。

• 每次改動規則，都重跑與該條件相連的邊界測試。
• 每次加入新商品類型，都檢查交收限制與混合購物籃。
• 每次更新送貨地區，都檢查地址選單、說明頁和通知內容。
• 每次更換付款或送貨安排，都檢查結帳總額及後台狀態。

再做一輪由客人角度出發的實際檢驗

請沒有參與設定的同事從商品頁開始，假設他只知道要買甚麼，不知道店舖內部的運費表。他選一件普通商品，進結帳頁填地址，看到運費後再換一個地區；之後回到購物車加一件限制商品，檢查系統會否清楚解釋選項的變動。若最後需要致電客服才明白可否送貨，說明畫面資訊還不夠清楚；修改說明後再讓另一位同事從頭試一次，看看是否真能自行完成。

另一輪由出貨人員從後台開始。他收到一張假設測試訂單，只憑訂單紀錄能否辨認要寄甚麼、送到哪裏、自取還是送貨、是否已付款、要不要等另一件商品？若要同時翻查聊天紀錄才能找到答案，就要補上欄位或流程，而不只是重新寫前台文字。客人與職員兩端都能按同一張單工作，才算通過交收測試。

店舖日後增加貨品、改配送範圍或調整自取安排時，安排一位政策負責人決定規則，另一位負責人按測試案例核對網站結果；重大改動才需要額外進行跨系統測試。把測試單和政策版本留存，遇到客訴可回看當時生效的說明，而不是用今天的條件猜測昨天訂單的運費。

哪些變更要先通知客服

送貨政策改動常會影響客人已看到的資訊。若商戶暫停某地區送貨、改自取點或調整運費，要先確定適用於哪個時間之後建立的訂單，並告知客服如何處理舊訂單查詢。網站顯示新規則時，後台仍可能有舊規則下的待出貨訂單；不能用目前的運費表直接推斷原單應收費用。版本紀錄與訂單當時的顯示結果，對跟進爭議尤其有用。

若已付費訂單需要改送貨方式，先由客服按照商戶政策解釋差額與時間安排，再由獲授權同事更新紀錄；修改後要核對通知是否送到正確收件人，訂單摘要有沒有保留清楚的變更理由。這些工作不一定需要複雜系統，但需要清晰的先後次序和交接資料，否則幾位同事容易各自向客人作不同承諾。

最後交付給營運同事的是一份能用的規則

網店送貨設定的工作，不是填完地區和價錢便算數。先用政策清單定義商品、地區、運費、自取和例外，再用假設購物籃逐一驗證畫面、付款與後台狀態是否一致。若店舖準備調整網上商店，可帶同目前商品種類、交收限制與已知難題，向 Black Media 說明實際流程；想先釐清測試範圍，亦可透過聯絡頁提出最常見及最棘手的送貨案例。