合同签完后,销售说客户还期待一次额外培训,报价单里写了可选项,正式合同却只约定远程上线。交付团队如果把所有邮件都当承诺,会失控;只看合同,又可能漏掉需要尽快澄清的期待。
AI能把来源分层并整理启动清单,但不能把销售措辞升级成合同义务。冲突项必须在启动会上明确。

先给承诺按证据级别排队
本轮输入限定为签署合同、最终报价和范围附件、销售邮件与会议确认、标准交付模板。每份资料先记录来源、时间和版本;关键资料缺失时,把缺口写进清单,不用相似记录补齐。
报价合同和邮件怎样逐项对照
| 步骤 | 具体做法 |
|---|---|
| 锁定签署包 | 确认正式合同、附件、最终报价和签署日期。 |
| 提取承诺项 | 拆出范围、数量、里程碑、客户前提、验收和沟通安排。 |
| 追踪销售表述 | 连接邮件与会议确认,标记已入合同、条件性和未纳入。 |
| 生成启动清单 | 为已确认义务分配责任、日期、来源和客户依赖。 |

未写进合同的期待如何处理
| 情况 | 判断依据 | 处理 |
|---|---|---|
| 正式义务 | 签署合同或附件明确 | 进入交付基线 |
| 条件承诺 | 条件写清且已被接受 | 同时记录触发条件 |
| 销售期待 | 邮件提及但未进入合同 | 启动会澄清 |
| 直接冲突 | 合同与报价或邮件相反 | 交法务销售裁决 |
这一步真正要作出的决定是哪些是正式交付义务,哪些是有条件承诺,哪些销售表述没有进入合同需要确认。无法回到原始证据的结论只能标为待确认,不能进入正式交付。
用一个包含口头加项的案例演练
准备一份合同、报价和邮件,其中培训在报价里为可选,邮件却写成默认赠送,检查是否会被错误纳入正式范围。
试跑后还要从判定正常的结果中抽查,若发现漏检,就修正规则并重跑受影响范围。最终验收目标是带来源和责任人的客户启动清单。
销售转交AI任务说明
你正在协助负责新客户启动的销售运营或交付经理。触发情况是合同刚签署,报价单、正式条款和销售往来中包含不同层次的范围、期限与承诺。只读取签署合同、最终报价和范围附件、销售邮件与会议确认、标准交付模板。需要判断哪些是正式交付义务,哪些是有条件承诺,哪些销售表述没有进入合同需要确认。交付带来源和责任人的客户启动清单。每条结论标出来源位置、版本和待确认人。第一轮只生成预览,不发送、不删除、不写回正式系统。
销售交付交接的输出先保存在预览区。经办人逐条关闭异常并记录修改理由,高风险动作由有权限的人执行。
交付前最后检查销售交付交接
- 每项承诺标明原始来源
- 条件和客户前提没有丢失
- 未入合同表述单独列出
- 责任人只接收已确认义务
如果继续自动处理可能导致交付团队漏掉合同义务,或把未经签署的口头承诺当成正式范围,就停止在当前步骤并指定接管人。合同解释与范围变更需由法务、销售和交付负责人确认,AI不作法律结论。
交付启动可组合哪些Skill
PDF Skill负责提取签署合同和报价附件中的范围与义务,输入是签署文件,输出带位置的正式承诺;DOCX Skill负责读取销售确认文件和批注,输入是方案与确认记录,输出条件承诺和范围线索;Internal Comms Skill负责把已核验承诺整理成内部启动清单,输入是正式义务和待确认销售表述,输出带责任人的交付启动清单。销售交付交接的能力之间通过带来源的中间表交接,不把未核实判断直接传给下一步。
销售交付交接的Skill边界是:复杂版面和扫描内容必须回看原页,不能单凭提取文本认定法律效力;复杂修订需检查XML关联和渲染结果,不能用重排格式代替内容差异判断;只能组织已提供或已授权读取的事实,不能替代业务负责人确认敏感结论

技能提升网