網店平台比較：香港商戶如何評估租用平台與自訂開發

網店平台比較，先把兩份功能清單放到同一張枱

兩份方案都寫着商品管理、網上付款和訂單通知，為甚麼仍然難以選擇？網店平台比較真正要看的，是功能如何配合每日工作、資料能否完整取回，以及日後改動由誰負責。租用平台與自訂開發各有適用情況，功能名稱相同，實際限制和管理責任卻可以相差很遠。

如果只是逐格數哪份清單較長，很容易忽略最影響營運的幾個細節：同一件貨有多種售價能否處理、付款失敗會不會佔用存貨、同事能否只看自己的工作，以及離開平台時哪些資料無法直接轉移。選型應把這些情況變成可展示的操作，而不是只接受「支援」兩個字。

以下比較的是服務模式和評估方法，並非任何指定品牌的套餐排名。不同供應商、版本及合約可以有不同安排，涉及費用、接口或功能限制，應以實際提供的文件和示範確認。商戶需要的是一個適合自己運作的系統，不是抽象地選出功能最多的平台。

先分清三種模式，別把代管與租用當成同一回事

租用平台：使用現成能力，也接受既定邊界

租用網店平台通常由供應商維持核心系統，商戶透過後台設定商品、內容及部分營運規則。好處是不用由零建立整套基礎功能，但可修改程度會受產品設計、方案和接口限制。供應商負責平台運行，也不等於包辦你的商品資料、帳戶權限和訂單處理。

這種模式適合願意採用既定流程、需要較快驗證銷售方式的商戶。評估重點不是畫面能否改色，而是核心操作是否足夠接近公司的做法。若每次接單仍要下載資料、修改格式再傳給另一人，便要把這些人手工作列入比較，不能因為網站前台可落單就視為整合完成。

自訂開發：可按需要設計，也要承擔持續管理

自訂網店可以按已確認的規則建立功能和資料結構，但不代表任何想法都能無成本加入。需求分析、開發、測試和維護都需要安排；程式交付、授權及帳戶控制亦要在合作文件寫明。把「自訂」理解為沒有任何限制，和把「租用」理解為完全不用管理，同樣不準確。

還有使用現成系統再由服務團隊代管的方式。它可能同時涉及系統授權、擴充程式和維護合約，不能單憑「有人幫手管理」就判斷屬哪一類。先了解系統由誰更新、資料存在哪裏，以及商戶可以自行做甚麼，才能放進公平比較。

先完成一份交易路線，再看示範網站

比較前，商戶應用自己的商品走一次紙上流程：客人怎樣找到商品、看到甚麼價格、如何選規格、何時確認付款，以及誰安排出貨。每一步都列出可能失敗的情況。這份路線不需要技術名詞，但必須反映實際營運，而不是供應商預設的最簡單訂單。

若公司連網站目標和負責人也未確定，可以先按網站需求整理步驟界定範圍，再進入平台示範。需求未清楚時，任何現成畫面都容易令人覺得足夠；到了真正上架、對數和出貨，差異才會出現。

用同一組情境比較每個候選方案

假設一間荃灣家品店，同時有現貨、預訂品及門市自取。示範時應用同一張混合購物籃，查看不同商品是否可分開安排、運費怎樣計算，以及客人在哪一步知道等候條件。這是假設情境，目的在於測試規則，不是描述任何真實商戶的成效。

1. 挑選能代表主要業務的商品及訂單情境。
2. 加入至少一個付款、存貨或地址例外。
3. 要求展示前台及後台的完整結果。
4. 由實際營運同事重做一次，而非只觀看示範。
5. 記錄需要人手補做的步驟及未能確認的限制。

每次示範都應留下一份結果，標示「已實測」「只見文件」「仍待確認」。不要把銷售人員口頭說可以做的功能，與已用你的資料成功完成的操作放在同一可信程度。尚未確認的項目若涉及主要交易，就應先釐清再作選擇。

試用帳戶還要確認看到的是哪個方案。有些示範開啟了全部功能，但商戶實際考慮的版本未必包括相同權限或整合。記錄示範所用功能的名稱、取得條件和限制，要求方案文件與示範對應，才不會把尚未包含的能力當成已同意交付。

最後把未解答問題交回同一位聯絡人整合，避免各部門分別取得互相矛盾的答案。只有回覆已落在同一份範圍文件，商戶才知道自己真正正在比較哪一個方案。

商品資料結構，往往比首頁樣式更影響日後工作

規格選項和獨立商品並不一樣

一件商品有不同顏色和尺碼，可能每個組合都有獨立存貨、圖片及貨品編號。平台若只容許前台顯示選項，卻不能按組合管理貨量，營運仍要另外處理。比較時應查看商品變體如何建立、匯入和停用，不要只看選單能否顯示。

同樣，套裝、贈品和預訂品也不只是文字標籤。套裝是否扣減組成商品的存貨、贈品缺貨如何處理、預訂是否與現貨一併出貨，都會改變系統規則。即使第一階段不做全部功能，也要知道往後擴充會否需要重整商品資料。

商品編號也值得在試用時檢查。有些公司的編號以零開頭，或同時包含英文字母和連字號；若匯入程序把它當作一般數字處理，便可能失去原有格式。用少量有代表性的資料測試新增、更新及再次匯出，確認同一件商品不會被誤建成另一筆紀錄。

內容展示要跟資料來源配合

商戶經常把規格寫在圖片內，之後改一項資料便要重新製圖，也難以供站內篩選使用。若某些欄位會反覆查詢、比較或更新，宜評估能否保存為獨立資料。這不是要求所有內容都結構化，而是把需要重用的資料從裝飾性版面中分開。

當商品介紹與品牌內容需要特別安排，可以把網站版面與內容設計納入評估，確認前台彈性是否足以呈現你的資料。能自由放區塊與能穩定維護大量商品是不同問題；版面再靈活，也不應迫使同事每次逐頁手改相同內容。

• 商品、規格組合及貨品編號之間能否清楚對應？
• 哪些欄位可以批量匯入，更新時如何避免覆蓋錯誤？
• 停售商品可否保留資料及舊網址安排？
• 圖片、說明和存貨由哪個系統作為主要來源？

付款支援要看到訂單結果，不能只看付款標誌

平台列出付款方式，並不等於商戶已完成帳戶申請或正式啟用。應確認商戶資格、貨幣、對帳資料、退款能力及正式設定由誰處理。不同付款服務的條件會變動，不能把另一間商戶的安排直接套用到自己身上。

分開付款成功與訂單狀態更新

客人完成付款後，平台仍可能需要接收付款服務的通知，再更新訂單。若通知較遲到達，後台會顯示甚麼？如果通知重複送達，會否重複發貨或扣存貨？選型時不一定要懂程式寫法，但應要求團隊說明如何避免重複處理，以及如何追查狀態差異。

退款也需要實際流程。全數與部分退款是否都支援、運費是否包含、存貨會否自動回補，以及會計如何取得紀錄，均要確認。有些動作可能需要在付款服務後台完成，再手動更新訂單；這未必不能接受，但必須計入同事工作和出錯機會。

付款測試應使用供應商提供的測試方法，正式交易則按其規則安排。不要只用一張成功訂單驗證所有情況。取消付款、付款失敗和客人返回上一頁，都可能造成不同狀態；系統應向客人清楚交代，並讓同事知道是否需要跟進。

送貨、存貨與多渠道營運，要問誰是資料的主控方

若門市和網店同時售貨，必須決定哪個系統保存主要存貨，以及其他渠道何時同步。所謂同步可以是即時事件、定時更新或人手匯入，三者對售罄風險和工作安排不同。沒有說明頻率、失敗通知和衝突處理，就不算完整的整合安排。

先處理例外，再確認正常流程

地址不完整、部分商品缺貨、客人要求改自取，都是可用來評估的例外。平台應讓同事找到原有訂單及修改紀錄，知道哪些動作已通知客人。若修改送貨方式會影響運費或付款差額，也要明確說明由系統處理還是人手跟進。

接駁物流服務時，要分清建立運單、取得追蹤號碼、更新物流狀態和預約收件。某方案支援其中一項，不代表全部都已包括。亦應確認接口失效時的替代操作，避免同事因為系統暫時未取得追蹤號碼而完全無法安排出貨。

比較多渠道功能時，最好把一張訂單從建立追到完成，再看取消、退貨及補寄如何記錄。只展示貨量數字相同，未必能證明交易過程一致。當兩邊同時修改同一筆資料，系統需要有清楚優先規則，而不是事後靠同事猜哪個數字較新。

若接口採用定時同步，要問一次同步失敗後會不會再試，以及重試是否可能重複建立訂單。商戶未必需要自行處理技術細節，但後台應提供足夠狀態或報告，讓人知道哪一筆需要跟進。完全沒有提示的失敗，比已知要人手處理的步驟更難管理。

權限與日常管理：誰可以看、誰可以改、誰可以匯出

店主、客服、倉務及會計需要的功能不同。選型時可以建立幾個測試角色，確認倉務只處理出貨時，是否仍可看見不需要的資料；客服可否退款、折扣可由誰設定，以及離職後能否立即撤銷個別人的存取權。

若所有同事共用一個管理帳戶，便難以判斷由誰改動，也難以在個別人離職時精準停止權限。平台有帳戶功能並不足夠，還要看是否有合適的角色、操作紀錄及帳戶復原方法。這些能力應與公司的分工相配，不必為了複雜而複雜。

• 用最少所需權限建立日常營運角色。
• 核對大量匯出客戶資料是否有適當限制。
• 查看退款、改價及取消訂單有沒有操作紀錄。
• 確認帳戶復原及額外驗證由公司掌握。
• 測試移除一名同事後，其他人能否繼續接手。

資料保留也要考慮用途。網站需要完成交易和提供服務，但不代表所有測試資料及過期附件都應永久保存。比較時應了解刪除、匯出和保留功能如何運作，再按公司的實際責任制定做法。不能只因為空間仍足夠，就忽略資料管理。

寄存、更新和支援，應列明誰處理哪一層

租用平台通常把部分運行工作包在服務內，但商戶仍要理解支援範圍。第三方擴充、自己修改的模板、付款帳戶及商品資料，可能由不同團隊處理。出現問題時，如果每一方只說自己的部分正常，商戶就需要一條可以協調排查的路線。

自訂系統則要把網店寄存與運行安排一併考慮，列明程式更新、執行環境、備份及故障處理分工。購買主機資源並不自動包含修正所有程式問題；網站開發合約也未必包含日後每項環境變更。這些責任應在採購前說明。

測試支援問題能否被有效接手

可以提出一個假設問題：「客人付款了，但訂單仍待付款，商戶需要提供甚麼資料？」好的比較結果應是清楚知道如何取得訂單編號、付款紀錄及發生時間，以及由誰協調處理。不能只用支援渠道有多少個，代替實際處理範圍。

更新亦有營運影響。平台更新後，模板、擴充或接口可能需要重新確認；自訂系統更新則需要安排測試和回復。選型時問清測試環境、更新通知及緊急處理方式，比籠統承諾「長期支援」更有用。任何可用性或回覆時間都應以實際合約為準。

資料能帶走多少，現在就應做一次匯出演練

能下載一份商品表，不代表已擁有可搬遷的完整網店資料。圖片、規格組合、分類關係、會員地址、訂單狀態、折扣紀錄和舊網址，都可能分開保存。比較時應取得匯出樣本，讓負責接手的人判斷內容是否足夠，不宜只問「可不可以匯出」。

匯出後要看資料能否互相對應。例如訂單內的商品編號，是否仍能對應已停售商品；會員被刪除後，歷史訂單會留下甚麼；圖片連結在停止訂閱後是否仍可取得。這些問題需要逐項確認，不能假設下載完成便代表可以還原原來系統。

還要查看匯出欄位是否有說明。日期採用哪個時區、價格是否包含某項費用、狀態代碼代表甚麼，若完全沒有定義，接手者可能把資料解讀錯。匯出格式不是越多越好，而是主要資料要可理解、可對應，並有方法核對筆數及交易關係。

停止服務的程序也應寫進退出安排：何時停止收新單、何時取得最後一份資料、誰保存備份，以及商戶何時失去後台存取。不要先取消帳戶才開始下載資料。舊網址和客戶仍會使用的連結，也要有相應去向，否則即使新系統已運行，舊入口仍可能中斷。

自訂開發也不能省略退出檢查。應確認程式使用權、部署文件、資料庫結構及第三方授權是否容許另一團隊接手。拿到檔案但沒有相依設定，仍可能無法運行。選擇前就談交接，能讓雙方清楚責任，不必等合作結束才補問。

計算整段使用期間的投入，不只比較第一張帳單

比較成本時，可以分成初始建立、持續使用、內部營運及日後變更四部分。這裏不需要填入任何假價錢，而是請每個候選方案按相同項目交代收費方式及限制。月費、開發費或代管費只代表不同計價形式，不能單獨說明整體是否合適。

把人手補做的工作寫進比較

如果每天需要轉換訂單格式、核對庫存或重複輸入地址，這些工作會佔用同事時間。可以用實際測試記錄每一步，由公司自行估算影響，不必引用沒有來源的節省百分比。同樣，自訂功能能減少某項人手工作，也要考慮開發及維護責任。

若正在考慮按營運流程製作網店，宜把最費時或最易出錯的工作交代清楚，讓方案回應具體問題。不是每個人手步驟都值得自動化；偶爾發生而需要判斷的例外，保留可追查的人手處理，有時比複雜規則更合適。

• 初始建立是否包括資料整理、匯入及同事培訓？
• 持續使用有哪些用量、交易、帳戶或擴充相關費用？
• 哪些規則可自行設定，哪些改動需要另行安排？
• 停止使用時，匯出、交接及保留資料如何計算？

亦要比較公司能負擔的管理複雜度。功能較多但只有一人懂操作，未必比簡單而多人能接手的流程穩健。相反，當交易規則已明確而且反覆出現，長期依靠多份試算表拼接，也可能成為營運負擔。選擇應配合人手，而非只看技術彈性。

用淘汰條件和實測證據作決定

不建議把所有項目隨意打分再加總，因為核心交易做不到，不能靠漂亮模板補回。先訂必須通過的條件，例如某種訂單流程、資料匯出範圍或指定權限。未通過的方案先釐清能否修正，通過後再比較操作便利、維護方式及投入。

最終決定應附上已知限制。接受某個限制並不代表選錯，只要公司清楚後果和替代安排。例如第一版暫時人手審核批發帳戶，但保留日後擴充需要的資料；這比要求供應商籠統承諾將來全部可做更容易管理。

如果兩個候選方案都能完成主要交易，便可選一項最常發生的營運改動作最後比較，例如批量改價或更換送貨規則。讓同事按正式權限操作，觀察是否容易預覽、核對及回復。這能揭示日常管理差異，毋須再為少用的裝飾功能反覆爭論。

不要因示範順利便省略試用者回饋。讓客服處理查詢、倉務安排出貨、會計找一張退款紀錄，往往比店主單獨看首頁更能發現實際問題。各人提出的困難應分清是需要培訓，還是系統本身欠缺能力，兩者的處理方法不同。

常見問題

租用平台是否一定比自訂開發便宜？

不能只比較初始付款。要把持續費用、擴充、用量、營運人手及退出安排一起看。標準流程可能適合現成平台，特殊規則可能需要額外整合。沒有相同需求和使用條件，就不能作出可靠的價格結論。

自訂網店是否代表所有程式都屬於商戶？

要看合約、授權及第三方元件安排。「自訂」描述製作方式，不自動決定所有權或轉交權。應列明可取得哪些程式、文件及資料，另一團隊能否接手，以及有哪些元件需要另行授權。

有付款圖示，是否代表可以立即收款？

未必。商戶仍可能需要申請帳戶、完成審核及正式設定，亦要確認適用貨幣和退款方式。應要求展示完整交易結果及對數流程，不要只以版面上的圖示判斷已經啟用。

日後可以搬平台，是否現在不用考慮退出？

恰好相反，現在就應確認匯出範圍和資料結構。商品能搬不代表會員、歷史訂單、媒體及網址都能直接轉移。越早知道限制，越能決定哪些資料要另行保存，避免日後臨時補救。

應否一開始便做齊所有功能？

可先完成主要交易及必要管理，再根據真實營運增加功能。但第一版仍要清楚處理付款、存貨及訂單狀態，不能以日後再做為由留下無人負責的交易環節。延後的是已知擴充，並非基本責任。

下一次看示範，帶自己的資料和問題去

準備一組代表性商品、一張正常訂單和幾個例外情況，再要求候選方案展示同樣流程。看完之後，應能說出哪些已實測、哪些需要人手，以及哪些仍待確認。選擇才有依據，不會只記得哪個首頁較搶眼。

Black Media 提供網上商店及程式編寫服務。若你希望先釐清資料控制、營運規則及交接需要，可以帶着這份比較清單討論網店平台取捨，把尚未確認的問題逐項列明，再決定適合的製作方式。