合同签得漂亮，执行时却找不到收款依据
一、一个怪现象：合同越签越厚，能伸手的地方越少
这几年项目型生意有个耐人寻味的变化：合同越做越精致。法务参与得越来越早，条款一页页加厚，违约后果写得明明白白，连附件都编了好几册。细看那些厚厚的合同，动词很多，落点很少，保护条款与执行着力点之间隔着一整片空白。
可奇怪的是，合同变厚了，执行时能伸手要钱的着力点反而没变多。财务那边应收照样挂得老高。
原因说来不复杂。合同厚的是保护性条款，薄的是执行性依据。写得清楚的是你不付我要追究，写不清楚的是你什么时候该付、凭什么付。前者是闹翻时才用得上的武器，后者才是平时推动款子流动的手柄。
- ● 条款写了按阶段付款，可每个阶段的完成标准散落在技术附件里，前后对不上；
- ● 写了以验收为准，可验收的流程、参与人、时限一个字没提；
- ● 写了资料齐全后付款，可资料指什么。双方的理解差了十万八千里。
于是执行现场常常出现这样的对话：销售说合同写了这一段该付了，客户说你们东西还没交齐；交付说东西早就交了，客户说交是交了，没人说认可了。每个人手里的依据都不完整，款子就在这些缝隙里安静地躺着。武器再多，平时用不上，款子还是躺在那儿。
谈判桌上的口头默契还常常是压垮执行的那根稻草。当时双方聊得投机，一些关键口径只落在饭桌上，没落进文本；等对接人一换，那些默契就像从没存在过。说到底，口头默契靠不住，不是人心不可靠，而是记忆本身留不住细节。
二、依据断在哪儿：断在做完与认可之间
项目型交付有一条天然的裂缝：乙方眼里的完成，是技术意义上的做完；甲方眼里的完成，是商业意义上的认可。这两个完成之间隔着一道手续，确认。款子依据断掉的地方，几乎都在这道手续上。确认这道手续，说轻不轻，它是商业世界里的交割动作，交割没完成。交易在账面上就始终悬着。
拆开看，断点无非几类。
- ● 成果交了，但没约定谁来认可、按什么标准认可，客户内部推来推去没人接；
- ● 认可做了，但只是会上口头点了头，会后没人留痕，人事一变动就翻不了账；
- ● 留痕有了，却躺在某个人电脑的文件夹里，发起收款时根本找不到；
- ● 各段成果之间没有先后关联，前面没确认，后面照干不误。窟窿越干越大。
这几类断点有一个共同根源：合同里只写了付款的条件，没写证据的生成方式。条件是静态的，证据是动态的，动态的证据没有流程托着，就会随时掉在半路。
所以真正要补的不是合同的厚度，而是依据的链条：每一段款子前面，都得摆出一份无可争议的认可记录。这个链条搭起来了，要钱的对话就从我觉得，变成你看这里。链条的每一段都要有人签字、有处可查、有据可依。缺一样都算断。
三、把交付物变成收款的语言
想让依据不断链，最有效的办法是让交付物直接开口说话，每一份关键成果。出厂时就自带收款信息。这不是修辞，是可以落地的做法。
- ● 需求规格确认书：客户签字的那份文件，页眉就关联对应的收款安排；
- ● 原型与设计稿：评审通过的动作完成，系统里同步生成付款申请的待办；
- ● 测试与试运行报告：报告归档即视为条件达成，开票流程自动接续；
- ● 培训与移交清单：最后一批移交物签收，尾款的申请依据同时归档。
这样做的好处是双边的。对乙方，收款不再依赖某个人的记忆和人情，文件走到哪，钱跟到哪；对甲方，付款变得理直气壮，每一段都对得上看得见的东西，内部审批也好过关。往实里说，对上对下都交代得过去，这四个字值很多力气。
许多项目负责人的体会是：把依据备齐之后，客户方反而推着流程走，因为他们的审批人同样要看依据，依据齐整的申请单走流程，比含糊的口头请求快得多。
谈判阶段就要把这层逻辑铺进去。报价时把成果清单和付款安排放在一起谈。让客户习惯见物付款的口径。谈的时候多花的心思，都会在执行时变成顺滑。
图1：签约前把交付口径谈透，执行时才有据可循
图2：跟进看板里随时能看每段款子的前置条件
四、绑定之后，执行现场会发生什么
把成果与收款绑成一条链之后，日常执行的画风会明显不同。
- ● 项目例会上讨论的不再是款子差不多了吧，而是确认书还差谁的签字；
- ● 交接不再靠长长的表格，新接手的人打开项目就能看到每段款子的出处；
- ● 财务开票不再打电话到处问，条件达成的消息会自动送到面前。
有一家做行业软件实施的企业经历过这个转变。过去每逢阶段小结，商务和交付总要为到底怪谁争上半天；绑定之后，争论消失了，因为每一段款子的前置动作都写着名字，掉链子的位置一目了然。
这印证了那个朴素的道理：说不清的事才会争，说得清的事只会办。后来他们开会讨论的议题都变了，从追究情绪变成了疏通流程。
当然，绑定不是把客户当对手防范，而是给双方共同的确定性。甲方内部同样有预算与审批的纪律，一份干净的认可记录。恰恰是他们最需要的东西。你以为在保护自己，其实也在成全对方。
再往深一层说，绑定还悄悄改变了团队的习惯：交付的人开始关心商务口径，商务的人开始关心成果状态，因为链条上彼此的动作看得见，谁也不好意思只扫门前雪。
五、让绑定长在系统里，而不是停在制度里
道理不难懂，难的是让每个项目都照做。靠制度宣讲、靠自觉、靠定期检查，最后总会松掉。可靠的办法是让绑定长在系统里，比如用海软CRM把每份关键成果与对应的收款条件挂接起来，成果归档即触发后续动作。条件达成即生成申请依据。
系统里的绑定，有几个手工表格给不了的特性。
- ● 强关联：成果没有归档，后面的申请流程根本发起不了，想跳步都跳不过去；
- ● 全留痕：谁在什么时候点了确认，记录改不了也赖不掉；
- ● 可视化：哪个项目的哪一段卡在哪个动作上，看板上一眼见底。
制度写在纸上，约束的是愿意遵守的人；规则长在系统里，约束的是所有流程的参与者。项目型企业的收款管理，缺的从来不是道理，而是让道理必然发生的那个装置。装置一旦装上，运转的成本极低，而它拦下的扯皮与遗忘。价值远超搭建的心思。
商机跟进的过程里每推进一步，对应的款子状态就同步一步。商务与执行从此共用同一份事实。
合同签得漂亮只是上半场，执行时每一步都有出处，才是真正体面的做法。
六、这些问题是问得最多的
1、问：老合同没做绑定，存量项目怎么办？
答：存量项目可以补一份执行备忘，把剩余各段成果的确认方式与收款对应关系约定清楚，再录入系统里跑。补绑之后新老项目的口径一致，管理才有连续性。不必追求一步到位，先把金额靠前、时间最近的几段绑上，边跑边补。老项目最怕的不是条款糙，而是谁也说不清现在卡在哪，补绑的价值就在把位置说清楚。
2、问：客户不愿意配合签字确认，怎么办？
答：先弄清不配合的原因。多数时候不是故意刁难，而是对方内部也没想好谁来认这件事。可以在谈判阶段就把确认人、确认方式写进文本，并建议对方指定唯一的接口人。把确认动作做得轻一些，线上点选即可完成，别让配合的代价太高，意愿自然会上升。
3、问：交付物种类太多，全都绑定吗？
答：不必。绑定的是关键成果，也就是那些直接对应收款条件的少数文件。过程性的内部文档、中间版本、会议纪要，留在项目管理里即可。抓大放小，一条链上只放真正起作用的几处，链条才清晰可用。链条越干净，执行的人越愿意用。什么都绑，等于什么都没绑，执行者很快就会麻木。
4、问：绑定后客户拖延确认，反而把节奏拖慢了吗？
答：恰恰相反。没有绑定的时候，拖延是弥散的，谁也说不清卡在哪；绑定之后，拖延被钉在具体的动作上，可以点名、可以升级、可以在例会上摆出来。看得见的拖延比看不见的拖延好治得多。再把超时提醒配上，大多数卡点会在升级之前就化掉。制度的作用是把偶然的顺利变成必然。
5、问：这套做法对小项目也适用吗？
答：适用，而且越小的项目越需要。小项目利润薄，尾款一旦沉底就伤筋动骨。小项目可以简化绑定，只留启动、中期、收尾三处动作，每处对应一份确认。麻雀虽小，链条齐全，照样能让依据不断。规模决定的只是链条的长短，不该决定有没有链条。
