ERP、CRM、钉钉集成最容易出现“技术上同步成功，业务上不敢使用”。交付清单不能只写接口名称，还要能回答数据从哪里来、经过什么转换、失败后谁处理，以及业务人员如何确认最终状态。
字段映射与主数据
每条接口都应附字段映射表，写明源字段、目标字段、类型、必填规则、默认值、转换逻辑和样例。客户、商品、部门、员工、仓库等主数据还要确定唯一标识及维护系统。
同一字段在不同系统中的含义可能不同。例如 CRM 的“成交”是否等于 ERP 可建单，钉钉审批金额是否含税，人员离职后历史单据归谁。没有业务确认的字段表，只是技术猜测。
接口触发与状态流转
接口文档要说明触发事件、数据方向、调用频率、鉴权、去重标识和返回结果。创建、修改、作废、撤回等状态分别如何同步，不能只覆盖正常创建。
交付时可按业务链核对：CRM 成交创建 ERP 订单，钉钉审批结果更新业务状态，ERP 发货或回款信息回写 CRM。每一步都要同时查看源记录、接口日志和目标记录。
权限与敏感数据
账号权限应遵循实际需要，列出应用授权、接口账号、管理员、可访问对象和敏感字段。钉钉组织可见范围、CRM 客户数据范围与 ERP 财务权限不是同一个概念，不能用一个高权限账号绕过设计。
日志、测试数据和错误消息也可能包含客户、合同或财务信息。交付清单应写明脱敏、留存、访问和账号回收方式。
失败补偿与数据一致性
必须测试超时、限流、目标系统不可用、字段缺失、编码不存在和重复提交。对应方案可包括自动重试、人工审核、补偿任务或回滚，但要明确哪些错误允许自动处理，哪些必须由人判断。
系统还应提供差异查询或对账依据，让运维人员能发现“源系统已成功、目标系统未落单”等不一致状态。只记录一条笼统报错，无法支持后续处理。
日志、监控与告警
日志至少能关联业务单号、调用时间、接口方向、请求结果、失败原因和重试状态。监控要覆盖接口可用性与积压任务，告警则明确接收人、触发条件和关闭方式。
业务人员不一定需要看到技术报文，但应能查询某笔订单或审批目前卡在哪一步。技术日志和业务状态应通过同一标识关联。
验收证据与上线安排
验收用例要包括正常、修改、撤回、重复、无权限和接口失败场景。每项保留输入数据、预期结果、实际结果和日志位置；关键对象使用可追踪的业务样例核对，不以演示口头确认代替记录。
上线方案应说明数据初始化、切换时间、旧流程停用、人工兜底和回退条件。各系统负责人要知道出现差异时由谁决定数据以哪边为准。
运维交接与变更边界
交付资料包括字段映射、接口文档、配置参数、账号权限、日志入口、监控告警、补偿操作、测试记录和部署说明。第三方系统升级、字段变化、组织调整或新增流程由谁评估，也要写进维护边界。
完成交接的判断标准，是客户能查到一次同步、定位一次失败、执行约定补偿，并知道何时需要联系哪一方，而不是文档文件夹里有若干未验证的说明。
