多门店零售合同系统系列之四
作者：合同吴彦祖
业务人员在外面谈了半个月，终于从合作方手里拿到一份合同。
这类合同通常不是企业自己的标准文本。
商场有商场的租赁合同，供应商有供应商的采购合同，广告公司也有自己常用的服务协议。对方把合同发过来，业务人员能谈价格、谈合作范围、谈什么时候进场，却很难独自判断几十页法律条款里藏着什么风险。
所以，合同提交以后，需要部门负责人看业务，财务看付款，法务看条款。
一路审批到法务，法务发现解除条款不对等：对方可以随时解除，我方却没有同样的权利。
法务在驳回意见里写得很清楚：该条款不符合公司要求，建议补充我方在对方违约时的单方解除权。
然后点击“驳回”。
系统里的动作到这里就结束了。
可业务人员的麻烦，才刚刚开始。
一、一次驳回，背后可能是三轮对外沟通
合同回到业务人员手里，他不能打开Word，按照法务意见改完就算了。
因为这不是我方模板，而是对方提供的合同。
合同里的每一句关键条款，改不改、怎么改，都要重新和对方商量。
业务人员把法务意见转给合作方。
对方回复：“这是我们的统一版本，不能这样改。”
业务人员只好再去找法务：对方不同意，能不能换一种写法？
法务给出第二种方案：如果不能增加对等解除权，至少要补充违约后的退款责任和赔偿责任。
业务人员又把方案发给对方。
对方内部也要找业务、法务和领导确认。过了两天，对方发回来第三种写法，只同意退还未发生的费用，不接受额外赔偿。
业务人员看不出这个方案能不能接受，只能再去问法务。
一条解除条款，就这样在双方之间来回了三轮。
等双方终于谈出一个勉强可以接受的结果，业务人员重新上传合同，再次发起审批。
部门负责人又收到一条待办。
财务又收到一条待办。
合同再次来到法务手里。
如果法务认为对方的让步仍然不够，合同还要第二次驳回。
业务人员再去找对方。
对方再回去请示。
内部审批再从前面走一遍。
表面上看，系统只是多了一次驳回。
实际上，每一次驳回，都可能带来一轮内部沟通、一轮外部谈判和一次审批重走。
浪费的从来不只是审批人的几分钟。
浪费的是业务人员和对方反复解释的时间，是法务被同一个问题一次次打断的时间，也是整份合同迟迟不能签下来的时间。
二、驳回意见写得再清楚，也不能替业务人员完成谈判
传统审批流程有一个隐藏的假设：审批人指出问题以后，发起人有能力独自把问题解决掉。
在许多内部申请里，这个假设可以成立。
报销单附件不全，发起人补上即可；采购申请数量写错，发起人改正即可。
第三方合同却不一样。
法务提出的不是一个简单的填表错误，而是对方愿不愿意让步、我方能够承受多大风险、双方最终用什么文字达成一致。
业务人员了解合作关系，却未必知道法律底线。
法务知道风险在哪里，却不一定了解这笔业务有多重要、对方有多强势。
财务关心付款和退款，部门负责人还要判断为了这项合作可以让到什么程度。
这不是发起人收到一句驳回意见以后，躲回自己的工位上改一份文件就能解决的事情。
它本来就需要几个人一起商量。
可审批系统只给了他们两个动作。
没有问题，点击同意。
发现问题，点击驳回。
至于驳回以后怎样和业务解释，业务怎样与对方谈，对方提出了什么条件，法务为什么接受最后的方案，系统通常不再关心。
流程管住了结果，却把真正决定合同能不能签下来的过程丢在了外面。
三、合同审批缺少的，不是第三种结果，而是解决问题的过程
很多人会想到，在“同意”和“驳回”旁边再加一个“协同”按钮。
按钮当然可以加。
但如果点进去只是发几条消息，它很快就会变成审批页面旁边的另一个聊天框。
真正的审批协同，不是让大家多一个说话的地方，而是让审批人发现问题以后，先不把合同退回去，而是在当前节点把相关人员组织起来，共同把问题解决掉。
法务可以直接说明：这条约定的风险是什么，公司不能接受的底线是什么，还有哪些替代方案可以谈。
业务人员既可以把对方的态度和修改意见带回来，也可以在获得授权以后，把对方指定的商务人员或者法务人员直接邀请进这次协同。
外部人员不需要进入企业的组织机构，也不能看到整条内部审批路线。他们只在被授权的范围内查看相关合同内容、回应条款意见、提交修改建议。
原本需要业务人员来回转述的问题，可以由双方法务直接把风险和修改方案讲清楚。涉及企业内部底线、风险判断和审批意见的内容，则仍然只在内部人员之间可见。
已经审批过的部门负责人和财务也要进入协同。谁需要参与讨论，可以根据问题决定；但合同在他们审批以后发生了修改，修改过程和最终结果必须让他们看到，并由他们自己确认是否影响原来的审批结论。
如果讨论涉及预付款、退款或者费用承担，财务需要直接提出意见；即使表面上只修改了法律措辞，财务也应当看到最终结果，并确认自己的原审批意见是否仍然有效。
大家讨论的仍然是同一份合同。
法务提出了什么意见，业务怎样判断，对方怎样回应，双方讨论过哪些方案，企业最后为什么接受，全部围绕这次审批保留下来。
问题解决以后，发起人、当前审批人和已经审批通过的人都确认没有异议，合同才能从当前节点继续向后审批。
这才是协同存在的意义。
它不是替代审批。
它是在审批作出最终决定以前，先给大家一个共同解决问题的机会。
四、如果法务没有立即驳回，事情会怎样发展？
还是前面那份第三方合同。
合同已经经过部门负责人和财务，现在停在法务节点。
法务发现解除条款不符合公司要求，没有立即点击驳回，而是在当前审批节点发起协同。
系统先把发起人拉进来。
法务不只留下一句“条款有风险”，还把意见说完整：问题出在哪里，公司理想的修改方案是什么，如果对方不接受，最低可以谈到什么程度。
业务人员可以拿着这个边界去找合作方，也可以给对方指定人员开通本次协同的外部权限。
对方第一次不同意，可以直接在协同中说明理由；如果对方仍然习惯通过线下沟通，业务人员也可以把沟通结果补充进来。
法务根据对方反馈给出替代文字。
对方第二次提出折中方案，双方法务可以围绕同一条款继续讨论，不再让业务人员承担专业法律意见的反复转述。
如果折中方案可能影响合作价值，部门负责人就在协同中表达意见；如果涉及退款和付款责任，财务也参与确认。
不需要业务人员在企业法务、内部审批人和对方人员之间来回传话。
也不需要法务每隔两天重新回忆一次，这份合同上次谈到了哪里。
所有意见都围绕当前问题连续积累。
等到法务认为风险已经控制，业务确认对方能够接受，所有已经审批通过的人也看过最终处理结果并表示没有异议，协同结束。
法务在当前节点完成审批，合同继续向后走。
这期间，合同可能修改了几次，对方可能来回反馈了几轮，但审批流程没有因为每一次谈判都退回起点。
问题一直留在发现问题的地方。
相关的人一起把它解决，然后继续向前。
五、真正的合同协同，应该长成一个什么样的工作区？
上面的故事如果只停在这里，协同仍然只是一种听起来很美的处理方式。
法务不驳回，大家留在当前节点共同解决问题——道理很容易理解，真正难的是系统怎样把这件事接住。
谁来参加？
在哪里看合同？
意见落在哪里？
对方又发回来一份文件怎么办？
谁已经表态，谁还没有确认？
最后由谁结束讨论，把合同送回审批？
这些问题没有答案，“发起协同”就只会变成审批页面上的第三个按钮。点进去以后，大家仍然回到微信、邮件和Word里做事。
所以，一场协同被发起以后，系统首先要建立一条正式的协同事项。
它有自己的名称、发起人、当前状态和协同轮次，也关联着正在处理的合同文件。法务可以按照状态查看哪些事项仍在进行，业务可以按照发起人查找自己负责的谈判，管理人员也可以看到每场协同有多少参与人、产生了多少条意见、最后一次更新发生在什么时候。
这一步看起来只是多了一张列表，实际上是把原来散落在聊天软件里的合同讨论，第一次变成了可以查找、可以跟踪的工作事项。
【截图位置1：协同列表页面】
建议展示：协同名称、当前轮次、进行状态、合同文件、参与人数、评论数量、更新时间，以及按照状态、发起人和评审人筛选的区域。
从列表进入一场协同以后，画面中间应该是正在审阅的合同正文，而不是一块空白的聊天区域。
参与者可以在线打开合同，查看完整内容，必要时直接编辑文档并保留修订。页面旁边则是与这份合同对应的评审区域，参与人员、评审意见、协同信息、版本和操作记录都围绕同一份文件展开。
大家不再一边翻Word，一边切回微信寻找法务说的那句话。
合同在哪里，意见就在哪里。
【截图位置2：协同工作区全景】
建议展示：页面上方的当前轮次、参与人、分享、上传新版本和定稿操作；中间的在线合同正文；右侧或旁侧的评审管理区域。尽量截出“合同是协同中心”的整体结构。
法务发现解除条款有问题，可以直接选中或者引用对应原文，在这段文字旁边发表评审意见。
这条意见不再只是“合同不符合要求”，而是与具体合同内容绑在一起。其他人点击意见，可以直接跳回原文，不必先在十几页合同里寻找法务说的是哪一句。
业务人员可以在意见下面回复，也可以@对方商务、对方法务或者已经审批过的同事。对方提出新的解释，法务继续回复；财务发现这条约定还涉及退款，也可以直接加入讨论。
每条意见都有自己的状态。
还没有谈妥的，继续保持“未解决”；已经形成一致意见的，标记为“已解决”；等待某个人表态的，可以进入他的“待我确认”；在几十条讨论中被@的人，也能直接筛出与自己有关的内容。
这样，协同面对的就不再是一串混在一起的聊天记录，而是一组围绕具体合同原文、可以逐条处理的评审问题。
【截图位置3：评审意见与原文关联页面】
建议展示：一条引用了合同原文的评审意见、回复与@人员，以及“全部、未解决、已解决、待我确认、@我的”等筛选项。如果一张图放不下，可以拆成“意见关联原文”和“意见状态筛选”两张。
参与者也不是简单地被拉进一个群。
系统可以从企业组织架构中邀请内部评审人，也可以通过授权和分享方式邀请外部人员。不同参与者拥有不同权限：有人只能查看，有人可以参与编辑和提交评审，有人负责最后定稿。
外部人员进入的是这一场协同，而不是企业整套合同系统。他看到什么、能够做什么，应当由本次协同授予的权限决定。
谁是发起人，谁是内部评审人，谁来自合同相对方，每个人拥有什么权限，都应该在参与人员页面中清楚显示。
【截图位置4：评审人员与权限页面】
建议展示：邀请评审人入口、内部人员和外部人员的身份区分，以及“仅查看、可编辑、可提交评审、可定稿”等权限。若邀请外部人员通过分享链接完成，可同时补一张分享设置截图。
合同正文也不能在协同中失去控制。
参与者在同一个工作区里审阅和修改文档，需要对方重新提供文件时，可以上传新版本；原始送审版本继续保留，后续版本按照产生顺序记录，不能用一句“最终版”把前面的过程全部覆盖。
版本管理中可以看到原始版本、当前可编辑版本、上传人、上传时间和所属协同轮次。需要进一步判断文字变化时，再进入版本对比——这一部分，我们放到下一篇单独展开。
【截图位置5：协同版本管理页面】
建议展示：原始版本、最新版本、版本编号、上传人、上传时间、当前协同轮次，以及“原始版本不可编辑”“当前版本可编辑”等状态信息。
讨论结束以后，每名评审人还要提交自己的评审结果。
发表过评论，不等于已经同意最终方案；在群里说过“可以”，也不等于完成正式确认。评审人需要针对本轮合同明确提交意见，系统才能知道谁已经完成、谁还没有表态。
所有应当参加的人完成评审后，拥有定稿权限的人才能结束本轮协同，把讨论形成的合同确定下来。
如果合同发给对方以后，对方又提出新的条件，可以基于同一场协同发起下一轮，而不是重新建一个群、重新发一套文件。上一轮讨论了什么、由谁确认、为什么进入下一轮，仍然能够前后接上。
谁邀请了评审人，谁上传了新版本，谁提交了意见，什么时候进入下一轮，又由谁完成定稿，这些动作还要进入操作日志。
协同结束以后，企业不只能看到最后那份合同，也能还原这份合同是怎样被讨论、修改和确认出来的。
【截图位置6：协同信息与操作日志页面】
建议展示：协同编号、状态、轮次、参与人数、评论数、版本数，以及创建协同、邀请评审人、上传版本、提交评审和定稿等操作记录。可以用两张截图分别展示“协同信息”和“操作日志”。
最后，这个协同工作区不应该成为合同系统之外的另一座孤岛。
它可以作为独立组件嵌入合同审批页面。审批人点击“发起协同”，合同系统把当前合同和参与人员带进协同；邀请评审、增加评论、上传版本、全部评审完成、发起新一轮和最终定稿等关键事件，再返回合同系统，推动原来的审批流程继续运行。
从用户的视角看，他仍然在处理同一份合同。
从系统的视角看，审批负责决定合同能不能继续，协同组件负责让这群人在决定以前，把问题真正谈清楚、改清楚并确认清楚。
这才是一套可以落地的合同协同能力。
不是在审批旁边加一个聊天框。
而是把合同正文、评审意见、参与人员、权限、轮次、版本、评审结果和最终定稿，放进同一个受控的工作区。
六、已经审批过的人，要么参加协同，要么重新审批
合同审批有一个不能跳过去的事实。
每个人点击“同意”，同意的都是当时看到的那份合同。
部门负责人同意的是原来的合作条件，财务同意的是原来的付款安排，区域负责人同意的也是原来的门店方案。
合同走到法务以后又被修改，哪怕表面上只改了一句话，前面那些人的审批依据也已经发生了变化。
系统不能替他们判断：“这次只改了法律条款，与你无关。”
法务也不能替财务判断：“付款条件没有变化，你不需要知道。”
因为一条解除条款可能牵出退款，一条违约责任可能增加费用，一处看似纯粹的法律表述，也可能改变前面审批人对风险的判断。
真正有权决定原审批意见是否仍然有效的，只能是审批人自己。
所以，发起人、当前审批人以及所有已经审批通过的人，都要进入这次协同。
进入协同不等于每个人都要从头审一遍合同，也不等于所有人都要参加每一轮讨论。
法务和业务可以负责主要谈判，涉及付款时财务直接发表意见，涉及合作范围时部门负责人参与判断。其他已经审批过的人可以关注过程，并在最终方案形成以后确认没有异议。
他们可以少说话，但不能完全不知道合同后来发生了什么。
如果企业决定不把某位前序审批人拉进协同，那么合同修改完成后，就必须重新流转到他那里，让他针对修改后的合同再作一次审批。
只有这两条路。
要么参加协同，看过修改过程和最终结果，明确表示没有异议。
要么不参加协同，在合同修改完成以后重新审批。
不能既不让他参加协同，又沿用他对旧合同作出的审批结果。
协同真正节省的时间，不是把前序审批人悄悄绕过去，而是让他们在问题处理的过程中就获得信息。等方案确定以后，他们只需要确认结论，不必等合同被驳回、重新提交，再从头走一遍审批。
对方人员则是一类特殊的参与者。
他们不是企业员工，不能因为参与一次合同讨论，就看到企业内部的风险判断、领导意见和其他合同。系统需要为这次协同单独授权：允许他看哪一份合同、哪几个条款、哪些公开意见，可以回复什么、能否上传文件，以及权限什么时候失效。
同一场协同中，也应当区分“双方可见”和“仅内部可见”。需要与对方谈判的条款意见，可以公开给外部参与者；企业能够接受的最低条件、审批人的内部判断和责任意见，则只留在企业内部。
把外部人员拉进来，是为了减少传话和误解，不是把企业内部审批过程一起暴露出去。
内部审批人的责任不能被跳过，外部参与者的权限也不能没有边界。
只有把这两件事同时处理好，协同才会比驳回更快，也不会因为追求效率而丢掉责任。
七、协同意见必须留下来，而且不能被事后改成另一种说法
现实中，很多合同其实也在“协同”。
法务在Word里写批注，业务把文件发给对方；对方通过微信回复，业务再把聊天内容转给法务；部门负责人打来一个电话，说这次合作很重要，可以适当让步。
大家确实讨论过。
但这些讨论散在不同地方。
Word里的批注可能在对外发送时被删掉，微信聊天只留在业务人员手机里，电话里的决定甚至没有任何记录。
半年以后合同出了问题，再问当时为什么接受这条约定，每个人都只能凭记忆回答。
有人说法务同意了。
法务说自己只是给过一个备选方案。
有人说领导要求先把合同签下来。
领导说自己当时只了解大概情况。
所以，审批协同至少要留下几类记录：谁提出了什么问题，给出了哪些处理建议，业务作出了什么判断，对方人员怎样回应，最后采用了什么方案，以及哪些相关人员表示没有异议。
外部人员的姓名、所属单位、参与时间、授权范围和实际操作也要留痕。以后再看这份合同，企业才能分清哪些是内部意见，哪些是对方的正式反馈。
这些内容一旦形成正式意见，就不能被悄悄删除或者改成另一种说法。
允许补充，允许继续讨论，也可以更正自己的表达。
但原来的意见、补充的时间和最终结论都应该保留。
这不是为了将来追责方便。
而是因为合同本来就是许多人共同判断、共同取舍以后形成的结果。
系统应当把这个形成过程保存下来。
八、协同不是绕过审批，重大变化仍然要重新判断
协同能够减少不必要的驳回，却不能成为绕开审批的捷径。
如果双方只是调整法律表述，没有改变原来的商务条件，所有已经审批通过的人看过处理结果并确认没有异议后，流程可以从当前节点继续。
但有些谈判结果，会直接改变原审批结论成立的基础。
合同金额从80万元谈到150万元，原来的审批权限可能已经不够。
付款方式从验收后付款变成预付，财务必须重新作出判断。
服务范围从一家门店扩大到一百家门店，合同影响已经完全不同。
签约主体发生变化，原来围绕主体作出的判断也不能直接沿用。
遇到这些情况，系统应当根据变化重新确定需要谁审批、从哪个节点重新确认。
该补充审批人，就补充审批人。
该回到财务，就回到财务。
确实需要重新发起，就重新发起。
协同解决的是“一个可以商量的问题，为什么非要先把流程打回去”。
它解决不了，也不应该掩盖合同条件已经发生根本变化的事实。
九、协同能力有没有价值，看一份合同少来回多少次
判断审批协同做得好不好，不应该看系统里产生了多少条消息。
应该看同一个问题少驳回了几次，业务人员少在内部和外部之间传了几次话，双方法务少产生了多少误解，前序审批人少被迫重新走了几遍完整审批，合同又提前了多少天签下来。
传统审批把每个审批人当成一道关卡。
没有问题，开门放行。
发现问题，关门退回。
可第三方合同不是企业自己关起门来写的文件。
它是双方一点点谈出来的。
法务发现风险，可以和业务以及获得授权的对方人员一起谈；对方不接受，法务继续给出新的方案；方案影响付款，财务直接参与；方案影响合作，部门负责人也要表态。即使没有直接参与每一轮讨论，已经审批通过的人也要看到最终结果并确认没有异议。
这个过程中，企业真正需要的不是更多次驳回。
而是让应该参与的人，在问题发生的时候一起把问题解决。
意见可以不同。
合同可以继续谈。
对方也可以来回几轮。
但内部审批没有必要跟着每一轮谈判一起从头再来。
大家没有异议以后，合同继续向前。
流程没有被无意义地重走。
每个人的意见和责任，也都留了下来。
我是合同吴彦祖。
下一篇继续讲另一个问题：合同谈了五六版，系统怎样保证最后签署的是正确版本？
