Shopify 雖然是代管平台，上線後仍有維護工作。品牌會更新商品與活動、安裝 App、調整分析、串接 ERP，也會遇到瀏覽器和第三方服務變化。維護合約應先約定哪些問題由誰看、多久回應、如何判斷完成，不能只預買一包用途模糊的工時。
談合約前先盤點現有系統。單純 Theme 商店、深度客製 Theme 與 Headless storefront，需要的技能、監控和事件處理都不同。
先分開保固、維運與新需求
保固處理原交付範圍未符合驗收條件的瑕疵，應有期限與提報方式。維運包含相依更新、健康檢查、小型設定、問題診斷和已知系統的例行照護。新增頁型、促銷機制、整合或設計改版，則屬於需求開發。
三者若混在同一工時池，品牌會覺得修 bug 還要付兩次，供應商則可能把新需求當成無限保固。合約附上例子，比抽象定義更有用：文字更正、App 衝突、瀏覽器回歸、加入新金流，各自走哪種流程。
回應時間不等於解決時間
SLA 要先定義事件等級。正式站無法結帳、部分付款方式失敗、後台報表錯誤和一般版面調整，商業影響不同。每個等級可約定受理時間、初步診斷時間、更新頻率和可用的暫時處置。
解決時間往往受 Shopify、App、金流或 ERP 供應商影響，無法一律保證。比較實際的承諾是多久開始調查、何時提供已知範圍、誰負責對外追蹤，以及是否有降級或回復方案。
工時池要能看見消耗方式
月費方案應寫明包含時數、最小計價單位、未用完是否保留、超時費率、哪些角色共用，以及估算由誰核准。每月報告至少列出需求、工時、狀態、變更檔與剩餘額度，不應只有一個總數。
若每月需求不穩定，可採按次估價加固定健康檢查；若活動密集、需要熟悉品牌的常態團隊，retainer 才可能降低每次重新理解的成本。選擇應依工作型態，而不是把維護視為建置案的固定附加品。
把第三方與版本責任寫清楚
Shopify API 有版本生命週期，自訂 App 和 Headless 前端需要追蹤棄用與升級。Theme 也可能因 App embed、extension、瀏覽器或平台更新出現回歸。合約要列出監看哪些公告、檢查頻率、升級是否含在月費，以及重大改版如何另行估算。
第三方 App 的 bug 不一定能由維護團隊直接修正，但仍可負責重現、蒐集證據、聯絡供應商與提出替代方案。若只寫「第三方問題不負責」，事故發生時品牌會在多個窗口之間轉來轉去。
正式環境要有基本可觀測性
至少確認網站可用性、前端錯誤、關鍵 API、付款與訂單流程由誰觀察。Headless 還需涵蓋部署失敗、快取、CMS、搜尋和相依套件。告警不是越多越好；每一個告警都應有接收人、判斷方式和處理文件。
活動前可安排變更凍結與演練，活動中約定值班窗口，活動後檢查訂單、庫存、付款與資料同步。這類事件支援通常要另列時段與費用，避免把 24 小時待命藏進一般月費。
品牌必須保有交接能力
程式庫、Shopify organization、網域、部署、CMS、分析與 App 帳號要用品牌可管理的身分建立。供應商取得最小必要權限，離場時有停權與憑證輪替清單。文件至少包含架構、發布、環境變數名稱、整合窗口、已知風險和回復步驟。
先跑三個月再校正容量
新系統剛上線時，內容調整、教育問題和真實流量下的缺陷較集中，不能直接代表長期月均需求。合約可先設定三個月觀察期，分類記錄事故、營運需求、改善與新功能，再依實際分布調整工時和技能配置。
若大部分時間都花在同一類手動修補，應提出根因與永久改善方案。維護合約的目標不該是讓重複問題穩定收費，而是讓系統更可預期，把工時移到有價值的改善。
每季也應刪除不再需要的存取權、App 與告警。減少系統表面積，往往比增加更多監控更能降低事故機會。
續約前回顧三件事：實際工時花在哪裡、重複事故是否減少、哪些問題應透過重構或流程調整永久處理。可把維運費和平台、App 一起放進 Shopify 建置費用拆解的三年成本表，再決定固定月費、按次支援或內部接手哪一種較適合。