物流、貿易與跨境電商

計費邏輯是這個產業最複雜的部分

物流的費用不是單純的「一公斤多少錢」。實務上至少涉及：

• 實際重量與材積重量，取大者計費
• 目的地分區
• 重量級距
• 最低收費
• 附加費用

把這套邏輯講清楚，比做一個試算器更重要——因為客戶如果不理解為什麼是這個價格，試算出來的數字他也不會相信。

材積重是最常被誤解的概念

客戶最常見的抱怨是：「我這箱明明只有 3 公斤，為什麼算我 12 公斤？」

原因

運輸工具的限制不只是重量，空間同樣是成本。 一箱棉被很輕但很佔位，一箱書很重但很小。

所以業界的做法是：把體積換算成一個「材積重量」，與實際重量相比，取較大的那個計費。

網站上該怎麼說明

• 用具體的例子說明——棉被與書的對比最容易懂
• 寫出換算的公式與係數——各家不同，要寫自己的
• 提醒量測方式——外箱尺寸而非物品尺寸
• 說明會不會重新丈量——以及以誰的數據為準

最後一項最常引發爭議。 事先寫清楚「以本公司倉庫實測為準」，能省下大量的事後解釋。

附加費用要全部列出

這是這個產業客訴的主要來源——結帳金額比預期高。

常見的附加項目：

建議在費用頁把所有可能的項目一次列完，並說明什麼情況會產生。

「沒說會收的費用」造成的信任損失，遠大於「事先說了但客戶覺得貴」。

要不要做試算器

先做費率表與說明

對多數業者，一張清楚的費率表加上完整的計費說明，就能解決八成的詢問。

而且費率表的維護成本低——調價時在後台改一個表格即可。

試算器的三個難點

1. 規則的例外很多——特殊品項、特殊尺寸、季節性調整
2. 算出來的數字客戶會當成報價——與實際收費有落差時容易爭議
3. 規則變動時要改程式，不像表格能自己改

如果要做，建議

• 明確標示為「估算」而非報價
• 說明哪些情況不適用
• 費率參數要能在後台調整，不要寫死在程式裡
• 提供「無法估算時請聯絡我們」的出口

第三項是關鍵。 費率寫死在程式中，每次調價都要付工時給廠商。

費率表不要做成圖片

這是這個產業最常見的技術錯誤。

四個問題

• 搜尋引擎讀不到——而「運費」正是被搜尋最多的內容
• 手機上會縮到看不清楚
• 改一個數字要重做整張圖
• 視障者完全無法取得資訊

正確做法是用表格，並讓後台能自行修改。

訂單查詢：先決定查詢方式

個資的考量

如果查詢結果會顯示收件人姓名、電話、地址，那就不該只憑單號查詢。

建議至少加上一道驗證——例如收件人手機末三碼。

或者：單號查詢只顯示貨態，不顯示個人資料；完整資訊要登入會員才看得到。

個資的處理原則見網站會蒐集到哪些個資。

貨態的狀態設計

狀態不是越多越好，也不能太少。

太少的問題

只有「處理中」與「已送達」，客戶完全不知道進度，還是會打電話問。

太多的問題

二十幾種狀態，客戶看不懂差別，而且現場人員很難每一步都確實更新。

建議的原則

• 每一個狀態都要對應到客戶關心的事
• 每一個狀態都要有人負責更新——沒人更新的狀態不要設
• 異常狀態要能說明原因——「查驗中」「待補件」比「異常」有用得多

最後一項很重要。告訴客戶「卡在哪裡、要做什麼」，比只顯示「處理中」有價值得多。

資料從哪裡來

這決定了開發成本與可行性。

方式一：人工更新

• 成本最低，適合量不大的業者
• 但要考慮：誰更新、多久更新一次、用手機還是電腦
• 後台的更新介面一定要簡單——複雜的話現場就不會更新

方式二：批次匯入

• 用試算表批次更新多筆
• 對每天有一批貨要更新的業者很實用
• 要注意格式的容錯與錯誤回報

方式三：串接物流商系統

• 最即時，但成本最高
• 需要對方提供介面
• 對方改版時可能需要配合調整——這筆費用要事先約定
• 要處理「對方系統無回應」的情況

串接的評估見API 串接前要確認什麼。

務實的建議

先做人工或批次更新，累積三到六個月後再評估要不要串接。

屆時你會清楚知道實際的更新頻率、人力負擔，以及客戶真正需要多即時。

正確性比即時性重要

這是實務上的重要判斷。

顯示「昨天下午到倉」但正確，好過顯示「即時」但錯誤。

錯誤的狀態會造成客戶白等、白跑，或誤以為貨遺失——這比更新慢造成的困擾大得多。

建議

• 標示最後更新時間
• 說明更新的頻率——「每日上午更新」
• 異常時提供聯絡管道

通知機制

主動通知能大幅減少查詢與客服負擔。

• 到倉通知
• 出貨通知
• 待補件或異常通知——最重要的一項
• 送達通知

管道的取捨

通訊軟體在台灣的開啟率最高，但要注意訊息費用會隨好友數成長。建議只在關鍵節點通知，不要每個狀態都推播。

成本結構見LINE 官方帳號的費用怎麼算。

驗收時該測的

1. 用手機完成一次查詢
2. 查詢不存在的單號——錯誤訊息是否清楚
3. 費率表在窄螢幕是否可讀
4. 後台修改費率，確認前台正確更新
5. 更新一筆貨態，確認查詢結果同步
6. 確認查詢結果沒有洩漏不該顯示的個資

第六項務必測試——用別人的單號查詢，看會顯示到什麼程度。

各業者的計費規則、服務範圍與作業流程差異很大，本文說明的是規劃原則與該確認的項目。實際的功能範圍與費用請依個案評估。

費用的組成

最大的分水嶺是「有沒有一般消費者直接下單」。

• 純詢價型——接近一般企業形象網站的複雜度
• 有會員與線上下單——接近電商，成本明顯提高

能問到準確報價的九個問題

1. 客戶會在線上直接下單嗎？ 還是先詢價
2. 需要會員系統嗎？
3. 計費規則有幾種？——分區、分級距、附加費用各有幾項
4. 要做費率表，還是自動試算？
5. 需要訂單查詢嗎？資料怎麼來？——人工、批次匯入或串接
6. 要顯示幾種貨態？
7. 需要串接物流商或報關系統嗎？
8. 需要線上付款嗎？——或採匯款方式
9. 需要幾種語言？

第三題與第五題最影響工時，卻最常被含糊帶過。

報價的組成見網站架設費用怎麼算。

建議的分階段做法

第一階段：說清楚

• 服務範圍與流程
• 費率表與計費說明
• 禁運與限制品項
• 常見問答
• 賠償與責任辦法
• 詢價表單與聯絡方式

這個階段就能承接大部分的詢問，成本也最可控。

第二階段：查得到

• 訂單或貨態查詢（先用人工或批次更新）
• 基本會員
• 通知機制

第三階段：自動化

• 線上下單與付款
• 費用自動試算
• 串接物流商系統

第三階段一定要等實際營運資料累積後再做。 屆時你會知道真正的例外有哪些、客戶真正需要多即時。

付款可以先用簡單的方式

不一定一開始就要串接第三方金流。先用匯款或轉帳，把介面預留起來，確認交易量之後再評估。

順霏供應鏈管理顧問有限公司的網站就是這個做法——購物與訂單流程完整，付款目前採 ATM 匯款，金流串接介面已預留。見作品說明與技術規格。

七個常見的規劃錯誤

一、計費規則沒定案就開始開發

最嚴重的一項。 計費邏輯是這類網站的核心，規則改動會牽動費率表、試算、訂單金額計算。

建議在開案前就把規則寫成文件並定案。

二、費率表做成圖片

搜尋引擎讀不到、手機看不清楚、改價要重做圖。而「運費」正是被搜尋最多的內容之一。

三、貨態設計沒想清楚誰更新

設計了十五種狀態，但現場沒有人力逐一更新，結果多數訂單永遠停在「處理中」。

每一個狀態都要有明確的更新者與時機。

四、禁運品說明太簡略

客戶最怕寄出後才被告知不能運。這一頁寫得完整，能減少大量爭議。

五、查詢功能洩漏個資

只憑單號就能查到收件人的姓名、電話、地址。單號可能出現在包裹外箱、對話紀錄、群組截圖中。

建議加上驗證，或分層顯示。

六、賠償規則沒有事先寫明

出事後才討論，雙方各說各話。事先寫清楚是保護雙方。

七、做了多語系但沒人維護

內容停留在兩年前，或機器翻譯品質不佳。與其三種語言都沒更新，不如一種語言做好。

見多語系網站的內容怎麼管理。

工期的參考

影響工期的主要因素：

• 計費規則是否已定案——這通常是最大的變數
• 費率資料的整理速度
• 是否需要串接
• 語言版本數量

業主端最常造成延誤的三件事

1. 費率還在調整——網站做到一半又改規則
2. 禁運品清單還沒整理
3. 貨態的定義沒有共識——不同部門講法不同

建議開案前先把這三項寫成文件，能明顯縮短時程。

資料準備清單見網站規劃階段要準備哪些資料。

長期維護的考量

這個產業的費率、航線、規則變動頻繁，網站的可維護性比一次性的美觀更重要。

發包時要確認的五件事

1. 費率能不能自己改？
2. 新增服務項目或航線，能自己加嗎？
3. 禁運品清單能自己更新嗎？
4. 貨態能用手機更新嗎？
5. 網域與主機登記在誰名下？

第四題容易被忽略——現場人員不會坐在電腦前，如果只能用電腦更新，實際上就不會有人更新。

第五題最根本：管理權可以外包，所有權應該在自己手上。見網域要自己註冊還是交給網頁設計公司。

在地曝光也要顧

雖然業務是跨境的，但客戶找承攬業者時常會搜尋在地——「某某地區 報關行」「某某地區 集運」。

建議把商家檔案建立完整，包含地址、營業時間、服務項目。見Google 商家檔案是什麼。

驗收時的重點

1. 後台修改一筆費率，確認前台正確更新
2. 用手機更新一筆貨態
3. 用手機完成一次查詢
4. 用他人單號查詢，確認不會洩漏個資
5. 費率表在窄螢幕可讀
6. 從外部信箱確認收得到詢價通知
7. 請實際會用的同仁操作後台一次

最後一項最有價值——後台好不好用，決定往後幾年的維護成本。

驗收項目見網站驗收怎麼做。

各業者的計費規則、服務範圍與作業流程差異很大，本文說明的是規劃原則與該確認的項目。實際的功能範圍與費用請依個案評估。