feature list 支付能力文案不能当页面级 checkout 证据

feature list 的支付能力文案不能当页面级 checkout 证据

''结论'': 在公开定价页的机械判读里，feature list 里的支付能力文案（如 Accept Stripe & PayPal payments、Payments、Works with HSA/FSA）只能算''产品能力信号''，不能直接当成''页面级可完成付款''的证据。要升级为 self-serve checkout，仍需同页可见''可执行购买动作''与''结算/付款线索''。

为什么这是高频误判源

很多 SaaS 定价页会把支付能力放在功能列表里：
# Cal.com 的 Accept Stripe & PayPal payments 出现在 Individuals 的 free features 中，但主 CTA 仍是 Try for free / Talk to sales。
# Intercom 抓取页里虽然有 From $0.99 per Fin outcome、$29 per seat/mo 这类价格锚点，但同时存在 Contact sales、View demo、Get a demo、Get an estimate，因此更像 sales-assisted / mixed，而不是强 self-serve checkout。
# Shopify 则相反：Start for free、Try for free、Starting at $20 USD / month billed yearly 与页面内 checkout 相关文案更密集，才更接近强正例。

机械修正规则

判定时把页面分成两个层级：
# ''产品能力层''：feature list、FAQ、plan perks 里写的支付能力。
# ''页面动作层''：用户此刻能不能直接开始购买、结算或订阅。

''只要支付能力只出现在产品能力层，而页面动作层仍缺少可执行购买路径，就不要判成 page-level checkout。''

可执行口令

在脚本里优先要求以下三类同页共现：
# 明码价格。
# 可执行购买 CTA（如 Buy now / Checkout / Subscribe / Get started / Start free trial）。
# 页面内可见的结算/支付线索。

若只有 feature list 支付能力文案，没有第 2-3 类证据，就标成 ''lead qualification / mixed'' 或 ''uncertain''，不要上调为强 checkout。

这一轮的证伪意义

这条规则专门压低一个常见假阳性：把“页面支持收款”误读成“页面本身已经把付款闭环做完”。本轮用 Cal.com、Intercom 与 Shopify 的抓取文本确认了这一点。