优秀建站服务商：交付物可以验收但不能被使用时怎样界定缺口
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ac2ca5c91d17.html
📄
优秀建站服务商：交付物可以验收但不能被使用时怎样界定缺口
缺口不在“做没做”，而在“从验收通过到业务可用”之间还差什么。界定方法是：把交付物按“静态合格”和“运行可用”两层分别检查，再看两层之间缺的是配置、数据、权限还是流程。如果缺的是运行条件，验收单应记为“有条件通过”，而不是“已完成”。
两种成立条件：缺运行环境，还是缺使用路径
先区分两种相反情况。第一种：文件、页面、接口都在，但部署环境、域名解析、证书、账号权限没有接通，导致没人能真正打开或登录。第二种：环境已通，但内容、栏目、导航、表单通知、后台操作说明缺失，导致能打开却没法日常使用。
判断依据是“谁在什么条件下能完成一次真实操作”。让非建站方的一名同事，用普通账号走一遍最关键的任务，例如提交一条咨询、发布一篇文章、查看一次订单。若卡在环境，属于第一种；若卡在不知道该点哪里、字段没有说明，属于第二种。
选择依据：若卡点在环境，下一步是补部署与权限清单；若卡点在使用路径，下一步是补操作说明、字段定义和培训。两者不能混在一张验收单里，否则责任方和整改顺序都会错。
用可核对证据区分“合格”与“可用”
验收通过通常只证明静态项达标，例如页面能打开、样式符合设计稿、链接不报错。可用还需要运行证据。可以要求服务商提供或共同确认以下可核对项：
- 在目标环境实际访问一次，记录访问地址、时间、结果；
- 用普通权限账号完成一次发布、提交或查询，记录操作步骤与结果；
- 列出后台各角色的可操作范围，以及哪些操作需要额外授权；
- 说明数据从哪来、存在哪、由谁维护，迁移或备份由谁执行。
这些证据的作用不是追责，而是定位缺口位置。访问失败指向环境；能访问但操作失败指向权限或数据；操作成功但结果不符合预期指向配置或内容规则。
一个注明假设的短例子
假设某服务商交付了企业站，验收单上“页面完成、移动端适配、表单存在”都打了勾。上线后市场同事发现表单提交后没人收到通知。此时不要直接判定“交付失败”，先查三处：通知邮箱是否配置、邮件服务是否接通、提交记录是否写入后台。
若后台有记录但无通知，缺口是通知配置；若无记录，缺口是表单与后台的连接；若两者都正常但邮件进入垃圾箱，缺口在使用约定，需要换通知方式或加白名单。三种原因对应三种整改动作，验收结论也应分别写成“补配置后可用”“补连接后可用”“调整通知方式后可用”。
实施动作：把验收单改成两段式
实际操作可以这样做：把原验收单拆成“交付合格”和“业务可用”两段。第一段保留原有静态检查项；第二段只写三到五个真实任务，每个任务注明执行人、前提条件、预期结果和实际结果。
执行后，若第二段有任务未通过，验收状态改为“有条件通过”，并附一份缺口清单：缺口描述、责任方、整改动作、复验方式。复验只复验未通过项，不重跑全部静态检查。这样做的结果是，下一步动作从“继续扯皮是否交付”变成“按清单补哪一项”，复验范围也被收窄。
例外与边界
有些缺口不属于服务商责任范围，例如客户尚未提供域名管理权限、尚未确定通知接收人、尚未完成内容审核。这类情况应在验收单上标为“待客户条件”，并写明条件满足后的复验方式，而不是计入服务商未完成项。
另一些缺口来自第三方服务，例如邮件送达、短信通道、支付回调。此时可核对的是配置是否正确、日志是否可见、失败时是否有提示，而不是要求服务商保证第三方行为。把可控项与不可控项分开记录，缺口界定才站得住。
最终判断标准可以归纳为一句：验收单证明的是“东西交出来了”，可用性证明的是“有人能按预期用它完成一件事”。两者之间的差额，就是需要被写清楚、被复验的缺口。
