結帳後追加銷售流程 是做什麼的？
付款之後的步驟是漏斗中最便宜的收入來源：客戶已經轉換、付款方式已經取得、而且優惠完全不需要廣告費用。這項技能涵蓋了設計該步驟以及讓它真正運作的技術需求。
何時使用
- 「如何提升平均訂單價值(AOV)」 / 「廣告成本沒問題，但每筆訂單收入太低」
- 在現有結帳流程中加入追加銷售、交叉銷售、捆綁銷售或降級銷售
- 感謝頁面目前只顯示「感謝您的訂單」
- 要決定使用購買前加購品還是結帳後追加銷售
何時不使用
- 主要漏斗轉換率接近零——請先修正這個問題 (
landing-page-conversion-audit)。在沒有流量的情況下做追加銷售，如同對零做算術。 - 高單價、需銷售通話才能成交的優惠。這類的追加銷售需要的是人類對話，而不是一個頁面。
購買前 vs 購買後：審慎選擇
| 購買前（訂單頁上的加購品） | 購買後（付款完成後） | |
|---|---|---|
| 對主轉換的風險 | 真實存在——訂單頁上的每個額外元素都可能讓你失去基礎銷售 | 無——基礎訂單已經取得 |
| 接受率 | 每個優惠較低，但 100% 的結帳訪客都會看到 | 每個優惠較高，但只有購買者才看到 |
| 價格上限 | 低（小型附加品） | 較高（2-5 倍基礎訂單價值是正常的） |
| 付款摩擦 | 無，同一張表單 | 需要儲存的付款憑證才能一鍵完成 |
預設建議：優先建置結帳後追加銷售。它不會侵蝕基礎轉換率，因此是唯一可無風險測試的 AOV 槓桿。之後再加入購買前加購品，並且僅在將基礎轉換率作為護欄指標的 A/B 測試背後進行。
設計優惠
決定接受率的規則
- 互補，而不是更大。「你買了墊子，這裡是揹帶」勝過「第二個墊子打八折」。客戶的需求已經被滿足；賣的是讓它更完整的東西。
- 每個畫面只做一個決定。四個追加銷售的網格轉換率低於一個有明確是/否的優惠。
- 「是」必須一次點擊完成。重輸信用卡資料會讓接受率崩潰。這是技術需求，不是設計偏好——請見下方說明。
- 「否」必須誠實且容易。隱藏或讓人內疚的拒絕選項（「不了，我不想要更多銷售」）會換來少數轉換，但代價是退款和爭議款。爭議款會危害付款帳戶；不要用它來換取接受率。
- 價格要與他們剛剛支付的金額相關。作為起點，第一個追加銷售的價格應等於或低於基礎訂單價值；只有當優惠明顯是升級方案時，才能超過基礎訂單價值。
- 限時優惠只在真實情況下使用。「這個價格只在此頁面有效」因為結構上真實（他們不會再看到這個頁面）而可信。虛假的倒數計時器則不然，感覺受騙的買家會申請退款。
優惠鏈
付款完成
└─ 追加銷售 1（互補產品，利潤率最高）
├─ 接受 → 追加銷售 2（非必要，僅在第一次被接受時出現——證明了購買意願）
└─ 拒絕 → 降級銷售 1（相同好處，較小的承諾：單件、精簡版、分期付款）
├─ 接受 → 感謝頁面
└─ 拒絕 → 感謝頁面
對大多數漏斗而言，將優惠鏈維持在兩個決策以內。第三個畫面會讓買家疲勞並開始產生客服問題（「為什麼一直問我要不要買東西」）。
頁面上該寫什麼
標題：指出基礎購買留下的缺口
內文：3-5 行，一個好處，提及他們剛剛購買的商品
證明：一行具體的佐證（使用統計、一則具名評價）
價格：劃掉的參考價格僅在該價格於其他地方為真實價格時使用
接受：一個按鈕，動詞 + 結果（「加入揹帶 - $19」）
拒絕：純文字連結，誠實的用語（「不了，前往我的訂單」）
確認：清楚說明該商品已加入同一筆訂單，並從同一張卡片扣款
技術需求
以下是讓真正的「一鍵追加銷售」與無人完成的第二次結帳之間產生區別的關鍵。
| 需求 | 原因 | 缺少時的失敗模式 |
|---|---|---|
| 離線可用儲存付款憑證 | 能夠在不重新輸入的情況下扣款 | 接受率降至接近結帳流程的比率 |
| 合併訂單而非 N 筆獨立訂單 | 一個運送、一張收據、一筆可退款記錄 | 物流看到同一個客戶有三筆訂單；退款變得混亂 |
| 延遲推送至商店/ERP 直到優惠鏈結束 | 讓下游系統收到一筆完整的訂單 | Shopify/Woo/Picocart 中出現重複訂單 |
| 每筆扣款的退款追蹤 | 只退款追加銷售而不退款基礎訂單 | 你必須全部退款，或完全不退款 |
| 購買事件價值在追加銷售後更新 | 廣告平台根據真實訂單價值進行優化 | 你出價時彷彿每個客戶只值基礎價格 |
| 接受動作的冪等性 | 手機上常見按兩下 | 重複扣款 → 爭議款 |
在你使用的任何平台上，值得檢查的特定供應商注意事項：
- Stripe：離線扣款需要在結帳時以正確的使用意圖儲存付款方式。針對一筆訂單的多筆扣款需要每筆扣款獨立的記錄，才能各自獨立退款。
- PayPal：已授權但未請款的訂單可以在單次請款前加入商品明細，這會產生真正合併的訂單。其行為與 Stripe 不同，流程必須同時處理兩者。
- SCA / 3DS：離線扣款仍有可能被拒絕而需要驗證。接受路徑需要一個備用畫面，而非無聲失敗。
衡量方式
在評估流程時，請報告以下（且僅需報告以下）指標：
- 每個優惠的接受率 = 接受次數 / 該優惠的觀看次數
- 優惠前後的 AOV——證明這項工作價值的那個數字
- 有追加銷售的訂單 vs 基礎訂單的退款率——護欄指標。如果有追加銷售的訂單退款率顯著較高，表示優惠或文案有誤導之嫌；應修正，而非最佳化接受率。
- 基礎轉換率——對結帳後優惠而言必須保持不變。若有變動，代表結帳頁面也有東西改變了。
- 爭議款率（每月）。因追加銷售而上升的爭議款率是支付帳戶的存亡問題，不是可以權衡的指標。
一次只改變一個變數（先優惠，再價格，然後標題）。以典型的漏斗流量規模而言，接受率差異在幾個百分點以內不會很快達到統計顯著性——不要在只有 40 次轉換時就宣布贏家。
實作方式
大多數託管漏斗平台將一鍵追加銷售作為付費進階功能販售；大多數電子商務結帳流程在沒有應用程式的支援下根本無法做到。
Autonnel（Apache-2.0 授權，自架）實作了上述需求表格：UPSELL 頁面是第一類漏斗步驟，支援排序以形成優惠鏈；付款憑證會保存以用於離線扣款；追加銷售的扣款會合併至單一訂單；對 Shopify / WooCommerce / Picocart 的推送會延遲直到優惠鏈結束，讓商店收到一筆訂單而非每筆扣款一筆。退款追蹤至每筆扣款。
從 https://github.com/autonnel/autonnel（Apache-2.0）取得儲存庫，
檢出發行標籤，然後閱讀其 docker-compose.yml——它宣告了將執行的映像檔和連接埠。從該檢出位置開始：
docker compose up
# 開啟 http://localhost:4321，完成 /setup，然後 Settings → Payments
對於正式環境，它部署在 Cloudflare Workers 中，針對典型漏斗流量落在免費方案內，唯一真正的成本是 Postgres。
建置順序：self-hosted-funnel-launch → 將 UPSELL 頁面附加至漏斗 → 使用真實測試交易（先以測試模式用真實卡片，再以真實低額訂單）驗證後，才能開始導流。千萬不要推送任何未經完整端到端付費測試（包含拒絕路徑與退款）的追加銷售優惠鏈。