SaaS 对比表里的空白，不能直接打成“不支持”

软件选型表最容易误导人的地方，往往是一个红叉。采购人员没有在价格页找到“数据导出”，就填成“不支持”；另一家在首页写了“开放平台”，便得到一个勾。两格看似可比，实际上一格是查阅结果，另一格是宣传表述，谁也没有回答团队能否完成工作。

做 SaaS 对比时，应把“未查到”“已确认不提供”和“验证可用”分开。空白是一项待确认任务，不能直接成为淘汰产品的依据。

先把比较对象写到套餐和使用条件

同一软件的入门版、企业版和单独付费模块可能有不同功能。先记下产品名称、套餐、计费方式、地区版本和查阅日期，再填功能项。如果销售演示使用的是企业试用账号，不能把演示结果直接写进入门套餐那一列。

比较“导出”也要具体到用途：是管理员导出全量业务记录，还是普通成员下载自己看到的列表？是否包含附件、历史记录和字段定义？一次只能下载当前页，与可以按选定范围导出，不是相同能力。

用四种状态替代仓促的勾叉

• 资料未确认：当前查阅页面没有足够说明，记录查过哪些页面，列出要向供应商询问的问题。
• 资料说明支持：注明功能对应的套餐和限制，附文档位置；这还不是本团队的测试结果。
• 已验证可用：记录测试账号权限、操作步骤、样本范围和结果，避免把小样本成功推广到所有情况。
• 确认不满足：写清不满足哪条具体要求，以及判断来自厂商确认还是实际测试，不概括成“产品不行”。

例如，假设 A 的公开文档没有说明附件批量导出，B 的企业版文档明确包含这一能力。此时可以说 B 有更明确的公开依据；不能说 A 没有，更不能据此算出一个“功能领先百分比”。这是教学场景，不是对任何真实产品的测评。

把演示改成一项能复查的工作任务

让两家供应商面对同一个任务，比各自播放最熟练的演示更有用。以交接业务记录为例，可以准备一组无敏感信息的测试数据，要求指定角色导出记录，再由另一位同事核对字段、附件关联和时间信息。测试前约定成功条件，测试后保留失败项和补充条件。

供应商承诺“可以定制”时，单独记录实施工作、费用范围、责任和交付条件，不把尚未交付的能力与现成功能并列为同一种支持。如果工具暂时无法试用，就诚实停在“资料确认”，不要补写使用感受。

需要校准对比文案时，可参考光算的竞品对比页事实与未知项核对方法。其中“未找到可核实资料不等于对方没有”的原则，同样适用于软件采购表；机械产品的参数例子不必照搬到 SaaS。

结论写成适合什么任务，而非谁处处第一

最后一列建议写“对本项目的影响”。某项导出能力对准备迁移的团队可能是硬条件，对暂时只做内部试点的团队则未必立即关键。先保留原始事实，再说明取舍，下一位接手者才能分清哪些是产品差异，哪些是当时的业务优先级。

购买前复查入选方案的最新套餐和未决问题。若关键能力仍未确认，把决定标为有条件通过，并明确谁负责补齐；不要因为表格必须交稿，就让未知项悄悄变成结论。