功能規格與報價

商品結構是電商報價最大的變因

「有幾項商品」不是重點——一百項單純的商品，可能比二十項有多重規格的商品簡單得多。

真正影響工作量的是商品的結構。

單一商品與多規格商品

組合數量會快速膨脹

5 種顏色 × 6 種尺寸 = 30 個組合，每一個都要各自管理庫存、可能各自有價格與圖片。

如果再加上第三種規格（例如材質），組合數會再乘一次。後台的建檔工作量與系統複雜度都會明顯上升。

要先決定的事

• 最多幾種規格軸線（顏色、尺寸、材質⋯⋯）
• 是否每個組合都有獨立庫存
• 是否每個組合都可能有不同價格
• 缺貨的組合要隱藏還是顯示為不可選
• 圖片是否隨規格切換

第四項建議選「顯示為不可選」——直接隱藏會讓客戶以為沒有這個選項，顯示為缺貨反而可能促成詢問或等待。

商品編號的規劃

這件事在只有網站時不重要，但只要涉及實體庫存或系統串接，就變得關鍵。

• 每個規格組合都要有自己的編號，不能只有商品層級的編號
• 編號規則要與現有的進銷存一致——否則串接時要做對應轉換，增加成本
• 編號一旦上線就不要輕易更動

資料對應的落差是串接成本的主要來源，見API 串接前要確認什麼。

分類架構

商品分類影響的是客戶找不找得到東西，也影響後台的管理效率。

• 層級不要超過三層——太深客戶找不到，搜尋引擎的抓取優先度也較低
• 一個商品可以屬於多個分類嗎——例如同時在「新品」與「上衣」
• 是否需要標籤或篩選——依價格、品牌、材質、適用對象篩選

篩選功能是常被低估的項目。 商品數量多時它很有價值，但每一個可篩選的條件都需要在商品資料中建立對應欄位，開發成本不低。

分類與層級的規劃原則見網站選單怎麼設計。

商品欄位清單

建議在規格書中直接列出每項商品需要記錄什麼：

• 基本：名稱、編號、價格、圖片、簡介、詳細說明
• 商務：原價與售價、成本、上下架時間、排序
• 物流：重量、材積、是否可超商取貨
• 規格：各規格軸線與選項
• 其他：規格表、注意事項、相關商品、常見問答

欄位越多，後台建檔的工作量越大。 這不只是開發成本，也是你自己上架商品時的時間成本。

建議只保留真正會用到的欄位——沒有人會填的欄位，做了也是浪費。

庫存的管理層級

• 不管庫存——接單後再調貨。最單純
• 單一庫存——一個數字，賣完就下架
• 依規格分別管理——每個組合各自一組
• 多倉庫或多門市——複雜度最高，通常需要串接

選擇取決於實際營運方式。如果庫存的真實來源是 ERP 或門市系統，網站端就不該是主資料源，應該同步過來，見資料同步該怎麼設計。

一個實務建議

如果商品結構還在調整，或不確定多規格是否真的需要，可以先用單一商品的方式上線——把「藍色 M 號」當成一個獨立商品。

缺點是商品列表會變長、管理較繁瑣；優點是系統單純、上線快、成本低。

等實際營運一段時間，確認確實需要規格管理，再升級。但發包時要先確認架構支援日後升級，否則就是重做。

三種模式，本質不同

要做電商，市面上有三條路。它們的差別不只是價格，更關鍵的是「網站是不是你的資產」。

開店平台

初期投入最低、上線最快，適合先驗證商品賣不賣得動的階段。

要注意的三件事

• 交易抽成——除了月租，部分平台按營業額抽成。營業額成長後，這筆費用可能超過自建的成本
• 資料能不能帶走——商品可能可以匯出，但會員、訂單、累積的內容與搜尋排名通常帶不走
• 功能受限——特殊的價格規則、報表需求、串接需求可能做不到

試算的方法

年成本 = 月租 × 12 + 年營業額 × 抽成比例

用你預估的營業額算三年，再跟自建的建置費加年度支出比較。營業額越高，兩者的差距越明顯。

套版電商

一次性付費、使用現成的電商版型與功能。適合需求標準、預算有限的情況。

限制在於版面與功能都在既有範圍內。如果你的商品結構或營運流程比較特殊，可能會發現「這個做不到」。

自建系統

依需求開發，功能與版面都不受限。適合：

• 營業額已達一定規模，抽成成本可觀
• 有特殊的價格規則或營運流程
• 需要與 ERP、POS 深度串接
• 品牌形象要求高
• 希望完整掌握會員與訂單資料

成本最高，但買到的是資產與自主權——可以搬遷、可以持續擴充、資料完全掌握在自己手上。

怎麼選

依階段判斷通常最實際：

1. 還在驗證市場——用開店平台，快速上線，先確認賣不賣得動
2. 營運已穩定、抽成開始有感——評估轉換的時機
3. 有明確的特殊需求——自建

轉換的成本要先知道

從平台搬到自建，需要處理：

• 商品資料匯出與重新整理
• 會員資料能不能帶走——這是最大的變數
• 網址結構改變，需要完整的轉址對應
• 重新申請金流與物流
• 搜尋排名可能需要重新累積

網址變動的處理見網站改版或更換網域，SEO 排名怎麼保住。

混合的做法

不一定要二選一。常見的組合：

• 官網自建、通路上平台——官網經營品牌與內容，同時在大型購物平台開店
• 先平台後自建——用平台起步，穩定後轉自建，平台保留為通路之一

要注意多通路的庫存同步，否則會超賣。這通常需要串接或人工控管。

不要只比初期價格

評估時建議算三年總成本，並且問一個問題：三年後如果停止付費，你手上還剩下什麼？

這一題的答案，往往比報價單上的數字更能決定該選哪一條路。

相關的成本觀念見便宜網站的隱藏成本。

電商報價為什麼特別難估

一般企業網站的報價，可以依「幾個單元、幾套系統」來拆解。電商與預約系統則多了一層：營運流程的複雜度。

同樣是購物車，處理「單一商品、貨到付款、宅配到府」與處理「多規格、多付款方式、多物流、會員分級價、優惠券、電子發票、ERP 串接」，是完全不同的工程。

報價通常包含的項目

1. 視覺設計——首頁、商品列表、商品明細、購物車、結帳流程各自需要設計
2. 商品管理系統——依欄位數量與規格複雜度計價
3. 購物車與結帳流程
4. 訂單管理系統——狀態流轉、查詢、出貨作業
5. 會員系統——依是否分級、是否有點數而異
6. 金流串接——通常每一種付款方式各自計價
7. 物流串接——同上
8. 運費規則——規則越多成本越高
9. 電子發票
10. 外部串接——ERP、POS、CRM
11. 報表
12. 政策頁面與內容建置

第六與第七項是常見的誤解來源。 「串接金流」不是一個項目——信用卡、ATM、超商、行動支付通常各自需要工時，報價時應該逐項列出。

八個放大成本的因素

這張表可以直接拿來自我檢視：如果你的需求大多落在右欄，就要有預算較高的心理準備。

三個常被低估的項目

一、退貨與退款流程

規劃時大家想的是怎麼把東西賣出去，很少想到怎麼收回來。但退貨一定會發生，而且牽涉庫存回補、金流退款、發票折讓、運費歸屬——是完整的一套流程，不是一個按鈕。

二、後台的出貨作業

訂單進來之後，實際要做的事很多：篩選待出貨、批次列印、建立託運單、更新狀態、通知客戶。這些「不起眼」的功能，是每天都要用的。

後台好不好用，直接決定營運的人力成本。 驗收時務必實際操作整個出貨流程。

三、商品資料建置

兩百項商品、每項有多規格與多張圖片，光是建檔就是可觀的工時。要先決定由誰輸入——自己做是內部人力成本，請廠商做是另計的費用。

年度營運成本

電商的持續性支出比一般網站多：

• 網域、主機、SSL——見網站每年的固定支出有哪些
• 金流手續費——按每筆交易收取，是長期的主要成本
• 物流費用
• 電子發票的加值服務費
• 維護方案
• 主機規格可能需要升級——流量與資料成長後

金流手續費要計入商品定價，低客單價的商品尤其要注意。試算方式見金流的費用怎麼算。

分階段的建議

電商特別適合分階段，因為很多需求要實際營運之後才知道是否真的需要。

第一階段：能賣東西

• 商品管理、購物車、結帳
• 一到兩種付款方式
• 基本的訂單管理與出貨
• 必要的政策頁面

第二階段：依實際需要擴充

• 更多付款與物流選項
• 會員分級、促銷機制
• 外部串接
• 進階報表

常見的情況是：原本以為必要的功能，營運三個月後發現根本沒用到；反而是當初沒想到的需求變得迫切。

發包時要確認架構支援日後擴充，並直接問「這個功能日後要加，需要重做嗎」。

判斷報價合理性的方法

請廠商逐項說明報價的組成。願意拆解到「哪幾種付款方式、哪些運費規則、商品有無多規格」的，通常是真的評估過需求；只給一個總價的，多半是估的。

報價單的看法見網站架設費用怎麼算。

電商的驗收不能只看畫面

一般網站驗收看的是頁面與功能，電商還多了一層：錢與貨的流程必須真的跑得通。

而且很多問題只在真實交易時才會浮現——測試環境正常，正式環境參數沒切換；信用卡沒問題，超商付款的流程沒測過。

一、走完整的下單流程

不是只按到「送出訂單」就結束，而是走到客戶收到貨為止：

1. 瀏覽商品，切換規格，確認價格與庫存正確
2. 加入購物車，調整數量
3. 結帳，填寫資料，確認運費計算正確
4. 完成付款
5. 確認訂單狀態自動更新為已付款
6. 確認客戶收到訂單確認信
7. 確認店家收到新訂單通知
8. 後台建立出貨、更新狀態
9. 確認客戶收到出貨通知與物流單號
10. 確認庫存正確扣除

第五步最常出問題。 如果付款結果不會自動回寫，就要人工核對每一筆，量大時必然出錯。

二、每一種付款方式都要測

這是最常被省略的一項。信用卡測過了，就以為其他也沒問題——但非即時付款的流程完全不同。

• 信用卡——即時完成，測試導回與背景通知
• ATM 虛擬帳號——測試取號、入帳後的狀態更新
• 超商代碼——同上
• 貨到付款——測試訂單流程與後續對帳

兩個關鍵測試

• 付款完成後立刻關閉視窗——訂單狀態還會正確嗎？這一題能測出串接是否只依賴前台導回
• 逾期未付款——訂單會自動取消嗎？庫存會釋放嗎？

相關問題見金流物流串接的常見問題。

三、正式環境的參數切換

這是造成實際損失最常見的疏忽。

開發時使用測試環境的參數，上線前必須全部切換為正式參數。沒切換的結果是：客戶以為付了錢，實際上錢進到測試環境，等於沒收到。

上線後務必做的事

用小額真實交易測試一次完整流程，包含退款。 這是唯一能確認正式環境正常的方法。

四、退貨與退款流程

一定要測，因為一定會用到：

• 後台如何建立退貨
• 庫存是否正確回補
• 退款如何操作——在網站後台還是金流後台
• 發票的作廢或折讓
• 部分退貨時運費如何計算
• 客戶是否收到通知

「原本滿額免運，退貨後未達門檻怎麼辦」是最常爭議的情況，規則要先確定並測試。

五、後台出貨作業的實測

請實際負責出貨的同仁操作一次，而不是由老闆或工程師代測。要確認：

• 能否快速篩選待出貨訂單
• 能否批次處理
• 列印的格式是否符合實際作業
• 手機能不能看訂單
• 臨時要改地址或品項時怎麼處理

後台好不好用，決定日後每天的人力成本。 這一項在驗收時多花一小時，可以省下往後數年的時間。

六、多規格與庫存的邊界測試

• 庫存剩 1 件時，兩人同時下單會怎樣
• 某個規格組合缺貨時，前台顯示是否正確
• 商品下架後，購物車中已有的商品怎麼處理
• 價格調整後，購物車中的舊價格如何處理

這些邊界情況平常不會遇到，但一遇到就是客訴。

七、政策頁面與必要資訊

這些不只是內容，金流申請審核時通常會檢查：

• 公司名稱、統編、地址、聯絡電話
• 購物須知、運費說明
• 退換貨政策與期限
• 隱私權政策
• 商品說明與價格清楚標示

八、試營運的建議

正式對外宣傳前，建議先安排一段試營運：

1. 找幾位同事或熟客實際下單，各用不同付款與配送方式
2. 從手機下單——多數客戶是用手機
3. 完整走完出貨流程
4. 刻意測試退貨
5. 收集操作上的困惑點

試營運能發現的問題，通常比任何檢查清單都多——因為真實使用者會做出你想不到的操作。

上線後前兩週的檢查

• 每天核對訂單筆數與金流後台是否一致
• 確認通知信沒有進垃圾郵件匣
• 留意是否有卡住的訂單
• 觀察客戶在哪一步流失
• 記錄客服接到的問題，找出流程盲點

完整的驗收原則見網站驗收怎麼做。