企業商店上線驗收工作簿：從商品與結帳測到配送復原

企業商店能展示商品，不代表已經可以對員工或客戶開放。真正的上線條件，是正確的人能依核准權益選到正確商品，付款與訂單狀態可以核對，配送出錯時也有具名負責人接手。這份企業商店上線驗收工作簿，把商品、資格、無障礙、結帳、配送與復原串成可執行測試，協助臺灣團隊用證據決定全面開放、限縮開放，或暫緩上線。

下載繁體中文工作簿，先看清楚適用邊界

下載企業商店上線驗收工作簿繁體中文版，版本二〇二七之〇四。檔案是可開啟的試算表，包含使用說明、測試案例、結果、缺失與簽核五張工作表，提供四十二項原創流程案例。全部結果預設為未執行，沒有預填客戶測試成果，也沒有任何自動上線功能。

版本名稱用於二〇二七年規劃，實際編製及資料查核日期為二〇二六年十月三十日。它不是對未來平台功能的保證，不是完整資安稽核，也不是無障礙認證。真正上線前，仍要重新確認採用平台、付款安排、配送地區及適用要求。企業的雇主、稅務、隱私、法律與採購判斷，不能由工作簿代替。

工作簿刻意把「可交人工決策」與「核准」分開。加權通過率只用來摘要進度，不能沖淡重大缺失。四十二項案例都必須具備有效通過紀錄，關卡才可能顯示可交人工決策；決策負責人、日期與證據是另一組欄位。有人填入姓名，也不代表系統已開放、供應商已承諾，或原本不適用的配送範圍突然獲准。

先保留一份空白母版，再依版本、受眾及市場建立執行副本。若某項案例不適用，應修改測試計畫、說明原因、調整公式範圍並取得負責人同意，而不是把未執行改成通過。舊版本與原始缺失應另存，讓之後的檢查人知道範圍為何改變，以及哪一個決策對哪一個版本有效。

---

先定義臺灣站點要開放什麼，再安排測試

用一段明確文字定義此次上線：誰可以使用、誰出資、有哪些商品、可送到哪裡、採用什麼幣別與付款方式、由誰出貨、客服何時接手。員工額度商店、公開品牌商品店與客戶選禮入口，外觀可能相似，資格與金流邏輯卻不同。測試團隊若只收到網站連結，沒有這份定義，就無法判斷眼前行為究竟正確還是錯誤。

專案負責人核准體驗範圍，人資確認員工資格與權益，財務提供核准的總額、退款及差額負擔規則。商品營運負責品項、規格、庫存與替代方案，資訊團隊負責身分與串接行為，隱私及資安人員確認測試資料界線，客服負責例外說明。小團隊可以由同一人兼任多個角色，但不能讓必要責任變成沒有姓名的「相關單位」。

臺灣站點應使用經同意的代表性地址測試，而不是只測公司總部地址。先向實際物流夥伴確認支援區域與欄位規則，再檢查樓層、室號、長地址、姓名符號與電話修正。不要自行假設離島、特殊區域或所有地址格式都被支援。測試的工作是證明約定規則被正確執行，不是替供應商創造原本不存在的配送承諾。

優先使用合成身分與受控資料。真實員工住址出現在截圖，不代表適合貼到所有人都能讀取的缺失表。證據應記錄必要欄位、存取人員、保存期間與刪除方式；需要完整資料治理設計時，可參考企業贈禮資料治理指南。本工作簿接著驗證經核准的設定是否真的生效，不能只把政策文件當成執行證據。

若平台有正式支援的測試環境與付款測試方式，應先使用它們。必要的正式環境小額測試，也要先有授權、金額上限、取消方式及出貨隔離措施。小額並不等於無風險，一筆訂單仍可能扣款、保留庫存或觸發倉庫工作。測試前把這些副作用列清楚，才能在失敗後知道應查哪一筆紀錄。

---

六類案例要連成同一段顧客旅程

四十二項案例依六個範圍各安排七項，屬於原創營運測試架構，不是產業基準，也不是所有企業商店的完整測試數量。特殊商品、多層核准、客製串接或額外配送限制，都可能需要新增案例。增加列數時，必須同步擴充公式與資料驗證範圍，再做邊界測試，不能只把新列放在表格下方便視為納入計算。

上線驗收範圍、主要負責人與應留存的證據

商品測試除了正常頁面，也要打開停用商品的舊連結、切換尺寸顏色、模擬缺貨及變更受眾。導覽列找不到商品，不代表直接網址或舊購物車不能下單。最後要比較送出的訂單規格，而不只是畫面上的商品照片。圖片正確、訂單規格錯誤，仍然是會造成交付問題的缺失。

資格測試必須包含合格、不合格與剛被撤銷資格的身分。再用識別資料相近的兩個測試帳號，確認額度與訂單沒有混用。已登入工作階段是否失效，要依核准的撤銷規則判斷，而不是臨時猜測。重複兌領與購物者嘗試管理操作，也應保留實際遭拒紀錄；成功登入只證明通過身分驗證，不等於取得正確權益。

配送則應沿著個別訂單明細追蹤，包含拆單、部分送達、退貨與補寄。「已出貨」可能只代表部分品項離開倉庫，不能把其餘未交付品項一起標成完成。要求訂單、付款、庫存、出貨與客服案件有穩定關聯，但不要預設所有供應商都提供相同欄位。欄位不足時，先約定可行的核對方法與責任，再開始測試。

---

無障礙與輸入錯誤要查當下版本，不套用舊標章

全球資訊網協會的網頁內容無障礙指引第二點二版可作為技術參考，這次查閱的建議標準版本日期為二〇二四年十二月十二日。工作簿中的七項無障礙案例只涵蓋部分流程，不能據此宣稱完整符合指引、取得認證，或滿足特定法律義務。實際範圍仍須由具備相關能力的人員確認。

臺灣規劃另有時間點要注意：數位發展部無障礙網路空間服務網的公告發布於二〇二六年六月八日，說明修正版規範認證標章檢測將自同年十一月三十日起實施。資料查核日仍在該日期之前，因此不能把新制寫成已經實施，也不應把舊版檢測條件不加說明地套到二〇二七年規劃。實際申請或驗收時，應依當時適用版本與範圍另行確認。

上述公告與企業內部上線驗收是不同事項。工作簿不是標章申請表，也不判定每一家私人企業商店的法律適用。它要求團隊把採用標準、測試環境與判定依據寫清楚，避免以模糊的「無障礙已完成」代替具體證據。規範更新時，先找出哪些案例受影響，再修改版本與重測計畫，不必捏造全面完成的結論。

實測應包含只用鍵盤完成主要旅程、焦點顯示與順序、對話框開關、資訊性圖片替代文字、錯誤提示、放大與窄畫面，以及購物車狀態變更的傳達。由專業人員選擇實際瀏覽器、裝置及輔助科技組合，並把組合記在證據裡。另一個人應能依記錄重現，而不是只看到一張沒有操作順序的截圖。

協會的表單輸入驗證教學也提醒，協助使用者修正輸入與安全控制不是同一件事。清楚的必填標示及可理解錯誤通知，不能取代伺服器端驗證。測試因此要分成使用者能否找到問題，以及後端是否阻止不合法操作兩條路徑；兩者都需要證據，不能只看畫面上出現紅框。

本地姓名、地址或電話在修正後，應確認有效內容沒有被不必要地清空或破壞。若錯誤與配送服務商規則有關，客服說明要指出可行的修正方式，而不是把責任丟回使用者。這些是營運測試建議，不是對所有姓名格式或地址均可受理的承諾；可接受範圍仍以已核准並實測的服務設定為準。

---

正確填寫結果，讓加權數字不能掩蓋缺失

執行前先審查嚴重度。工作簿預設權重三代表重大、二代表高，經負責人審查的一般案例可用一。這些數字是編輯提供的初始分類，不是風險發生機率，也不是財務損失估計。若團隊決定更改，應在執行前記錄理由；不要在測試失敗後調低權重，讓結果看起來更接近上線條件。

有效通過必須有通過結果、證據位置、測試人與有效試算表日期，還要有支援的權重及唯一對應案例編號。公式會排除不合條件的紀錄，但無法判斷證據內容是否誠實、是否屬於同一版本，或測試人是否真的做了指定操作。因此審查者仍須打開證據，比對驗收條件、執行順序與實際觀察，不可只讀取計算出的數字。

加權通過率用有效通過案例的權重除以全部案例權重。未解重大案例數要一起看，因為其意義不是另一種平均分數。即使其他案例都通過，一個重大失敗仍會保留阻擋；而關卡要求全部案例有效通過，所以少了一項一般案例的證據，也不會因整體比率漂亮而自動放行。百分比是摘要，完整紀錄才是決策依據。

每筆缺失應有固定編號、對應案例、重大與否、狀態、負責人及結案證據。只填了一部分的缺失列會維持未解決。真正結案要保留原失敗、修正內容與複測，而不是把狀態改為已結案便結束。若同一問題影響多個案例，應說明關聯與回歸範圍，避免只修最容易重現的一條路徑。

禁止把舊執行的通過欄整欄貼到新副本，也不要覆蓋公式來追求綠燈。跨試算表軟體使用時，應重新確認計算與關卡顯示。可另外建立驗證副本，用合成資料測試全數通過、重大失敗、缺少證據與未結缺失等邊界，但驗證副本不能混入真實營運證據。測過工作簿公式，不等於測過企業商店。

證據參照應盡量使用穩定位置與版本，而不是會失效的個人暫存連結。缺失描述至少包含前置條件、操作、預期結果、實際結果與影響範圍。附上畫面時，也要補充看不到的付款或出貨狀態。若證據只有「看起來正常」，審查者仍無法知道是否存在重複交易或權限洩漏，應退回補證而非代為推定通過。

---

假設決策一：員工登入正常，私人商品卻洩漏

假設一家臺灣企業要開放員工商品商店，採用經確認支援的單一登入方式。以下是示意案例，不是客戶故事，也不代表任何特定平台必然提供某種串接。人資交付核准員工群組與額度規則，資訊人員交付身分設定，商品營運提供員工專屬目錄與不得混用的其他受眾目錄。測試人先確認這些輸入都對應同一個上線版本。

團隊建立合格、不合格與剛撤銷資格的合成身分。合格者可以登入並選購正確商品，但撤銷者重新開啟原工作階段後，仍看得到私人價格。若只做一筆正常訂單，這個問題不會出現。測試人記錄身分類別、政策版本、工作階段操作順序及實際露出的內容，不使用真實員工個資作為公開範例。

專案負責人面臨全面開放、限縮群組或延後三個選項。若缺失讓排除身分仍能進入，縮小邀請名單並未修好邊界，只是降低進站量。全面開放則把未驗證的風險擴大。延後會增加溝通與時程成本，卻能讓團隊先修正一個已經被證明存在的控制失效，因此不能只拿原定日期當成選擇依據。

資訊與商店設定負責人先查明核准規則要求立即撤銷，還是允許明確的工作階段到期行為，再依授權修正。若原規則本身含糊，先由負責人釐清，測試人不能自行降低要求。修正後重跑原路徑、全新登入拒絕與合格使用者正常訂購，並檢查額度是否仍正確，因為存取與權益可能共用部分設定。

驗收需要修正後版本、撤銷身分無法執行禁止操作的證據、合格身分仍可完成流程的證據，以及具名決策。原缺失留在紀錄中，不因已經修好便刪除。若資訊團隊只能提出設定截圖，尚未完成實測，狀態仍是待複測，不是通過；如果結果不明，也不能藉由再次登入成功一次就認定所有路徑都安全。

若單一登入的必要能力暫時不可用，改用另一種受支援登入方式是一個新的架構與政策決策。負責人要比較身分可信度、管理工時、使用者阻力與資料需求，再核准變更。它不是讓測試案例消失的捷徑。變更後應重新檢查資格、額度、撤銷與客服流程，並讓員工清楚知道實際使用方式。

這個案例也說明限縮試行的真正價值：它應讓已經成立的邊界在較小範圍中得到實務回饋，而不是用較少使用者掩蓋已知控制失效。試行成功的接受證據應包括指定群組、限制仍有效、例外有負責人，以及明確擴大條件。沒有這些條件，小規模開放只是規模較小的未驗證上線。

---

假設決策二：跨市場結帳逾時，配送也出現例外

再假設同一方案涵蓋三個核准市場，其中一項商品對某目的地停用，測試時也刻意模擬承運交接失敗。財務提供各路徑核准的總額與退款處理，物流提供實際支援地區與限制，商品人員準備經核准替代品。這些都是案例設定，不是把臺灣的付款、稅務或配送規則直接套到其他市場。

第一個問題出現在結帳逾時：使用者沒有收到確認，付款服務商的結果卻還不明。若立刻重按送出，可能產生重複扣款或重複訂單。測試人保留原請求與交易識別資料、觀察時間及畫面狀態，交由指定技術負責人先查明原交易。測試的驗收點是可安全核對與復原，而不是重試到某一次成功為止。

查明交易後，接著核對訂單與倉庫紀錄。承運交接失敗必須留下具名例外，不能因訂單已建立就標成送達。客服演練應說明已知狀態、下一次確認時間與允許的退款或補寄路徑，不承諾尚未確認的到貨日。補寄若獲核准，必須連回原訂單並檢查是否已有退款，避免兩種補償在不同系統中各自發生。

停用品項則要測直接網址、舊購物車，以及加入商品後變更配送國家。畫面警告不等於真正阻止交易，最後提交仍接受受限品項就沒有通過。商品負責人可以提出替代方案，但使用者選擇、價差與額度差異都要符合核准政策。不能只在倉庫端換貨，卻讓前端與訂單紀錄繼續顯示原商品。

此時可以延後所有市場，也可以只開放已驗證的配送路徑。限縮開放能保留部分使用價值，但前提是排除規則在承諾交易時確實生效，且使用者能清楚理解。它增加客服複雜度，也可能減少可選商品；全面延後比較容易維持一致溝通，卻會推遲本來已準備好的市場。應比較實際控制與營運能力，不能預設哪一種一定較佳。

若採限縮方案，驗收證據至少要有目的地邊界測試、付款與訂單核對、可運作的例外處理及對限縮範圍的明確核准。被排除路徑留下負責人、缺失與重測條件。之後承運測試成功，也不代表自動擴大上線權限；應由負責人閱讀新證據，確認商品、付款、客服與配送都符合新範圍後，再記錄新的決定。

遇到查不到結果的交易，應把不確定性寫成具體狀態：哪一筆交易、最後確認時間、已做的查詢、尚缺哪一方回覆，以及由誰何時再查。這比「付款有問題」更能支援接班。不要用重新建立訂單來躲開原紀錄，也不要把等待第三方回覆誤報為測試通過。原交易能否對後續操作造成影響，是是否可繼續的關鍵。

---

演練停止接單，保留已承諾交易的處理能力

上線前可用一項刻意保留的重大失敗做桌上演練。確認誰能停止受影響範圍的新接單、誰發出說明、誰核對已付款或已出貨訂單。關閉商店入口並不會讓既有金流或配送義務消失。復原計畫應區分停止新承諾、維持既有服務與修正錯誤，不能只寫一句「全部回復」就當作有處理方式。

出現重大缺失時的處理順序

暫停受影響的上線範圍，保存版本、原請求識別資料與觀察狀態，指派具名負責人。先查明不確定交易，再決定是否重試。完成授權修正後，複測原案例及受影響的相鄰流程，重新取得人工決策。保留原失敗；必要依賴仍不可用時，不得把案例標成通過。

最後決策前，逐項確認以下事項：

• 上線範圍、排除受眾與目的地已經寫清楚。
• 工作簿與證據對應同一版本及設定。
• 每個通過及結案紀錄的證據均已開啟檢視。
• 沒有未解重大缺失、不明交易或無人負責的例外。
• 客服、升級聯絡及停止接單方式均可執行。
• 授權決策包含範圍、日期、負責人與下次檢查條件。

如果專案是替換既有商店，還需另外處理舊系統狀態、餘額、庫存及網址移轉。可以搭配企業商店遷移指南規劃切換。本工作簿檢查的是變更後的購物旅程，不能替代切換前後帳務與資料核對；兩份工作應互相引用證據，而不是各自宣稱涵蓋全部風險。

每季及重大商品、資格、付款、配送或串接變更後，重新檢查案例。已完成執行應保留日期與版本，不要永遠覆寫同一個共享檔。測試覆蓋、營運準備度、使用率與商業成效也要分開報告。這份範本沒有量測營收提升或員工滿意度，不能把通過率轉述為未經證實的投資報酬。

交接時可讓沒有參與修正的人抽查幾筆證據，但抽查不應被誇大成完整驗收。檢查人應能找到案例、實際結果、修正與決策的連結，並指出仍不清楚的地方。若接班者需要靠口頭回憶才能知道是哪一次執行，表示記錄還不夠可追溯，應在擴大上線前補足版本與關聯，而不是再增加一個沒有用途的狀態欄。

---

把上線決策建立在可重現的證據上

測試環境與正式環境也要分開記錄。在測試環境拍到正常畫面，只能證明該環境當時的行為，不會自動證明正式環境有相同設定。決策前應比較商品版本、受眾規則、付款模式、目的地限制及相關設定識別資料；若有差異，明列哪些證據仍可沿用、哪些操作需要重新獲准測試。不要為了比較方便，把真實付款憑證或個人地址複製到工作簿。

另一個常見問題是把需求變更寫成修正完成。例如某地配送失敗後，團隊決定先不開放該地，這可以是合理的範圍調整，卻不是已修復配送的證據。原缺失仍應保留，另記新的限制、限制如何被測試、誰核准以及何時重新考慮。測試者不能自行改寫期待結果，讓原本失敗的操作在沒有實質改變下變成通過。

正式交接還需要一段清楚的覆蓋說明，列出實際測過的瀏覽器、裝置、輔助科技、付款方式與配送路徑，並交代選擇依據。依據可以是核准受眾與實作支援範圍，沒有資料時就不能捏造流量比例。相似路徑成功不等於未測路徑成功；如果選擇限縮上線，必須證明未測路徑無法接受新訂單，並準備客服可以使用的明確說明。

保留證據不代表無限期保存所有資料。負責人應依既有政策設定閱覽對象、保存期限與必要的遮蔽方式，讓之後的檢查仍能辨識測試版本及結果，又不暴露不必要的收件資訊。當原始記錄依法或依政策移除時，也應留下允許保存的決策摘要與來源識別，避免讓舊的通過狀態失去可解釋性。具體保存義務仍由企業自己的隱私與法務負責人判斷。

有用的產出不是一張看起來全部通過的表，而是從核准範圍、測試操作、觀察結果、缺失修正到人工決策的連續紀錄。範圍較小但邊界明確、失敗可復原的商店，可能比只完成展示卻一次開放所有市場更容易負責任地營運。選擇應依實際證據與團隊處理例外的能力，而不是只依預定日期。

若正評估Giftpack 公開說明的企業商店與商品服務，可用同一份測試矩陣討論實作範圍，逐項確認受眾控制、付款安排、庫存責任與各目的地配送能力，不能自行推定串接或合規保證。透過企業方案討論把已核准的需求轉成執行計畫時，企業仍保有上線決定及法律、稅務、隱私與雇主責任。