功能多不等于覆盖广
功能清单长，意味着每项都浅：能生成但不能回写，能问答但不能留痕。为什么危险：采购按清单验收，一线按链路使用，落差在第一周就出现。怎么纠正：把验收改成走完一条完整链路，缺环即视为未交付。
垂直不等于只做一件事
垂直产品的边界在行业，不在任务数量，一套运输管理产品可覆盖调度、对账与异常处理。为什么常被误判：演示只看单点功能。怎么纠正：按岗位列任务，看它覆盖几个岗位的日常，而不是数左侧菜单。
选型不是一次性决策
平台会更换、厂商会合并、业务会调整。把选型当终局，容易接受过长的合约束缚与深度的数据绑定。怎么纠正：按主平台加专用工具的组合架构设计，保留数据回流层与替换窗口，签约时同步考虑退出。
单价低不等于成本低
订阅单价之外还有集成、迁移、培训与运维；垂直产品单价常更高，但集成工作量小。为什么容易算错：报价单只覆盖许可与实施，内部工时不在表内。怎么纠正：把内部人力按角色折算进同一张三年表。
大厂不等于低风险
大厂的产品线会调整，收购与停服并不罕见；垂直厂商规模小，但专注度高、响应快。怎么判断：看近两年迭代记录、客户留存与停服迁移条款，而不是只看品牌。边界是关键系统仍要留一套可替换方案。
适用与不适用
适合谁
- 正在评审选型方案、听到过类似说法的决策者
- 被功能清单和低价方案说服过的采购团队
不适合谁
- 已经完成选型、只差签合同的团队
典型场景
某能源企业的选型会上，综合平台的功能数量更多，报价也低。评审组把两个方案放进同一张链路图：综合平台在审批回写上缺环，垂直产品在报表上要另配工具。会后按组合方案调整，用垂直产品承载核心业务，争论收敛。
可执行步骤
- 把五个误区改写成提问清单，逐条问候选方与内部一线使用者和业务管理者
- 按岗位列出日常任务，标出哪些必须闭环、哪些可以由工具拼接补齐
- 用一条完整的业务链路做验收，而不是对着功能清单逐项去勾选确认
- 把内部的集成、培训与运维工时按角色折算进同一张三年成本表之中
常见坑
- 按功能清单验收，交付后发现关键链路缺回写，只能追加开发，责任归属也扯不清，返工无从追溯。
- 因为垂直这个标签就排除了能覆盖多岗位的产品，短名单过窄，议价空间随之变小，选择余地小。
- 合同一签就是五年，中途业务调整想换方案，一看迁移成本很高，只能将就着继续用下去。
自检与验收清单
- 验收是否以完整链路为单位，而不是功能条目
- 岗位任务清单是否覆盖了一线的日常操作场景
- 三年成本表是否包含了内部的集成与运维工时
- 合同是否保留替换窗口、退出与迁移协助条款
常见问题
垂直产品能覆盖多个岗位吗？
取决于行业集中度。业务链条紧密的行业，一套垂直产品常能覆盖调度、执行与对账多个岗位；跨行业需求仍要靠综合平台或集成补齐。判断方法是列出岗位任务看覆盖率。
组合方案会不会更难维护？
会多一层集成维护，但换来了各环节的深度与替换弹性。做法是限定组合数量、统一身份与权限、把接口纳入监控；组合超过三个系统时，集成本身就成为新负担，需要重新评估。
小厂商的风险怎么控？
用合同与架构一起控。约定数据托管、停服提前通知期与迁移协助义务，关键数据定期回流自有存储。别把全部入口押在一家小厂商身上，重要系统保留一套可切换的备选。