结论先行:文档交付型供应商并非不能用,但接口必须从“交付物验收”改成“可执行状态验收”。也就是说,你买的不是一份方案,而是一组能被你的团队或第三方直接执行的资产。如果合同里只写“提供推广计划文档”,而没有写清文档必须包含哪些可操作字段、由谁在什么系统里执行、执行结果如何回传,那么规模化后一定会出现例外:单个页面照做有效,批量执行就失控。
常见情形是:供应商给出一份推广计划,包含栏目结构建议、内容主题方向、页面标题写法、内链思路。你拿其中一个栏目试做,效果看起来成立,于是决定推广到全站。结果第二批、第三批执行时,问题集中出现——不同编辑对同一份文档的理解不一致,标题写法被自由发挥,内链规则在深层页面失效,没人能判断某次改动是“按计划执行”还是“偏离计划”。
这时有两种解释,必须先分开。
文档停留在策略层,没有落到字段层。比如只写“标题要包含核心词”,但没写核心词从哪来、长度边界、重复时如何处理、由谁审核。人读得懂,机器和批量流程读不懂,于是每次执行都要重新做一次人工判断。
即使文档足够细,如果没有约定执行方和回传方式,文档仍只是参考资料。供应商交完文档就结束,你的团队执行后没有结构化结果返回,供应商也无法基于结果迭代下一版。双方各自持有半张图,规模化时必然对不上。
不要靠感觉判断,用下面这组可观察证据区分:
假设一个场景:供应商文档写了“重点栏目页标题需优化”。你让两名编辑各处理十个页面,结果一人改了标题,一人只调整了描述,且都没有记录改了哪些页面。此时差异来源不是编辑能力,而是文档没定义“优化”对应哪个字段、哪个值范围,也没定义回传。这就是两种解释同时存在,但接口缺失是更靠前的原因。
针对只交文档不实施的供应商,接口应拆成三层,每层都有明确的交付状态。
文档必须能映射到具体字段。用页面标识、字段名、建议值或规则、优先级、例外条件这五个列来约束。供应商不需要登录你的系统,但必须让这五列可以被你的执行方直接填写。缺少例外条件,规模化时就会把不该套用的页面一起改掉。
明确谁执行、在哪个环节执行、执行前需要什么确认。常见取舍是:让供应商远程指导你的编辑执行,还是由你的编辑独立执行、供应商只做抽查。前者沟通成本高但偏差小,后者效率高但要求字段层足够细。选择依据不是供应商强弱,而是你的执行团队是否稳定、是否具备按字段操作的能力。
执行后必须回传结构化结果,至少包括:已处理页面清单、未处理页面及原因、实际改动与建议值的差异。回传不是形式,它决定供应商下一版文档能否收敛。没有回传,文档只会越写越厚,例外越来越多。
先做一次小批量试运行:从文档中选一个栏目,要求供应商把该栏目拆成字段层清单,你的执行方按清单处理,并回传差异。结果会出现三种情况,对应三种下一步。
这个动作的价值在于:它用一次小规模执行结果,替代了“文档看起来是否完整”的主观判断。只有当字段层、执行层、回传层都能对上,文档交付型供应商才适合进入规模化推广计划。
上述接口设计适用于文档由外部提供、执行由内部或第三方完成的情况。如果供应商同时负责实施,接口应改为任务单和验收单,而不是字段清单。另外,当你的站点结构频繁变动时,字段层清单需要同步维护,否则旧文档会变成误导。判断是否继续使用该供应商,不看文档厚度,而看每次小批量执行后的差异是否在收敛。差异持续扩大,就应暂停扩大范围,先修接口。