乌海建站公司：交付物可以验收但不能被使用时怎样界定缺口
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3fdf6d62ec37.html
📄
乌海建站公司：交付物可以验收但不能被使用时怎样界定缺口
结论先说：如果页面能打开、后台能登录、文件也齐，但业务人员仍然无法用它发布内容、接收咨询或完成下单，那么缺口通常不在“有没有交付”，而在“可用性验收”这一层。此时不应把问题笼统归为质量差，而要先区分三种缺口：功能可用性缺口、内容可运营缺口、环境可迁移缺口。三者的责任归属和补救代价完全不同。
先判断是哪一种“不能用”
“不能用”至少可以分成三类，每类的证据和下一步动作都不一样。
- 功能可用性缺口：表单提交后没有到达指定邮箱或后台，支付流程中断，会员登录后权限错误。这类问题通常能通过一次完整业务路径复现。
- 内容可运营缺口：页面能看，但编辑无法新增栏目、替换图片会破版、文章发布后不进入列表。这类问题要在真实编辑账号下操作才能暴露。
- 环境可迁移缺口：本地或演示环境正常，换到正式服务器后伪静态失效、上传目录无写权限、定时任务不执行。这类问题与代码质量未必相关，更多是部署配置差异。
把这三类混在一起谈，最常见的后果是：需求方认为“东西没做完”，交付方认为“功能已经实现，是你们不会用”。双方都没有错，但验收清单里缺少了“真实角色完成真实任务”这一项。
两种常见做法：补验收还是扣尾款
发现交付物可验收但不可用时，需求方通常面临两个选择：要求对方补一轮可用性验收，或者直接以“未达到使用条件”为由扣减尾款。两者都合理，但成立条件不同。
选择补验收的条件：缺口集中在配置、权限、内容初始化、部署说明这些可修复项；双方对“可用”的定义还能对齐；项目还没进入大规模内容录入阶段。此时补验收的代价较低，通常一次联合走查加一份修复清单就能推进。
选择扣尾款的条件：缺口涉及核心业务路径无法完成，且合同或需求确认书中已经写明该路径属于交付范围；对方拒绝在合理期限内修复；或者继续修复会引入新的费用争议。扣款不是目的，它的作用是让“未完成部分”在商务上被单独计价。
需要提醒的是，扣尾款并不能替代验收记录。如果没有留下可复现的失败步骤和对应需求条款，扣款很容易变成情绪化对抗，反而拖慢修复。
一个会推翻上述结论的反例
假设合同里只写了“交付网站前后端源码及部署文档”，没有写“保证编辑可独立发布内容”，也没有约定正式环境由谁配置。此时业务人员无法发布内容，可能并不构成交付方违约，而是需求方在采购时漏掉了运营可用性条款。这种情况下，正确动作不是扣款，而是先补一份变更单，把“编辑培训、栏目配置、发布流程走查”作为新增工作单独确认。
这个反例说明：判断缺口是否成立，不能只看“能不能用”，还要看“当初有没有约定谁来保证它能用”。约定越模糊，越应该先补约定，而不是先追责任。
把缺口写清楚：一次可执行的走查
与其争论“算不算交付”，不如用一次走查把缺口变成可核对的条目。建议按真实角色走一遍，而不是按功能菜单逐项点开。
- 用编辑账号完成一次“新增内容—上传图片—发布—在前台找到它”的完整操作，记录在哪一步失败。
- 用访客身份完成一次“填写表单—提交—确认对方能收到”的路径，记录失败发生在提交、通知还是存储环节。
- 如果涉及交易，用测试账号走一遍下单到订单可查，记录中断位置。
- 把每一步的失败现象、复现步骤、对应需求条款写在同一张表里，再区分“必须修复”和“可另行报价”。
走查结果会直接影响下一步：如果失败集中在配置和权限，优先要求修复并复验；如果失败集中在未约定的运营支持，转为变更协商；如果核心路径在约定范围内仍无法完成，才进入扣款或更换供应商的讨论。
修复之后怎样确认缺口真的关闭
修复完成不等于缺口关闭。有效的复验应当由原操作角色在正式环境重走同一路径，而不是由交付方在演示环境截图证明。复验通过后，把走查表、修复记录和最终确认结果一起归档，作为后续维护和二次开发的起点。若复验仍失败，下一步就不是继续口头沟通，而是按未完成项重新协商交付范围与付款节点。
