合同归档
合同签订后由运营人员扫描、存档和管理；权限人员需要调取电子档时仍依赖运营人员查找和传递。
项目案例 02 · 合同 / 应收 / 回款管理
从合同归档到
销售回款
把分别推进的合同归档、应收账款和销售回款检查重新连接起来，形成从合同生效到到账核销的端到端业务流程方案。
- 本人在案例中的真实角色
- 参与三个模块的实际推进，在应收账款系统化中独立完成业务字段表、PRD和流程图；参与回款动作、证据、权限和检查规则设计，并试用演示版与测试版、反馈问题。
3个模块历史上分别推进
1条链路合同到回款闭环
8个节点端到端流程设计
4类边界程序、规则、人工与AI
01 / 原有现场
三个岗位各管一段，业务却属于同一条链路
合同、应收和回款动作并不是三件彼此独立的工作。流程被拆开后，材料、付款节点和执行证据难以形成连续追踪。
应收管理
合同约定的付款金额和时间进入应收跟踪，但付款节点、项目资料和应收状态之间缺少统一关联。
回款检查
有应收项目需要销售执行回款动作并提交证据，检查人员再依据制度判断执行是否达标。
历史状态：三个模块在原企业中分别由不同人员负责，也作为不同功能分别推进，并未在同一系统中完整联动。
02 / 关键洞察
合同归档不是终点，而是应收和回款管理的起点
合同签订后，应当立即形成付款节点和应收计划；存在应收时，再触发责任人的回款动作、证据检查和异常升级。
- STEP 01
合同上传
建立合同、客户和项目关联。
- STEP 02
付款拆解
记录金额、比例和计划付款日期。
- STEP 03
应收生成
形成待收节点和当前应收状态。
- STEP 04
到期提醒
向对应销售或项目负责人发出提醒。
- STEP 05
回款执行
按制度执行沟通、拜访或蹲点动作。
- STEP 06
证据检查
由管理人员检查动作和证据是否达标。
- STEP 07
到账核销
财务确认到账并关闭对应应收节点。
- STEP 08
异常升级
逾期、动作不足或争议进入升级与申诉。
03 / 责任边界
哪些交给程序，哪些必须保留人工判断
流程整合不等于把所有决策自动化。确定性动作由系统执行，高风险判断仍由有权限的人负责。
程序规则
日期计算、金额校验、状态变化、节点提醒、权限和必填检查。
业务规则
回款动作标准、证据要求、达标条件和升级条件。
人工判断
证据真实性、特殊情况、申诉、绩效和管理决策。
AI可选能力
合同字段提取、回款进展摘要和异常原因解释。
AI不替代财务到账确认、证据真实性判断或管理决策。
04 / 个人贡献
既参与过局部改造，也能重新理解完整链路
案例价值不在于宣称独立开发系统，而在于能够把业务现场、字段规则、流程要求和后续方案连接起来。
把业务要求转成系统需求
发现合同调取依赖单一运营人员的问题，提出电子档上系统与权限查询需求；参与应收系统化，独立制作业务字段表、PRD和流程图；深度参与回款动作、证据要求、权限和检查规则设计；参与演示版与测试版试用反馈。
把三个模块整理成一条链路
识别三个模块本质上属于同一条业务链路，并将合同、应收、执行检查、到账核销和异常升级整理为一套端到端方案。
05 / 方案价值
真正的改造，是让信息和责任连续流动
不是简单地把三张表搬进系统，而是让每个付款节点都有来源、负责人、执行记录和处理结果。
- 减少合同扫描件反复查找与人工传递
- 把合同付款约定转成可跟踪的应收节点
- 让销售回款动作与具体应收项目关联
- 让负责人查看执行证据、异常原因和处理状态
- 保留人工判断与申诉机制，避免系统越权
06 / 证据边界
真实参与和后续方案，必须明确区分
合同归档、应收账款和销售回款动作检查在原企业中分别推进。本页端到端流程是基于本人真实参与经验形成的复盘整合方案，不代表三个模块当时已经在同一系统中完整联动或整体上线。