CRM电子签章集成怎么验收？从合同映射、回调幂等到证据归档

“CRM里能点发起签署”只是入口可用，不代表电子合同闭环。真正的验收对象，是一份CRM合同能否唯一映射到签署流程，签署人身份和版本能否追溯，回调能否抵抗重复、乱序和漏送，最终文件与证据能否按权限长期调取。

先定边界：CRM管业务事实，签章平台管签署可信性

CRM适合保存客户、商机、报价、合同业务编号、审批结论、履约状态和负责人；电子签章平台负责实名认证、签署意愿、签名制作数据控制、签署过程和签署文件。不要在CRM里自造“已签署”按钮，也不要把签章平台当作合同主数据仓库。中国人大网公布的《电子签名法》第十三条强调签名人专有控制、签名和数据电文改动可发现；第十四条规定可靠电子签名与手写签名或盖章具有同等法律效力。这意味着验收必须覆盖身份、内容完整性和可验证性，而非只看页面状态。

把签署状态设计成状态机，而不是一个复选框

腾讯电子签开放文档列出的合同状态包含创建、签署中、完成、拒签、撤回、流签、失效和异常等多种状态。CRM至少应保留本地业务状态、平台原始状态、平台事件时间、接收时间和事件编号。只有“全部签署完成”且最终文件获取与校验成功，才允许进入履约；拒签、撤回、流签和异常必须回到负责人待办。

回调验收的核心是幂等、验真和补偿

厂商回调文档通常把HTTP 200视为已成功接收；如果业务处理失败却提前返回200，平台可能不再重发。接收端应先验签和校验时间窗，再用事件ID或“流程ID+状态+事件时间”去重，将原始事件写入不可随意修改的接收表，然后异步更新CRM。回调重复不得产生重复任务，回调乱序不得把“完成”退回“签署中”，回调漏送则由低频对账任务按流程ID补齐。

证据归档要与合同版本绑定

每个完成流程应归档最终签署文件、签署报告或可验证凭证、文件哈希、签署人及角色、关键时间、平台流程号和获取时间。国家标准GB/T 38540-2020规定了安全电子印章、电子签章的数据结构和密码处理流程，可作为技术方案评审的标准线索；具体法律适用仍应由企业法务结合合同场景判断。CRM只保存授权范围内的索引和必要副本，下载、预览与导出均应留下审计记录。

还要验证文件生命周期：平台临时下载地址失效后，授权用户是否仍能从企业归档位置取得同一文件；证书更新、签署服务商切换或接口版本升级后，历史合同是否仍可验签；员工离职后，原经办合同是否能按责任交接而不改变原签署人。对保存期限、备份、恢复和销毁的规定，应由法务、档案和信息安全共同确认，不能由接口开发人员自行假设。

上线前用12个场景做端到端验收

1. 正常双边签署并取得最终文件；
2. 签署人顺序签与无序签；
3. 个人和企业身份映射；
4. 签署人拒签；
5. 发起方撤回；
6. 签署超时；
7. 签署人变更导致失效；
8. 重复发起拦截；
9. 重复、乱序、伪造回调；
10. 回调漏送后的主动对账；
11. 权限外用户无法查看文件；
12. 离职交接后责任人和审计链不断裂。

建议为验收数据准备三组合同：最小字段的标准合同、包含附件与多签署人的复杂合同、故意制造异常的故障合同。三组数据使用统一业务编号，但版本和请求ID必须不同。验收人员要从CRM、接口日志、签章平台和归档位置四处交叉核对，任何一处状态不一致都生成差异单，不能用人工截图直接销项。

验收报告不要只贴成功截图。每个场景应记录输入合同版本、请求ID、平台流程ID、回调次数、最终状态、文件校验值、异常责任人和复测结果。需要评估私有化环境、接口部署和证据留存边界，可从CRM私有化部署、CRM源码交付和实施与迁移服务的既有页面继续核对。

主要信息来源

• 北京市政府网站转载：《中华人民共和国电子签名法》
• 国家标准全文公开系统：GB/T 38540-2020
• 腾讯电子签开放文档：合同相关回调
• 腾讯电子签开放文档：回调通知说明

计划接入电子签章时，先用一份真实但脱敏的合同跑完上述12个场景，再决定是否上线。可通过网站现有咨询入口沟通接口边界与验收范围。