美妝品牌談購物網站架設，很容易先比較版型、平台月費或首頁風格，最後才發現真正卡住上線的是商品資料：同一款保養品有容量、組合與限定包裝，倉庫有自己的品號，行銷又用另一套名稱；一旦規格、庫存與訂單對不起來，再漂亮的網站也會把問題放大。
所以，SHOPLINE、Shopify 還是客製網站，不應只用功能數量決定。更實用的判斷方式是先畫出「商品建立到售後完成」的資料流，再看現成平台能否承接；只有在流程或整合需求明確超出平台能力時，才評估客製。這樣能避免為了少數例外重做整站，也避免選了平台後才發現核心營運無法落地。
先建立商品主檔，不要直接從商品頁開工
商品名稱只是顧客看到的一小部分。發包前可先用試算表建立主檔，每個可銷售單位至少整理：內部 SKU、前台名稱、規格選項、售價、庫存單位、重量、出貨限制、圖片、成分與使用說明。若組合商品會拆成多個庫存品，也要寫清楚扣庫規則。
Shopify 官方的 Variants 說明 將尺寸、顏色等選項組合視為不同 variant，且庫存可依 variant 管理；也能以 metafield 保存更專門的欄位。這不表示每個品牌都必須使用 Shopify，而是提醒需求方：規格不是商品描述中的一段文字，而是會影響選購、庫存與出貨的結構化資料。
對保養品而言，可把容量、香氣或包裝做成規格，但肌膚需求、系列與成分用途較適合當分類或篩選欄位。若把所有資訊都做成規格，組合數會快速增加；若全部只寫在文案裡，後台又無法篩選與批次更新。發包前應先用幾個真實商品測試資料模型，而不是等全站切版後才補欄位。
金流、物流與電子發票要用同一張訂單狀態圖
「有串金流」並不等於訂單流程完成。至少要列出待付款、付款成功、付款失敗、備貨、已出貨、已送達、取消、退貨與退款等狀態，並定義每次狀態變更的來源、通知對象與可執行動作。
例如付款成功後是否立即開立電子發票，取消訂單時是否同步作廢；超商未取件怎麼回到客服待辦；物流單建立失敗能否重送；部分退款是否要留下原訂單與明細。這些都是金流串接、物流串接與電子發票串接共同依賴的規格，不能交給三個外掛各自決定。
驗收時不要只做一筆成功付款。至少測試付款失敗後重試、付款成功但通知延遲、缺貨取消、分批出貨與部分退款。每個情境都要核對前台顯示、後台狀態、庫存、通知與對帳資料是否一致。
售後不是客服備註，而是可追蹤流程
Shopify 官方 Returns and exchanges 將 refund、return 與 exchange 分成不同動作，也說明退貨可包含寄送指示、追蹤，以及驗收退回商品後退款。這個區分很適合拿來檢查自建網站需求：客人提出申請、商品寄回、倉庫驗收、退款完成，本來就是不同狀態。
美妝與個人用品是否接受退換、在什麼條件下處理，應由品牌依商品、銷售地區與適用規範確認；網站團隊不應自行推定。系統面則要讓客服看見原訂單、申請原因、照片、物流與退款紀錄，並確保政策頁和實際操作一致。若規則會調整，也要保留訂購當時適用的版本，避免後來修改文字卻無法還原交易脈絡。
案例：同是美業，資料模型可以完全不同
「MORIÉ 森澄研」是保養品電商官網案例，站內以分類、系列與肌膚需求形成三種篩選軸，36 支商品各有獨立頁面，並串起收藏、購物車與結帳。這種架構的重點不是頁面數，而是每件商品必須有一致欄位，篩選結果與商品內容才不會互相矛盾。
「衡嶼身心養護」則把三間館所、六項療程的預約與日常選物、電子心意卡放在同一站。服務時段、實體商品與電子商品的履約方式不同，若硬塞進同一種庫存與出貨流程，後台會很難操作。案例說明，複合商模的購物網站應先分清楚每種品項如何交付，再設計共同購物車。
發包前交付這四份資料
第一份是商品主檔與欄位定義；第二份是訂單狀態圖，含失敗與人工處理；第三份是金流、物流、發票及倉儲的系統邊界；第四份是售後情境與權限矩陣。廠商應依這些資料回覆哪些功能由平台提供、哪些靠外掛、哪些需要客製，以及外部服務異常時如何處理。
最後用真實商品與完整訂單情境驗收，不只確認按鈕能不能按。當商品、庫存、付款、履約與售後共享同一套狀態定義，購物網站才會是可長期營運的系統，而不是上線後仍靠人工對表的展示櫥窗。
