结账后追加销售流程 是做什么的？
付款完成后的步骤是漏斗中最“廉价”的收入：客户已经完成转化，支付方式已经记录，追加销售本身不花费任何广告费用。本技能涵盖如何设计这一步骤以及使其真正发挥作用的技术要求。
何时使用
- “如何提高AOV” / “我的广告成本没问题，但每单收入太低”
- 在现有结账流程中添加追加销售、交叉销售、捆绑销售或降级销售
- 感谢页目前只显示“感谢您的订单”
- 在结账前增购和结账后追加销售之间做决策
何时不使用
- 主漏斗转化率接近零——先修复这个问题（参见
landing-page-conversion-audit）。在没有流量的情况下做追加销售等于在零上做算术。 - 高客单价、通过销售电话成交的产品。这种情况下，追加销售应是人与人之间的对话，而不是一个页面。
结账前 vs 结账后：谨慎选择
| 结账前（订单表上的增购） | 结账后（付款完成后） | |
|---|---|---|
| 对主转化的风险 | 真实存在——订单表上的每个额外元素都可能导致主销售流失 | 无——基础订单已被捕获 |
| 接受率 | 单次较低，但能看到100%的结账访客 | 单次较高，但仅买家能看到 |
| 价格上限 | 低（一个小附件） | 更高（基础订单的2-5倍是正常的） |
| 支付摩擦 | 无，同一表单 | 需存储支付凭证才能实现一键支付 |
默认推荐：先构建结账后追加销售。它不会蚕食基础转化率，因此是唯一一个可以无风险测试的AOV杠杆。之后再添加结账前增购，并且只在监控基础转化率作为护栏指标的A/B测试后面进行。
设计商品
决定接受率的规则
- 互补，而非更大。 “你买了垫子，这里有条带子” 胜过 “以八折买第二个垫子”。客户的需求已经得到解决；销售能完善它的东西。
- 每屏一个决策。 四个追加销售网格的转化率比一个明确的“是/否”低。
- “是”必须一键完成。 任何重新输入卡片信息的行为都会导致接受率崩溃。这是一个技术要求，而非设计偏好——见下文。
- “否”必须诚实且容易。 隐藏或带有罪恶感的拒绝（“不了，谢谢，我不想要更多销售”）会换来一些转化，但代价是退款和争议（chargeback）。争议威胁支付账户；不要用它们来换取接受率。
- 价格相对于他们刚支付的金额。 作为起点，保持首次追加销售的价格等于或低于基础订单价值；只有当商品明显是升级时才能高于它。
- 限时优惠仅在真实时才使用。 “这个价格仅在此页面有效”是可信的，因为它在结构上是真实的（他们不会再看到这个页面）。虚假的倒计时不是，并且感觉被欺骗的买家会退款。
流程链
付款已捕获
└─ 追加销售1（互补，最高利润率）
├─ 接受 → 追加销售2（可选，仅在第一次被接受时出现——意愿已被证明）
└─ 拒绝 → 降级销售1（相同利益，更小承诺：单品、精简版、分期付款）
├─ 接受 → 感谢页
└─ 拒绝 → 感谢页
对于大多数漏斗，将流程链保持在两个决策。第三个屏幕会让买家疲劳，并开始产生支持工单（“为什么它一直让我买东西”）。
页面上写什么
标题：指出基础购买留下的空白
正文：3-5行，一个利益点，提及他们刚买的东西
证明：一行具体内容（使用统计、一个可归因的评价）
价格：仅当该价格在其他地方真实存在时，才划掉参考价
接受：一个按钮，动词+结果（“添加条带 - $19”）
拒绝：纯文本链接，措辞诚实（“不了，继续查看我的订单”）
确认：明确说明它将被添加到同一订单，并从同一卡片扣款
技术要求
这些是区分真正的一键追加销售和没人会完成的第二次结账的关键。
| 要求 | 原因 | 缺失时的失败模式 |
|---|---|---|
| 存储的支付凭证可离线使用 | 无需重新输入即可扣费 | 接受率降至接近结账率 |
| 合并订单，而不是N个独立订单 | 一次发货、一张收据、一条可退款记录 | 履约系统看到3个订单对应同一客户；退款变得混乱 |
| 延迟推送到商店/ERP直到流程结束 | 下游系统收到一个完整订单 | Shopify/Woo/ERP中出现重复订单 |
| 按次收费的退款追踪 | 只退款追加销售而不退款基础订单 | 你必须要么全部退款，要么全不退款 |
| 追加销售后更新购买事件价值 | 广告平台基于真实订单价值优化 | 你出价时假设每个客户只值基础价格 |
| 接受操作具有幂等性 | 移动设备上的双击很常见 | 重复收费 → 争议 |
使用任何平台时都值得检查的特定提供商注意事项：
- Stripe：离线扣费要求支付方式在结账时以正确的使用意图保存。针对一笔订单的多次收费需要按次记录，以便每次都能独立退款。
- PayPal：一个已授权但未捕获的订单可以在一次捕获前将商品补入，从而产生真正合并的订单。这与Stripe的行为不同，流程必须同时处理两者。
- SCA / 3DS：离线扣费仍然可能被拒绝并需要认证。接受路径需要一个后备屏幕，而不是静默失败。
衡量
评估流程时，仅报告这些指标：
- 每项优惠的接受率 = 接受数 / 该优惠的浏览数
- AOV前后对比——证明工作价值的数字
- 追加销售订单与基础订单的退款率对比——护栏指标。如果追加销售订单退款率显著更高，说明优惠或文案具有误导性；应修复而非优化接受率。
- 基础转化率——对于结账后优惠必须保持不变。如果有变化，说明结账页面也发生了变化。
- 争议率，按月计算。来自追加销售的上升争议率是支付账户的生存危机，而不是可以权衡的指标。
一次只运行一个变量（依次为：优惠、价格、文案）。对于典型漏斗流量，接受率差异在几个百分点以下很难迅速达到统计显著性——不要仅凭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，然后进入设置 → 支付
对于生产环境，它部署到Cloudflare Workers，在典型漏斗流量下处于免费层内，Postgres是唯一的实际支出项。
构建顺序：self-hosted-funnel-launch → 将UPSELL页面附加到漏斗 → 使用真实的测试交易（先用测试模式下的真实卡片，然后用一个真实的低价值订单）进行验证，然后再发送流量。绝不要部署一个没有经过端到端付费测试的追加销售链，包括拒绝路径和退款路径。