宜搭能搭出回款管理吗，卡在三个地方
低代码平台搭表单这件事，门槛确实低。一个懂业务的人，半天能搭出一张像模像样的回款登记表：客户名称、合同号、期次、金额、应收日期、实收日期、备注。搭完给老板看，老板点头，觉得省了几万块。
三个月后问题来了。这张表能记，不能管。回款管理要的不只是把数记下来，是让该发生的事在正确的时间发生。三个地方卡住。
卡在结构
回款不是一个孤立的事，它挂在订单上。一个订单分几期，每期多少金额、什么时候到期、逾期怎么算，这些是结构，不是字段。表单能加列，但加不出"这一期属于哪个订单、这个订单属于哪个客户、这个客户归谁"这种层级关系。
千营的做法是订单建的时候就定收款方式：一次性收款填付款时间；分阶段收款设多个阶段及对应金额和时间。阶段是订单的一部分，不是一个独立的表。收款时在订单详情页记录实际收款时间、收款方式，原定时间和实际时间都留着，逾期几天自动算得出来。
卡在提醒
表单不会主动找人。到期该收款了，没人提醒，就得靠人记。低代码平台一般能配提醒，但要自己搭流程、配条件、设触达方式，配完之后维护的人一走，流程就静悄悄地失效了。
系统里这件事是原生的。日程类型里有"回款"这一项，是五类系统内置之一，不能改不能删。把每一期的到期日建一条日程，到期提醒，日程页的月视图上一眼能看到这个月有几笔钱要收。
卡在权限
回款数据是敏感的。谁能看全部、谁只能看自己跟的单、谁能改金额，这三层权限在表单里要么没有，要么得靠人手工维护。千营的权限有两个维度：角色决定能做什么，数据查看范围决定能看谁的数据。这两层分开，配起来清楚。
要说公道话：如果公司只是想把散在 Excel 里的回款记录集中起来，低代码平台够用，成本也低。真正需要换的时候，是老板开始问"这个月该收多少、实际收了多少、逾期的是哪几笔"——这类问题需要跨表统计，表单开始吃力。
还有一种卡法：数据越堆越沉
表单搭出来的东西，用一年会变成什么样？这是选型时几乎没人问的问题。答案是：字段越加越多，因为每次有人提需求就加一列；表越建越多，因为每件事都独立建一张；关联越来越少，因为建表的人已经离职了。
成品系统在这件事上有天然优势：结构是定死的，加字段可以，改结构不行。听起来不灵活，实际是把"想清楚"这件事前置了。做项目的公司，客户、项目、订单、回款这四层结构十年不变，不需要每年重构一次。
当然代价也在。有些行业确实有奇怪的流程，硬塞进标准结构会拧巴。这种时候低代码反而合适，因为它的目标本来就是承接非常规的流程。
两条路可以并着走
见过的稳妥做法是：核心的客户、订单、回款放成品系统，外围的、临时的、试验性的流程用低代码搭。两边各管一段，不互相拖累。
怕的是什么都想用一个工具干。低代码想管回款，管不动；成品系统想承接所有奇怪的审批，会被改得面目全非。分工清楚，两边的钱都没白花。
迁移这件事，谁都要面对
现在的客户数据在 Excel 或者表单里，换系统就得搬。搬的过程最能看出一套产品的成熟度：有没有导入模板、导入失败能不能看到明细、字段对不上怎么办。
千营的做法是给模板、按模板填、上传导入，失败了下"下载查看明细"，能看到是哪一行哪一列出错。这个细节看着小，实际决定了第一次导入能不能一次成功。没这个明细，五百条数据出错，只能靠肉眼找。
搬之前先做减法。三年的老数据里，一半是死的，搬过来只会让新系统一开始就臃肿。挑近两年有成交或有跟进的搬，剩下的留在旧表里存档。
搬完先跑一个月，别急着停旧表。
旧表留着，只读不写，三个月后再删。
判断标准很简单：能记的叫台账，能提醒、能统计、能追责的才叫管理。项目型销售CRM那页按阶段拆过回款节奏；逾期的部分怎么跟订单对上，见装备制造CRM。
