先给结论:演示里出现的功能若依赖额外付费模块,你无法从演示画面直接确认自己买的套餐是否包含它。正确做法是把演示拆成“基础能力”和“模块能力”两份清单,再向对方索取一份书面范围说明,写明模块名称、是否单独计费、缺失时页面会退化成什么样。拿到这份说明后再决定保留、改写需求还是退出,而不是凭演示时的观感下判断。
演示环境通常按最理想的配置搭建:所有模块都开着,数据量小,网络和账号权限都处于最佳状态。这种环境下的顺畅,只能证明“这套系统在满配时能跑通”,不能证明“你选的套餐能跑通”。
一个反直觉的现象是:演示越流畅,越容易掩盖模块边界。因为模块被打开时,前端往往不会提示“此功能由某某模块提供”,你看到的是一个完整页面,而不是一堆可拆分的零件。等到你自己搭建时,某个按钮点不动、某个页面空白或提示升级,才会暴露真实范围。
这里需要区分两种解释。第一种是功能确实属于付费模块,你的套餐没买;第二种是功能本身在基础版里,只是演示时用了另一套配置或模板。两者外观相似,但处理方式完全不同。区分它们不能靠再问一遍“这个包含吗”,而要靠可核对的证据。
看演示时不要只记“好看不好看”,而要边看边记两列内容。
记录时用具体动作描述,而不是用感受描述。把“看起来很流畅”改写成“点击筛选后,列表在不刷新页面的情况下更新”。这样后续核对时,对方无法用模糊话术绕开。
拆分完成后,挑出模块列里你真正需要的三项,逐项追问三个问题:这个功能由哪个模块提供;该模块是否包含在当前报价内;如果不包含,缺少它时页面会变成什么样。第三个问题最关键,因为它决定了你能否接受降级方案。
口头回答容易在交付时被重新解释。更稳妥的动作是:把整理好的两份清单发给对方,请对方以文字形式逐项标注“包含”“不包含”或“需另购”,并注明依据的是哪份套餐说明或合同附件。
这份说明不需要复杂格式,一段文字加一张对照清单即可。关键是它必须能对应到具体条款或产品说明,而不是一句“一般都包含”。如果对方只愿意口头保证,你可以把这次沟通记录整理成文字回执,请对方确认,作为后续比对的基准。
这个动作的结果会直接影响下一步:如果书面说明里模块边界清晰,你可以据此调整需求,把非核心模块换成基础能力可实现的替代方案;如果对方始终无法给出明确边界,说明范围本身不稳定,继续投入沟通的时间成本会上升。
确认范围之后,通常面临三种选择,它们适用的前提并不相同。
三种选择没有优劣之分,只有前提是否成立。不要因为已经投入了沟通时间就强行保留,也不要因为一个模块不包含就全盘否定——先看这个模块是否在你的核心流程上。
假设你在演示中看到商品列表可以按价格、颜色、库存三个条件同时筛选,你觉得这正是需要的。演示结束后你记录了动作:“勾选三个条件,列表即时更新,无需刷新。”
核对时对方回复:基础版支持按单一条件筛选,多条件组合筛选由“高级筛选模块”提供,该模块不在当前报价内。此时你有两个可核对的点:第一,基础版的单条件筛选是否够用;第二,如果不够用,缺少多条件筛选时用户需要多跳几次页面才能找到商品。
如果单条件筛选已经能覆盖主要浏览路径,改写需求是成立的;如果多条件筛选是核心转化路径,而模块价格可接受,保留原需求也成立。这个判断依据来自书面说明和你的业务流程,而不是演示时的即时感受。
无论最终选择保留、改写还是退出,都建议把确认结果落到一条可复查的记录里:哪些功能属于基础、哪些属于模块、模块是否计费、缺失时的降级表现。下一次沟通或验收时,直接拿这份记录对照,而不是重新回忆演示画面。
如果对方提供了官方站点或应用内的套餐说明页面,应在该页面内核对渠道和条款,不要依赖第三方转述或截图。范围确认的价值不在于一次问清所有细节,而在于让后续每一次判断都有同一份基准可以对照。