网站服务公司：交付物能验收却不能用时怎样界定缺口
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e7cdc1937e84.html
📄
网站服务公司：交付物能验收却不能用时怎样界定缺口
先给有条件的结论：如果验收单上的每一项都能勾选，但业务人员仍然无法完成一个真实任务，缺口通常不在“有没有交付”，而在验收标准只覆盖了存在性，没覆盖可用性。此时不要直接判定对方违约，也不宜自行补做，而应把“不能用”拆成可核对的失败点，再对照合同里的功能描述与验收条件，判断这是范围外需求、环境差异，还是交付物本身未达到约定状态。只有能定位到具体环节，后续的返工、补款或换供应商才有依据。
先分清三种“不能用”，它们的责任方不同
“验收通过但不能用”常被当成一个笼统问题，实际上至少有三类，处理方式差别很大。
- 功能存在但路径不通。例如后台能登录，却无法完成一次完整的发布流程。这通常属于交付物未达到可用状态，责任在服务方。
- 功能可用但不符合实际业务。例如表单能提交，但字段与真实审批流程不匹配。这更可能是需求阶段没有说清，属于范围界定问题。
- 功能可用但运行环境不同。例如在测试环境正常，接入正式域名或正式数据后失效。这要看环境准备由谁负责，不能默认是服务方的问题。
区分方法很直接：让实际操作的人复现一次失败，记录从哪一步开始偏离预期、报什么错、缺什么数据。能稳定复现且与业务无关的失败，偏向第一类；只有特定角色或特定流程才失败的，偏向第二类；只在正式环境出现的，偏向第三类。这一步做完，再谈缺口才有意义。
用可核对的证据替代“我觉得不好用”
判断缺口需要能被第三方复核的证据，而不是主观评价。可以准备一份最小核对表：
- 任务名称与操作角色，例如“编辑发布一篇带图文章”。
- 预期结果，写成可观察的状态，例如“前台出现该文章且图片可见”。
- 实际结果，包括页面提示、错误信息或卡住的步骤。
- 发生环境，测试环境还是正式环境，用的哪套账号与数据。
- 与合同或需求文档的对应条目，指明哪一条被违反或未覆盖。
这份记录的作用是让“不能用”变成可讨论的条目。假设某个筛选功能在验收时只测了默认条件，上线后按业务常用条件筛选却返回空结果，那么缺口应写成“该筛选在指定条件下无结果”，而不是“筛选功能不可用”。前者能定位到实现或数据问题，后者只会引发争论。
反例：什么时候“能用”也不该算缺口
有一种情况会让上面的结论失效：如果合同只约定了交付某个页面或某项功能，而“不能用”的原因是业务方后来新增了流程、换了第三方系统，或要求与原有后台打通，那么这属于新增范围，不是原交付的缺口。此时强行要求服务方免费补齐，反而会让责任判断失焦。判断依据是时间线：需求是在验收前就明确写入，还是验收后才提出。前者可主张返工，后者应按变更处理，先确认工作量与费用，再决定是否继续合作。
下一步动作：先冻结争议点，再决定返工还是变更
拿到上述记录后，建议按一个顺序推进。先书面列出可复现的失败点，标注属于功能未达约定、需求未覆盖还是环境问题。然后要求服务方针对“功能未达约定”的部分给出修复说明与复测方式；对“需求未覆盖”的部分单独评估是否走变更。复测时用同一份核对表，由实际操作人确认，而不是只看服务方截图。如果修复后仍无法完成核心任务，且失败点集中在约定范围内，才考虑扣减尾款或更换供应商。这个动作的意义在于：把“能不能用”的争论，转化为“哪一条约定没有被满足”的可验证问题，后续每一步都因此有了依据。
