关于 post-purchase-upsell-flow
这项技能为营销人员提供购买后加购流程的设计与实施指导，涵盖报价呈现、一次点击支付、订单合并及效果衡量。
主要功能
- 01比较购买前加购与购买后加购
- 02设计加购与降价方案链路
- 03规划报价页面文案
- 04说明支付与订单技术要求
- 05衡量接受率、客单价与退款
适用场景
- 01为现有结账添加购买后加购
- 02改善每笔订单收入
- 03检查加购支付和退款流程
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/post-purchase-upsell-flow确认已加载。
详细介绍
购后加售流程
付款后的步骤是销售漏斗中成本最低的收入来源：客户已经完成转化，付款方式也已记录，而且无需花费广告费。这项技能涵盖如何设计这一步，以及让它真正奏效的技术要求。
适用场景
- “如何提高客单价”／“我的广告成本没问题，但每笔订单的收入太低”
- 为现有结账流程添加加售、交叉销售、捆绑销售或降价销售
- 感谢页目前只显示“感谢您的订单”
- 在购前加购和购后加售之间做选择
不适用场景
- 主销售漏斗的转化率接近零——先解决这个问题（
landing-page-conversion-audit）。没有流量时做加售，结果仍然是零。 - 高客单价、通过销售电话成交的商品。此类加售靠的是人工沟通，而不是页面。
购前与购后：审慎选择
| 购前（订单表单上的加购） | 购后（付款后） | |
|---|---|---|
| 对主转化率的风险 | 确实存在——订单表单上每增加一个元素，都可能让你失去一笔基础订单 | 没有——基础订单已经成交 |
| 接受率 | 每个商品的接受率较低，但 100% 的结账访客都能看到 | 每个商品的接受率较高，但只有买家能看到 |
| 价格上限 | 低（小额附加品） | 较高（基础订单金额的 2～5 倍很常见） |
| 付款阻力 | 无，使用同一表单 | 需要保存付款凭据才能实现一键购买 |
默认建议：先构建购后加售。它不会蚕食基础转化率，因此是唯一可以无风险测试的客单价杠杆。之后再添加购前加购，并且只有在 A/B 测试将基础转化率作为护栏指标监测时才这么做。
设计优惠
决定接受率的规则
- 提供互补品，而不是更大的同类商品。“你买了垫子，这是配套的绑带”胜过“再买一张垫子，享受 8 折优惠”。客户的需求已经得到满足；要卖的是能让这件商品更完整的东西。
- **每个页面只做一个决定。**四个加售商品组成的网格，转化效果不如一个明确的“是／否”选项。
- **点击一次即可接受。**任何要求重新输入银行卡信息的步骤都会拉低接受率。这是技术要求，不是设计偏好——详见下文。
- **拒绝选项应坦诚且方便。**隐藏拒绝选项或用内疚感诱导拒绝（“不用了，谢谢，我不想再买东西”），或许能多带来几笔转化，却会增加退款和拒付。拒付会威胁支付账户；不要为了提高接受率而冒这个险。
- **价格应与刚才支付的金额相称。**作为起点，首次加售价格应不高于基础订单金额；只有优惠明确属于更高档升级时，才可以超过这个金额。
- 仅在确实限时的情况下使用限时优惠。“此价格仅在此页面有效”可信，因为它在结构上确实如此（客户不会再看到这个页面）。虚假的倒计时器则不可信；感觉受骗的买家会申请退款。
加售链
Payment captured
└─ Upsell 1 (complementary, highest-margin)
├─ accept → Upsell 2 (optional, only if the first was accepted - willingness is proven)
└─ decline → Downsell 1 (same benefit, smaller commitment: single unit, lite version, payment plan)
├─ accept → thank-you
└─ decline → thank-you
对大多数销售漏斗来说，加售链最多安排两次决策。第三个页面会让买家感到厌烦，也会开始引发支持工单（“为什么一直让我买东西？”）。
页面文案
Headline: names the gap the base purchase left open
Body: 3-5 lines, one benefit, referencing what they just bought
Proof: one specific line (usage stat, one attributable review)
Price: struck-through reference price only if that price is real elsewhere
Accept: one button, verb + outcome ("Add the strap - $19")
Decline: plain text link, honest wording ("No thanks, continue to my order")
Confirmation: state clearly that it is added to the same order and charged to the same card
技术要求
以下要求决定了它是真正的一键追加销售，还是一个没人会完成的二次结账。
| 要求 | 原因 | 缺少时的失败模式 |
|---|---|---|
| 可在非会话状态下使用的已保存付款凭据 | 无需重新输入即可扣款 | 接受率会降至接近结账转化率 |
| 合并订单，而非 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
# open http://localhost:4321, complete /setup, then Settings → Payments
在生产环境中，对于典型的漏斗流量，它会部署到 Cloudflare Workers 免费套餐中，Postgres 是唯一实际产生费用的项目。
构建顺序：self-hosted-funnel-launch → 将 UPSELL 页面添加到漏斗 → 使用真实测试交易验证（先用测试模式下的真实银行卡，再进行一笔低金额的真实订单），然后再导入流量。未经完整端到端付费测试（包括拒绝路径和退款）的追加销售链，绝不要上线。