电子合同平台选型：证据链、API集成与成本测算

电子合同平台怎么选，这个问题我在最近半年被问了不下十次，问的人从十来人的创业团队到几千人的集团公司都有。有意思的是，绝大多数人一开口就是问价格，"你们家一份合同多少钱"，而真正让项目在上线前一周翻车的，从来不是单价高低，而是签署链路能不能跑通、出证的时候拿不拿得出东西、回调丢了能不能对得上账。所以这篇不打算做那种列参数、比价格的常规测评，我想按一个真正要落地的人的视角，把"电子合同平台"这个东西拆开来看：它到底在卖什么、四类典型平台各自的长板和边界在哪、哪些指标比价格更值得抠、成本怎么用自己的业务量算清楚、接进自有系统时会踩哪些坑。适合正在做选型的技术负责人、法务、行政采购，也适合刚开始接触这块业务的同学。为了不写成软文，下面用甲、乙、丙、丁四个代称指代四类代表性平台，它们分别对应综合型、法务导向型、轻量SaaS型、办公生态自带型这四种典型路线，你把手上的候选对号入座就行。

1. 别急着比价：先弄清电子合同平台到底在卖什么

很多人对电子合同的想象停留在"上传一个PDF，双方点一下，盖个章"。真做起来你会发现，这背后是一整套身份、意愿、证据的链条。平台卖的不是"签字按钮"，而是"当这份合同将来被质疑的时候，你能拿出一条完整、可验证、被第三方认可的证据链"。理解这一点，后面所有的选型判断都会变得清晰。

打个比方，纸质合同的证据链靠的是纸、笔迹、红章、快递单，物理世界里这些东西很难伪造；电子世界里没有"纸"，就必须用密码学手段重建一套"不可伪造"的等价物。这套等价物的核心是三样：证明"这个人就是他本人"的实名认证，证明"这个动作是他主动做的"的意愿认证，以及证明"这份文件签完之后一个字都没被改过"的完整性校验。三者缺一，合同的证明力就会打折。

1.1 一次"合规签署"背后要凑齐的四件事

现行法律框架对"可靠电子签名"的认定，通常被归纳成四个要件：签名制作数据专属于签名人；签署时该数据仅由签名人控制；签署后对签名的任何改动能够被发现；签署后对数据电文内容和形式的任何改动能够被发现。这四句话听起来抽象，翻译成工程语言就是四个技术动作。

第一，平台必须给每个签署主体签发或绑定一份数字证书，私钥由本人控制，这是"专属性"。第二，签署动作发生前必须做一次身份校验，短信验证码、人脸识别、视频双录都算，强度不同但目的相同，这是"控制权"。第三，合同文件生成后用哈希算法（常见的SHA-256或国密SM3）算出摘要，签章时把摘要和签名值一起写进文件，任何一字节的改动都会让哈希对不上，这是"签名防篡改"。第四，签完之后要有一个可信时间源给这份文件盖时间戳，证明"这个状态在某个时刻已经存在"，这是"内容防篡改"里最容易被忽略的一环。

我见过不少团队在评估时只盯着"能不能盖章"，完全不问时间戳来自哪家、证书链能不能验、验签工具是不是开放的。等到真出了纠纷，对方律师一句"你怎么证明这份文件在签署后没被你们自己改过"，就答不上来了。所以第一轮沟通就该把这三个问题抛出去：证书谁签发、时间戳谁提供、验签报告能不能由第三方独立出具。

1.2 签署链路中的六个技术环节

把一次签署从发起到归档完整走一遍，大致会经过六个环节，每个环节在不同平台上的成熟度差异极大，这也是横向对比时最该逐个打勾的地方。

这六个环节里，最容易被低估的是"存证"和"归档"。发起和签署是显性功能，跑一遍就知道行不行；存证和归档是隐性能力，平时没人看，出事了才翻。我的建议是，在POC阶段就主动要求对方出一份完整的存证报告样本，看看里面到底记了什么——只记最终文件的哈希，和记录每一次查看、每一次认证失败、每一次签署的时间点与IP，是完全两个量级的证据密度。

1.3 选型翻车最常见的三种情形

第一种是"业务部门先买了，技术后知道"。某公司行政用个人账号买了几百份的套餐，结果业务系统要对接时发现这个套餐不支持API调用，只能人工上传，白买。这类问题的根源是采购流程里没人问一句"这个要不要跟系统打通"。

第二种是"集成做完了，发现计费口径不对"。合同里写的是"按份计费"，但一份合同三个签署方，平台按"签署次数"扣费，实际消耗是份数的三倍，预算直接超支。这个坑我在第4节会专门拆开算。

第三种是"上线了，但出证走不通"。真到了要走法律程序需要出证的时候，发现平台只能提供一份自制的哈希存证说明，拿不到有资质的第三方出具的鉴定材料，或者需要额外付费、额外等待周期。这类问题在选型阶段几乎没人问，因为大家都觉得"不会那么倒霉"。

2. 四类代表性平台的能力画像

把市面上能见到的方案归归类，基本能收敛到四种路线。它们不是谁好谁坏的问题，而是各自长在不同的土壤上，适配的业务形态完全不同。下面这四段是我按实际接触过的项目整理的画像，你对照手上的候选看。

2.1 甲平台：资质与司法配套最全的综合型

甲这类平台起步早，牌照、资质、司法配套是它们最厚的护城河。具体表现在几个方面：自建或深度合作的CA体系、与多家司法鉴定机构和公证机构的对接通道、相对完善的存证链条、以及一整套"出证服务"的标准化流程。如果你的业务涉及金额较大、纠纷概率不低、法务部门对证据链有明确要求，这类平台通常是绕不开的选项。

但综合型的代价是重。功能多意味着菜单深，一线业务人员第一次用往往要找半天；接口能力齐全但文档组织得比较"按模块划分"，你得先搞清楚自己要的是"文件签署"还是"流程签署"这两套不同的API体系。另外这类平台的价格通常不是最便宜的，商务谈判的空间也相对有限，因为它们的客户结构里大客户占比高，不太需要靠低价抢单。

我个人的判断标准是：如果你们公司法务部能明确说出"我们需要什么形式的出证材料"，那甲类值得重点谈；如果法务对这块还没概念，那先别急着为"司法配套"付溢价，可以放到第二阶段再升级。

2.2 乙平台：法务视角的模板与合规审查

乙这类平台的产品设计明显是从法务的使用习惯出发的。最典型的特点是模板库和条款管理做得细——不是简单的"上传Word"，而是把合同拆成可复用的条款块，支持条款版本管理、审批流、以及签署前的合规检查提示。对于合同量大、模板多、条款经常微调的行业（比如供应链、人力资源、渠道代理），这类设计的价值很实在。

它的另一个特点是对接方式偏"半自动"。很多流程是通过配置化的表单和规则引擎完成的，不一定需要写代码，行政和法务自己就能把一条签署流程搭起来。这对技术资源紧张的中小团队是好事，但也意味着深度定制时你会碰到产品设计的边界——当业务逻辑超出它预设的规则组合，改造成本可能比从零对接API还高。

我在一个项目里遇到过这种情况：业务要求"三方签署，第二方签署完成后自动触发第三方，且第三方必须在48小时内完成，超时自动作废并通知发起人"。乙类平台的流程引擎能配出前一半，但"超时作废+自动通知"需要走接口由我们自己的系统来兜。所以评估这类平台时，一定要拿你最复杂的那条流程去试配置，别拿最简单的demo流程试。

2.3 丙平台：轻量SaaS，重体验轻定制

丙这类平台走的是"开箱即用"路线，注册即用、界面干净、移动端体验好，发一份合同给客户签，对方的操作路径通常最短。对于签署量不大、流程简单、主要场景是"给外部合作方发个协议签一下"的团队，这类产品上手成本最低，几乎不需要培训。

代价在深度。API的能力边界相对窄，回调的事件类型少，批量处理、复杂的签署顺序、印章权限分级这些偏企业级的需求，往往要等到更高版本才有。另外这类平台的计费通常按份或按套餐走，小量时很划算，量一大单价优势就不明显了。

我的经验是，丙类适合作为"过渡方案"或者"部门级工具"。如果你们公司的主营业务系统短期内不打算集成电子签，只是行政、销售需要一个发合同的工具，那选它没毛病；但如果你计划一年内把签署嵌进订单系统、CRM或者HR系统，那就别在这里省事，直接评估接口能力更强的。

2.4 丁平台：办公生态自带，接入零成本但有边界

丁这类平台最大的优势是"本来就在用"。如果你的团队日常沟通、文档、审批都在同一个办公生态里，那电子签就是顺手点一下的事，不需要新开账号、不需要重新建组织架构、审批流直接复用。这种零接入成本带来的推动力是惊人的，很多公司的电子签落地之所以顺利，就是因为"不用学新东西"。

边界也很清楚：它的能力上限取决于生态本身的开放程度。对外部签署方的覆盖、对复杂业务流程的支撑、对私有化和数据本地化的支持，通常不如专业平台。另外当你需要把签署能力嵌进自己的业务系统时，能拿到的接口粒度可能不够细，比如想精细控制每一个签署字段的定位，未必支持。

还有一点要提醒：生态型方案的"便宜"是有前提的，就是你的用量在套餐内。一旦超出套餐需要单独购买份数包，单价可能比专业平台还高，这个一定要提前问清楚超额部分的计价方式。

2.5 一张表看清四类平台的分水岭

这张表只能帮你快速排除，不能帮你做决定。真正的决策要靠第3节的硬指标和第4节的成本测算。

3. 六个硬指标：比价格更能决定三年后是否后悔

价格是可以谈的，能力是谈不来的。下面这六项，我在每次选型时都会逐项打分，权重按业务特点调整，但一项都不会跳过。

3.1 出证能力：出事那天才知道值钱

出证能力要拆成三层看。第一层是"能不能出"，即平台是否具备对接司法鉴定、公证、仲裁等机构的标准通道；第二层是"多快能出"，是线上一键申请几小时出，还是要走线下流程等一周；第三层是"出了能不能用"，这份材料在实务中是否被普遍认可，格式是否规范。

评估方法很朴素：让对方提供一份脱敏的真实出证材料样本，看看里面有没有完整的签署过程记录、时间戳、证书信息、哈希校验值。如果对方只能给一份"存证证明"，内容只有文件名和一个哈希，那这份材料的证明力就相当有限。另外一个细节是问清楚出证是否额外收费、收费标准是什么，很多平台的套餐价里不含出证服务，这块是单独计费的。

提示：出证材料的"过程记录"比"结果记录"更重要。只证明"最终文件未被篡改"是不够的，能证明"谁在什么时间用什么方式完成了认证并点击了签署"，证据链才完整。

3.2 意愿认证的强度可配置性

不同业务对认证强度的要求天差地别。一份几千块的采购单，短信验证码就够了；一份涉及大额资金的担保协议，可能需要人脸识别加视频双录。评估时不要只看"支持哪些认证方式"，要看"能不能按合同类型、按金额档位、按签署方身份分别配置"。

举个实际场景：同一套系统里，内部员工签署用企业账号登录即视为完成认证，外部供应商签署要求法人人脸识别，外部个人签署要求身份证加人脸。如果平台的认证策略是全局统一的，那你只能在"全严"和"全松"之间二选一，前者伤体验，后者伤合规。

还要问清楚认证失败的处理路径。认证失败的错误码是否细分？是"姓名与证件号不匹配"还是笼统的"认证失败"？前者可以让用户自己改，后者只能转人工，客服成本差好几倍。

3.3 接口成熟度：文档质量和回调设计

技术团队评估接口，通常先看文档。我的经验是，看三样东西就够了：一是有没有可以直接跑的示例代码，二是错误码表是否完整并附处理建议，三是有没有沙箱环境。这三样齐全的平台，集成周期通常能压缩一半。

但真正决定长期维护成本的，是回调设计。电子合同的核心交互是异步的——你发起签署，用户可能在几小时后才签，平台通过回调通知你结果。回调设计得好的平台，会做到：事件类型细分（已查看、已签署、已拒签、已过期）、回调带签名可验真、支持失败重试、提供主动查询接口作为兜底。设计得差的平台，只有一个"签署完成"的事件，且不保证送达，你只能靠定时轮询。

注意：不要相信"回调一定会到"。任何异步通知都有丢失的可能，主动查询接口是必需品而不是可选项。如果平台没有状态查询接口，这个方案在架构上就是不合格的。

3.4 计费口径的换算陷阱

这是最容易吃亏的地方，第4节会展开算，这里先点出三种常见口径的差异：按份（一个合同文件算一份）、按签署次数（每个签署方的每次签署算一次）、按坐席（每个使用账号按年收费）。同样是年签5000份合同，三种口径算出来的钱可能差两三倍。

评估时要问的问题很具体：一份合同三个签署方，扣几次？签署被拒后重新发起，扣不扣？合同作废了退不退？模板变更后重新生成，算不算新的一份？这些问题在销售阶段问清楚，比签完合同再扯皮强得多。

3.5 数据归属、存储与私有化边界

合同数据是企业的核心资产，存储位置、归属权、导出能力这三件事必须在合同里写清楚。公有云方案要问：数据存在哪个区域、加密方式是什么、平台方是否有权访问明文、合同终止后数据保留多久、能不能全量导出（包括过程记录）。

私有化部署不是所有团队都需要，但如果你们有明确的数据不出内网要求，那在评估初期就要确认对方的私有化版本是否存在、最低起购量是多少、私有化版本和SaaS版本的功能差多少。很多平台的私有化版本是"阉割版"，缺的恰恰是你最需要的那些高级能力，这个必须提前对齐。

3.6 服务响应与故障复盘机制

电子签不是核心交易系统，但它卡在业务流程中间，一挂就断。所以要问清楚：故障响应时限是多久？有没有专属对接群？历史上出过什么级别的故障、怎么复盘的？

这里有个小技巧，问销售"你们最近一次比较大的故障是什么时候、什么原因"，观察他的回答。能坦诚说出原因和改进措施的平台，通常运维体系更成熟；含糊其辞或者一口咬定"我们从没出过故障"的，反而要警惕。

4. 成本测算：用你自己的业务量算一遍

价格表都是假的，只有你自己的业务量算出来的数才是真的。这一节我给一套可以照着套的算法，你把数字换掉就能用。

4.1 三种计费模型的换算公式

先统一口径。设年签署合同份数为 N，平均每份合同的签署方数量为 P（含己方），则年签署次数 T = N × P。

按份计费：年成本 = N × 单价_份。 按次计费：年成本 = T × 单价_次 = N × P × 单价_次。 按坐席计费：年成本 = 坐席数 × 单价_坐席 + 超额份数 × 单价_份。

换算的关键是单价之间的数量级关系。通常按次单价约为按份单价的 40%–60%，所以当 P 大于 2 时，按次计费的总价会超过按份计费。反过来，如果 P 普遍等于 1（比如单方签署的确认函、告知书），按次计费反而更划算。

4.2 一个年签5000份合同的测算样例

假设某公司年签署合同 5000 份，其中 70% 是双方合同（P=2），30% 是三方合同（P=3），则平均 P = 2.3，年签署次数 T = 11500 次。下面的单价是为了演示换算关系而设的假设值，不是任何平台的实际报价。

看出问题了吗？坐席制看起来"包年不限量"，但往往有隐含的份数上限，超额部分照样按份收费，最后反而最贵。而坐席制的真正成本还不止于此——坐席是按"使用账号"算的，如果贵公司有 200 个销售都要发合同，30 个坐席根本不够，这个模型会迅速失控。

所以测算时一定要先回答一个问题：到底有多少人要"发起"合同，多少人只是"签署"？签署方通常不计坐席，发起方才计。如果发起人集中在行政、法务、财务这几个岗位，坐席制是可行的；如果发起人散布在几百个销售身上，坐席制基本可以排除。

4.3 容易被忽略的四项隐性成本

第一项是认证费用。人脸识别、企业四要素核验这些认证动作，很多平台是按次单独收费的，不包含在合同份数里。年签 5000 份、每份 2.3 个签署方，如果每个签署方都要人脸核验，就是一万多次认证，这块成本可能占到总价的 20% 以上。

第二项是出证费用。前面提过，出证通常是单独计费的，按次收，金额从几百到上千不等。如果你们行业纠纷率较高，这项要提前纳入预算。

第三项是集成与运维人力。对接一套 API，从评估、联调、测试到上线，一个熟手通常需要 5–15 人天，如果平台的文档质量差、沙箱不稳定，这个数字会翻倍。这部分不进平台账单，但实实在在是成本。

第四项是迁移成本。用了两年想换平台，历史合同的存证、验签、出证怎么办？有些平台的历史数据只能用自家工具验签，换平台后就变成"死档"。签合同前一定要问：数据能不能全量导出为标准格式？导出的文件离开平台后还能不能独立验签？

5. 集成实测：把签署能力接进自有系统的四个关键动作

假设你已经选定了平台，接下来是把它接进业务系统。这一段我按实际做过的项目顺序写，重点讲那些文档里不会写、但一定会踩的地方。

5.1 账号与组织架构打通

第一件事是身份映射。业务系统里的用户 ID 和平台侧的账号 ID 必须建立一一映射，通常做法是在平台侧创建"第三方用户标识"，用自己的用户 ID 作为唯一键。听起来简单，但坑在两点：一是同一个自然人可能在不同主体下有不同的身份（既是A公司的法人，又是B公司的员工），映射关系必须是"用户ID + 主体"的复合键；二是人员离职后账号要不要停用、停用后历史合同的查看权限归谁，这些要在设计阶段就定好。

我的做法是在本地维护一张映射表，字段包括：本地用户ID、平台用户ID、所属主体ID、实名状态、证书序列号、状态、最后同步时间。这张表是后续所有操作的基础，宁可设计得冗余一点。

5.2 模板变量的坑比想象上多

模板签署看起来最省事，实际上变量处理是出错重灾区。常见的问题有这么几类。

一是类型不匹配。模板里定义的是日期字段，你传了个时间戳字符串，平台可能不报错，直接显示成一串数字。二是长度溢出。模板预留了两行位置放公司名称，实际名称太长自动换行把下面的内容顶掉，导致签署位置偏移。三是特殊字符。公司名里带括号、带"·"，某些平台在生成PDF时会渲染成乱码或者方框。四是空值处理。可选字段不填时，模板上留的是一个空白下划线还是直接不显示，各平台行为不同。

解决办法是建立一个"变量填充测试集"，把最长的公司名、最复杂的地址、带特殊字符的名称、空值、超长金额都放进去跑一遍，逐个目视检查生成的PDF。这个测试做一次能省后面无数次返工。

# 变量填充的自检思路（伪代码，与具体平台无关） def build_variables(contract): return { "party_a_name": safe_text(contract.a_name, max_len=40), "amount_cn": to_chinese_amount(contract.amount), # 大写金额 "amount_num": f"{contract.amount:,.2f}", "sign_date": contract.sign_date.strftime("%Y年%m月%d日"), "remark": safe_text(contract.remark, max_len=200, allow_empty=True), } def self_check(pdf_bytes, expect_count): # 渲染后做一次基本校验：页数、关键字段是否出现、是否有乱码占位符 assert page_count(pdf_bytes) >= 1 text = extract_text(pdf_bytes) assert "□" not in text and "\ufffd" not in text return True

5.3 回调验签与幂等处理

回调处理有两个必须做的事：验签和幂等。验签是为了确认这个请求真的来自平台，不是别人伪造的；幂等是为了保证同一个事件被重复推送时不会重复处理。

验签的标准做法是对回调内容按约定规则拼接后做 HMAC 计算，和请求头里的签名值比对，同时校验时间戳防止重放。这里有个细节：拼接时字段的顺序、空值的处理、编码方式必须严格按文档来，差一个字符就验不过。我建议先用平台提供的示例数据跑通验签逻辑，再上真实回调。

幂等的做法是用"业务流水号 + 事件类型 + 事件ID"组成唯一键，处理前先查一下这个键有没有处理过。这里要注意，有些平台的事件ID在重试时会变，所以更稳妥的做法是用"业务流水号 + 事件类型 + 状态"做幂等键，配合状态机判断是否允许这次状态跃迁。

// 回调处理骨架 async function handleCallback(req) { const raw = req.rawBody; // 必须用原始字节验签 if (!verifySignature(raw, req.headers['x-sign'], req.headers['x-timestamp'])) { return res.status(401).send('bad signature'); } const evt = JSON.parse(raw); const key = `${evt.bizNo}:${evt.eventType}:${evt.status}`; if (await seen(key)) return res.status(200).send('dup'); // 幂等 await withLock(key, async () => { await applyStateTransition(evt); // 内部再做一次状态合法性校验 await markSeen(key); }); return res.status(200).send('ok'); }

注意：验签必须用原始请求体，不能用框架解析后的对象重新序列化。JSON 重新序列化后字段顺序和空格都可能变，验签百分之百失败。这个坑我见过至少三个团队踩。

5.4 状态机与超时兜底

合同状态不是线性的，会来回跳。典型状态包括：草稿、待签署、部分签署、已完成、已拒签、已过期、已撤销。业务系统必须自己维护一份状态机，明确哪些跃迁合法、哪些非法，非法跃迁要告警而不是静默接受。

超时兜底是另一半。签署链接通常有有效期（7天、15天、30天不等），到期后平台会置为过期，但平台不一定主动通知你。所以业务侧要有一个定时任务，扫描"待签署"且"已超过约定时间"的单据，主动调查询接口确认状态，然后决定是提醒、重发还是作废。

这里有个容易被忽略的点：重发不等于新建。重发应该在原单据上重新生成签署链接，而不是创建一份新合同，否则你的业务数据里会多出一堆重复单据，对账时非常痛苦。

6. 一次上线前的回调丢失排查全链路

这一段讲一个真实项目里发生过的事故，我把排查过程完整写出来，因为这类问题的排查思路比结论更有价值。

6.1 现象与第一反应

上线前一天的压测，测试同学反馈：发起 50 份合同，手动在测试环境签了 20 份，业务系统里只有 13 份变成了"已完成"。剩下 7 份，平台侧显示已签，我们侧还是"待签署"。

第一反应是"回调没收到"。但这里要先排除一种可能：回调收到了，处理失败了。这两种情况的排查方向完全不同。所以我做的第一件事是拉日志，搜回调接口的请求记录。结果是这 7 笔在网关日志里完全没有记录，说明请求根本没到达。方向确定为"回调丢失"。

6.2 逐层排除：从网关到业务日志

按链路从外往里排：平台侧发送 → 公网 → 负载均衡 → 网关 → 应用 → 业务逻辑。

第一步查平台侧的回调记录。平台的开放平台后台能看到每次回调的发送状态和响应码。查下来发现，这 7 笔平台的记录是"已发送，响应超时"。响应超时说明请求发出去了，但我们这边没在平台要求的时间内返回。

第二步查负载均衡和网关的访问日志。这里出现了关键信息：这 7 笔请求确实到达了网关，但状态码是 504。504 意味着网关等后端响应超时了。

第三步查应用日志。应用侧这 7 笔请求有进入记录，但没有处理完成的记录。看线程栈，发现这些请求都卡在同一个地方——一个数据库行锁上。原因是我们的回调处理逻辑里有一段"先查后改"的操作，并发回调打到同一条业务单据上，互相等锁。

到这里根因已经清楚了：压测时同一批单据的多个签署方几乎同时完成签署，触发了多条回调并发处理同一条业务记录，行锁等待超过了网关的超时时间，网关返回 504，平台认为失败。而平台的重试策略是间隔递增重试，重试时我们的锁已经释放了，理论上应该成功——但重试的请求打到了另一台机器上，而那台机器的本地缓存里还是旧状态，判断"状态未变"直接返回了成功但没处理。这是第二层问题。

6.3 根因与修复动作

根因有两个，都得修。

第一个是并发控制。回调处理改成"快速落库 + 异步处理"：回调接口只做验签、幂等检查、写入事件表，然后立刻返回 200，真正的业务处理由后台任务消费事件表完成。这样接口响应时间从几百毫秒降到十几毫秒，彻底避开网关超时。

第二个是缓存一致性。事件消费任务改成每次处理前从数据库读最新状态，不依赖本地缓存；同时给状态跃迁加上版本号，更新时带上版本条件，防止并发覆盖。

修复后重跑压测，50 份全部对账一致，问题关闭。

6.4 同类问题的预防清单

这件事之后我总结了一份清单，后面每个项目上线前都过一遍。

其中"每日对账"这一条我认为是必需的。任何异步系统都会有不一致，关键是有没有办法发现不一致。对账任务不复杂，拉平台侧的当日在途单据列表，和本地比一遍状态，差异超过阈值就告警。有了这个，就算回调丢了，第二天也能补上。

7. 按团队规模给结论：不同场景该往哪边靠

写到这里，前面的分析已经够了，这一节直接给倾向性结论。注意这是倾向不是推荐，具体还得结合你的业务。

7.1 十人以下的小团队

签的量不大，流程简单，主要是给客户发个服务协议、给员工签个劳动合同。这种场景没必要折腾API，选丙类或丁类，看重的是"对方收到链接能不能一把签完"。判断标准就一条：找一个没用过你们系统的人，让他从收到短信到签完，能不能在三步内完成。超过三步就换。

预算上，这个阶段不要买年框大套餐。按份买，用多少买多少，等量稳定了再谈年框。另外注意别买最低档的套餐，很多平台最低档只包含几十份，稍微超一点就要单独加购，很不划算。

7.2 百人级、签署流程稳定的公司

这个阶段通常已经有CRM、ERP或者自建的业务系统，签署需要嵌进去。方向应该是甲类或接口能力强的乙类。核心考量不再是界面好不好看，而是接口能不能覆盖你的流程、回调是否可靠、出证能不能满足法务要求。

这个规模建议做一次正式的POC，用真实业务单据跑通全流程，而不是用demo数据。POC的排法见下一节。

7.3 强合规、需要私有化部署的场景

金融、医疗、大型制造这类对数据位置有硬要求的，SaaS基本可以排除，直接问私有化。私有化的评估重点完全不一样：不看界面，看部署架构、看升级方式、看性能压测报告、看和你们现有中间件的兼容性。

一个现实提醒：私有化版本的功能通常滞后于SaaS半年到一年，而且升级需要你们自己的运维配合。所以要在合同里明确升级支持的服务方式和响应时限，别默认"买了就有人管"。

7.4 已经重度使用某个办公生态的团队

如果全公司日常协作都在同一个生态里，丁类方案的推动成本最低，优先考虑。但要提前确认两件事：一是外部签署方的覆盖情况，你的客户里有相当比例不用这个生态的话，体验会打折；二是接口粒度能不能满足未来的系统集成需求，别等到要接业务系统时才发现接口不够用。

一个折中方案是"双轨"：对外用生态自带的方案解决内部审批和员工签署，对内嵌业务系统的部分用专业平台。代价是要维护两套账号体系，收益是各取所长。

8. 七天POC怎么做才有意义

POC 最常见的失败是做成"产品演示会"——销售演示一遍，大家觉得挺好，然后签合同，然后上线时发现一堆问题。真正有价值的 POC 必须用自己的数据、自己的流程、自己的人去跑。

8.1 时间怎么排

七天是压缩后的最短周期，再短就只能看演示了。我的排法是：第1天环境开通和账号配置，第2天跑通最简单的单方签署，第3–4天跑通你最复杂的那条业务流程（多方、有顺序、有超时），第5天做出证和归档测试，第6天做异常场景（拒签、过期、撤销、重复回调），第7天出评估报告。

关键在第3–4天和第6天。简单流程谁都能跑通，复杂流程和异常场景才是分水岭。异常场景尤其要试，我列几个必测项：签署方拒签后重新发起、签署链接过期后重发、同一份合同多个签署方并发签署、回调重复推送、签署中途修改合同内容（应该禁止）。

8.2 验收打分表

打分不要追求绝对分数，追求的是"哪一家在你的关键项上明显更稳"。如果两家分数接近，选那个在异常场景上表现更好的，因为上线后你面对的大部分是异常场景。

8.3 谈判时可以争取的三个条款

第一个是用量弹性条款。约定首年用量可以上下浮动一定比例，超出部分按阶梯价而不是标准价结算，避免业务量突然增长导致预算失控。

第二个是数据导出与迁移条款。明确合同终止后数据可以全量导出，导出格式包含可独立验签所需的全部信息（文件、哈希、证书链、时间戳），且导出不额外收费。这条在签的时候没人在意，换平台时价值千金。

第三个是服务等级条款。把可用性指标、故障响应时限、连续故障的补偿方式写进合同。不是为了索赔，是为了让对方在排期时把你当回事。

最后分享一个我在实际操作中的体会：选电子合同平台这件事，本质上选的是"三年后出问题时谁能帮你兜住"，而不是"今天谁的界面好看、谁便宜两百块"。我见过太多团队在比价环节省下几千块，然后在集成、出证、迁移上多花几万块和几个月时间。把前面那六个硬指标和成本测算认真过一遍，多花两天，能省两年。