认识一家公司,O2O业务,而且还是2B的。业务发展到全国180多个城市,业务最火的时候,合同管理不过来,需要找一个专门保管合同的小仓库,有6个专门负责处理合同存证的工作人员。用来记录X年X月X日,谁和谁签了什么类型的合同;用来提醒公司销售部XX合同就要到期了,记得续约什么的。

还有一家国内独角兽钢铁互联网公司,对纸质合同的管理和痛苦,不亚于以上。

我也看到过负责前端销售的同事,被山一样的A4合同堵的只露个尖儿。一年光合同来回邮递费用就要大几十万。

公司合同那么多,怎么没想过电子签呢?

其实,纸质合同完全可以以电子合同+电子签署的形式解决。国内也有很多SaaS供应商,提供企业资质认证、合同多方签署、以及签署后的存档存证服务。通过这些服务,所有纸质合同都可以消失不见了,甚至包括员工劳动合同、期权协议等等等等。

从产品角度上来讲,利用现成的第三方服务,再加上你自己公司的一点点逻辑,就可以解决电子合同的问题。需求比较简单,实施起来也比较快,属于四两拨千斤,立竿见影,又有一点点那么科技感在内的东西。因此推荐各位产品经理不妨试一试。

那么怎么着手去授理该需求,从而实现产品功能呢,我个人建议从以下6个角度先来梳理下你手里的业务场景。

1. 合同主体都是哪些,是个人还是公司,合同模板是标准模板,还是非标模板?

2. 对方在你提供的什么工具或应用上完成签署?

3. 签署方如果是公司,那么签署人(被委托人)和公司是什么关系?

4. 如果合同主体大于2方,签署顺序怎么来定?

5. 合同里有哪些变量,哪些地方需要用印?

6. 合同签署后,会影响你现有的那些业务逻辑?


为了总结我之前在电子签过程中走过的弯路,特针对以上6点举实例一一说明:

1. 合同主体和合同模板

我们公司A,委托公司B,帮我们寻找全国大的房地产中介公司(C),共同售卖在马来西亚的海外地产。因此,三方需签署一份合同,为期一年。

因此在该例中,合同主体有三方,ABC,即甲方是我们,乙方是B-委托代理公司。丙方是C-全国各大地产中介公司。所签署的合同模板是一份三方合作模板,其中列明ABC之间的关系,包括B和C对于佣金的分成等内容。

2. 签署载体或工具

作为合同签署的发起方,乙方无签署载体。丙方即全国代理公司,可以在我们的平台上(web站点或APP应用)完成签署。

3. 签署方和委托关系

上例中,甲方和乙方都是唯一的一家公司,不是变量。丙方是全国各中介公司,属于变量。因此在签署合同时,因为甲乙双方的关系非常明确,甲方和乙方可以先签署,预留丙方内容,等丙方被委托人签署即可。

丙方被委托人为在我平台上注册过的丙方负责人,举个简单例子,上海我爱我家中介公司入驻了我平台,那么该公司的店长或总经理(在入驻时,已经我平台核身,已在我平台实名认证),在产品规划角度上,我们认为其可以代表丙方完成合同签署的。

因此,合同主体三方ABC,即合同中的甲乙丙三方已经确认。在签署过程中,甲方即我平台,乙方是我找的代理商。我们两方在推送合同给丙方时,应当或已经事先签署好,再由我们敲定的丙方负责人拿到授权完成签署,那么这份合同就签署完了。

4. 签署顺序

在上例中,C拿到的待签署合同,是AB已好就等你了的三缺一合同。在产品逻辑层的解剖顺序是:平台拿着合同完成甲方自动签,成功后,再发起乙方自动签,成功后,推送给丙方完成人肉签。因此在整个流程中,甲乙方的法人代表或被委托人完全无感知,丙方需要在工具上执行一次电子签署过程,签署才算结束。

5. 合同变量和用印

本例中,合同模板里要填的内容,假如有以下7处。那么是否是变量内容我们就比较清楚了:

fetch_file55b29fc226b3e9f7e32ce18eabba82d1-picture

我们知道,一份合同,电子形式一定是一份不能随意编辑的PDF文件。那么文本内容是怎么生成的呢?一般有两种生成方式,先生成一份甲乙丙内容俱全缺少用印的合同,然后交由第三方生成PDF即可。还有一种办法,先生成空白PDF合同,再针对变量内容,写入到PDF里去。这两种方式各有利弊,前者一般用于非标合同生成,后者用于标准合同生成。本文使用的是后者。那么怎么去更改PDF中的变量值呢?

这里就要用到Adobe公司出品的一款对PDF编辑的付费软件了,Adobe pro dc。它也有7天的试用版,如果你的合同是一份标准合同,那么只要用该软件对PDF处理一次即可。

该软件支持win和OS系统,我们要用到的功能,是其对PDF可以插入文本域的功能:

fetch_file373fba37d9dae932b88cee317d17db9a-picture

使用上图的准备表单,在需要引入变量的地方插入文本域即可,并且对文本域起个名字,告诉后端该文本域的名字,及变量值即可。

下图是插入文本域后的结果,注意,文本域不能重名。并且请提前定义好文本域的样式,如左对齐,字号,字体颜色,该文本域是否必填等内容。

fetch_filedc039e4e24c5b227068d79725206bb3c-picture

做好上面的准备,保存PDF,然后交由第三方公司对该PDF进行加密处理,以后就可以当做空白模板了。

内容处理好后,就需要处理用印了。

用印内容,在模板中,我们定义好公章,章心的关键词,第三方服务通过识别关键词,会把自家的公章盖到章心位置,从而实现落印位置准确。

骑缝章一般第三方都会额外处理,只需要通过接口调用骑缝章服务,和声明骑缝章是哪方的章即可。不需要定义章心关键词。因此下表中,骑缝章没有关键词。

fetch_file6838fa4ae86cb5c73663493b70e09e5d-picture

这些章心位置是怎么生成在PDF中的?这里有个小技巧,可以在制作合同时,在word或者PDF的固定位置,插入一个文本层,然后用白色字体,并且调整到字体下方。这样就可以在PDF里存在一堆,看不到,但是确实有的章心位置了。

6. 合同签署后的逻辑

以本文为例,合同签署后,中介公司B就等于在平台上开通了权限,可以代理分销我们马来西亚的房子了。产品语言翻译:请求第三方发起签署,第三方返回签署状态后,打开该中介公司在平台中的合作关系。


通过以上的例子,从业务角度上,我们大概梳理了一份电子合同,从生成到签署的大致逻辑。但在产品实操过程中,我们还需要大概梳理一下上述流程的大概时序。有些位置的逻辑不一定遵循本文,可以根据公司业务的实际情况来展开。比如公司被委托人的授权关系,可以在该公司入驻平台时就生成好,也可以在该委托人去签署合同时为其生成。各有利弊,诸君请自行判断吧。

最后,附一份电子签需要调用的接口顺序:

1. 合同模板生成接口;

2. 企业CA生成接口;

3. 个人CA生成接口;

4. 合同生成接口(合同内容生成);

5. 自动签署接口;

6. 手动签署接口;

7. 异步消息返回接口;

包括自动签的发起,手动签的发起,骑缝章的发起,都由第三方异步消息方式通知主调方。但一般会很快;

8. 授权关系接口(包括取消授权);

当被委托人为公司签署合同时,我们需要判断下授权关系。如果该公司之前未授权过别人,即无授权关系,则新起授权即可。如果该公司之前已经有一个老负责人被授权过,则需要取消老的,授予新的授权关系。确保授权关系的干净,也便于以后纠纷后取证;

9. 合同详情查看接口;

生成过的,签署过的,或者简单说只要是合同,哪怕是空白合同,出于公平公正考虑,都应托管在第三方平台,由第三方平台完成哈希校验,以保证合同未被变动过。因此无论是哪一方想要查询合同,签署合同,都应从第三方获取。不应从本地获取。

10. 合同归档接口;

11. 个人ca更新接口;

主要是个人的手机号发生变更,需要去第三方完成手机号更新报备。

这是因为个人在签署合同时,会收到第三方平台的验证短信,根据验证码才能完成合同的签署。

12. 合同下载接口

其大概的时序图关系见下:

fetch_filecfd913f61ebfe9a772924a384d723fdb-picture

最后,从逻辑上完成了合同的签署后,我们还需要在我们的管理中心里建一个合同管理功能模块,从上述逻辑中取最重要的节点作为筛选条件,这样就可以对合同进行管理了,比如哪些中介公司有合同了,哪些还没签,签完以后什么样等等。你可以将管理中心和你的签署终端联动起来,对还未签署的合同或即将到期的合同,做一些消息提示。从而让你的客户在电子签环节中体验更好。

如果你们公司的合同多的已经造成管理上的亚历山大,或者你们公司的客户群是C端客户,并且和他们的服务过程中需要签署合同,那你不妨照我上面的示例,自己撸一撸吧。


欢迎大家关注我的知乎,附原文地址:https://zhuanlan.zhihu.com/p/30237544