复杂服务型合约的多层任务执行模型：从场景拆解到五层数据结构

代账公司、会计师事务所、检测机构、IT运维服务商，这类企业有个共同点：卖的不是货，是"分多次、由多人、长期执行"的服务。合约签下来的那一刻，麻烦才刚开始——服务怎么拆、任务怎么派、进度怎么盯、钱按什么节奏收、执行人怎么算提成，五件事缠在一起，常见的订单模型到这里就开始吃力。

这篇内容整理自超兔一体云团队的一轮业务建模复盘。我们在给服务型企业客户梳理服务合约管理时，把"复杂服务型合约"的多层任务执行模型完整推演了一遍，下面把推演过程摊开来讲，供做业务系统设计的同行参考。

先把场景看明白

一家代账公司签下一笔年度合约，里面装着多项服务产品：月度代账、年报审计、税务申报。每一项都是客户实打实购买的东西——只不过属于服务型产品，以执行、行动、待办的方式交付，本质上仍然是产品。

复杂度藏在细节里。月度代账买了十二期，一年十二次交付；一项服务可能要三到四个人接力跟进；执行中途还会换人。财务月底要算提成，老板随时想知道两件事：哪些服务还没派出去，派出去的做到哪一步了。

把客户的核心诉求列出来，其实就三条：

• 哪些服务产品还没有派发；
• 已派发产品的执行进度到哪一步了；
• 按月对执行完成的部分，给参与的每个执行人核算提成。

这三条看着简单，落到数据模型上，每一条都要动结构。

实物订单的建模思路，为什么装不下服务合约

传统CRM的订单模型围绕实物商品设计：品名、型号、SKU、数量、单价，签单后走发货、出库、回款。这套结构处理"一手交钱一手交货"的生意没有问题，问题出在服务合约上——服务没有SKU。

一种常见的将就做法，是把服务的每次执行当成一条"任务"手工登记，或者建个分组把任务归拢起来集中管理。跑一阵子就会发现：任务和合约对不上账，换人之后历史记录散落各处，月底算提成靠人工翻记录。说白了，把服务当"任务"管，管住的只是过程流水；把服务当"产品"管，才管得住交付承诺。

我们认为，核心在于换一个本体：合约里的每一项服务，都应该被建模成"服务产品"这个实体，而不是任务清单。产品决定谁来做、做什么、做多少次、按什么顺序做、什么时候开始做。想通这一点，后面的结构就顺了。

模型怎么抽象：五个主体，五层结构

沿着"合约—产品—期次—待办—记录"这条线，场景里的所有角色可以收进五个主体：

三处关系容易建模出错，值得单独说。

合约与服务产品是1:N。产品是合约对客户的交付承诺，管理目标始终以合约为中心，但驱动执行的是产品。

期次与待办是1:N，而不是共享。每期要有自己独立的一套待办，不能十二期共用一张任务清单——否则第一期做完勾掉的任务，第二期就没法做了。

待办与执行记录是1:N。一个待办往往要拖好几天、来回多次操作，执行记录就是这期间的流水，日期、内容、执行人都要留痕。

把这五层再往通用里抽象一层，就得到一套可以跨业务复用的映射：合同→交付计划→交付批次→交付任务→执行记录。代账叫"期次"，检测机构叫"批次"，IT运维叫"巡检周期"，叫法不同，结构同构。

容易被低估的一层：服务产品本体

五个主体里，服务产品是核心实体。若产品的实体和属性不清晰，整个业务逻辑都无法立足——这不算夸张，因为产品决定了一切下游行为：

• 产品决定负责人：谁执行，写在产品上；
• 产品决定待办任务：做什么行动事项，由产品定义；
• 产品的期次决定待办数量：买六期生成六套待办，买三期生成三套。

因此，合约是管理主体，产品是驱动主体。

关键在于，服务产品的核心属性不是品名、型号、SKU，而是围绕"服务交付"定义的一组业务属性：

其中WBS结构值得多说两句。部分服务必须按固定顺序执行：票据没收集完，凭证录不进去；凭证没审核，报表出不来。这意味着待办之间存在前后依赖，前序未完成，后序不可启动；而任务拆分规则是预定义的模板，不同产品类型对应不同模板。WBS结构是产品的内在属性，不是执行时临时编排的东西。

交付日期与提醒逻辑也一样。某项服务预计10月8日交付，执行至少需要两周，那么9月24日就该自动创建提醒待办——提醒时间不是人工设定的，是由交付日期和执行周期两个属性推算出来的。这让"定时分发待办"有了明确的数据依据。

用一张树形图把服务产品的结构画出来，大致是这样：

服务产品（含WBS结构）
├─ 负责人：张三、李四
├─ 期次：12期
├─ WBS 任务分解
│   ├─ 1. 收集票据（前置）
│   ├─ 2. 录入凭证（依赖1）
│   ├─ 3. 审核校验（依赖2）
│   └─ 4. 出具报表（依赖3）
├─ 交付日期与提醒
│   ├─ 第1期交付日：1月15日 → 提醒：1月1日
│   ├─ 第2期交付日：2月15日 → 提醒：2月1日
│   └─ ……

五层数据结构全景

把五个主体叠成完整的树，就是这套模型的数据结构主干：

合约
├─ 服务产品1（单期）
│   ├─ 负责人（1个或多个）
│   └─ 第1期（交付日：1月15日）
│       ├─ WBS待办1：收集票据
│       │   ├─ 执行记录1.1：01-05 联系客户获取票据
│       │   └─ 执行记录1.2：01-06 收到票据扫描件
│       ├─ WBS待办2：录入凭证（依赖#1）
│       │   └─ 执行记录2.1：01-08 完成凭证录入
│       ├─ WBS待办3：审核校验（依赖#2）
│       └─ WBS待办4：出具报表（依赖#3）
├─ 服务产品2（多期，如十二期）
│   ├─ 负责人（3~4人参与）
│   ├─ 第1期（交付日：1月15日）→ 待办 + 记录（如上）
│   ├─ 第2期（交付日：2月15日）→ 待办 + 记录（如上）
│   └─ ……
└─ 服务产品3

这里有个容易被忽略的认知：期次是产品与待办之间的桥梁层。产品决定做什么，期次决定做几次。判断一个系统的服务合约建模是否到位，看期次这一层就够了——凡是让所有期次共享一套待办的，第二期交付时一定出问题。

单看某个WBS待办的执行留痕，就是一条时间线：01-05联系客户获取票据，01-06收到票据扫描件，01-08凭证录入完成。执行人换了，记录跟着待办留在原地，追责和提成都有据可查。

模型要落地，系统需要三种能力

结构定了，系统能力跟着结构走。这套模型跑起来，依赖三件事。

快速数据记录。执行人要能低门槛录入交付进度和行动记录，操作成本一高，数据就断档，后面的进度分析和提成核算全部失去依据。

自动分发待办。产品属性里写着负责人，系统据此自动创建交付任务并派发，不让主管手工指派。产品决定谁来做，系统替人跑腿。

定时分发待办。产品的期次和交付日期定了，提醒时间就是推算出来的：10月8日交付、执行需两周，9月24日自动建提醒待办。到期自动触发，不靠人记。

单合约总控视图：管事、管钱、管人

数据结构是骨架，用户真正使用的入口是单合约总控视图。它的目标一句话能说清：以一份合约为入口，在同一视图内实现管事、管钱、管人。

逻辑线分四步：合约头部总览建立全局认知，按产品分组管控执行，关联交付计划管应收回款与费用，按执行进度核算激励。

模块一，合约头部总览。第一屏放两类信息：合约基础信息（甲乙方、签约时间、有效期、合约总金额），加财务总览（总应收、已回款、待回款、总执行费用）。管理者进来十秒钟建立判断。

模块二，产品执行管控。这是核心操作区，每个产品一张卡片：产品信息、期次进度、每期独立的待办列表、待办下的执行记录、负责人及历史变更、交付提醒与逾期标识。前面说的五层结构，在这里一屏摊开。

模块三，应收回款与执行费用。让钱和事不脱节的关键设计是：应收跟着产品的期次走，回款与应收做成多对多核销——一笔回款可以核销多笔应收，一笔应收也可以分多次回款核销，两边独立记录，通过核销关联建立匹配。执行费用单独归集，挂到具体产品上。

模块四，激励核算。按产品执行进度自动算各执行人应得份额：执行人、关联产品、完成期次、激励比例、应得金额、核算周期（按月汇总）。月底出提成报表时，数据从执行记录一路自动汇上来，不再人工翻聊天记录。

用一个具体快照感受一下（合约有效期2026年1月至12月，截取6月末状态）：月度代账12期完成6期，1~6期应收已全额回款，7~12期待回款；年报审计尚未启动，待办全部待开始；本月提成张三1200元、李四800元，王五因审计未启动暂无。事、钱、人在一个视图里对得上，这个模型才算闭环。

这套模型在CRM里的承载

落回产品层面，CRM的合同订单管理中心对服务型业务有专门的承载方式：服务型交易用合同和合同视图管理，合同之下配套合约交付计划和回款计划，把"事"和"钱"挂在同一份合同上。

财务侧由智能应收引擎衔接：签约、开票、发货均可触发应收，自动拆分多期，金额与百分比双向计算；选择"合约金额-回款"算法时，保存合同订单会弹出智能新建回款计划的界面。回款到账后，一条回款记录可以智能匹配多个回款计划，自动拆分出未回部分，应收与回款两边联动，避免两本账。

执行侧用行动记录和待办任务衔接：执行人的跟进行动可一键转待办，派给自己或同事；人员变更时，历史记录跟随产品留在原地，不散落。

至于按期次核算提成，在这套模型里属于激励层的设计目标——执行记录和完成期次已经沉淀为结构化数据，核算规则就有了可靠的取数来源。

方法小结：把复杂合约建模拆成四步

这套推演过程可以抽成一个通用方法，不只服务合约适用。

业务到数据的四步映射：

三条铁律：

• 合约是管理主体，产品是驱动主体，下游行为一律从产品属性推导，不做人工二次录入；
• 期次是产品与待办之间的桥梁，每期独立待办列表，互不共享；
• 钱和事挂同一棵树，应收跟期次走，回款靠核销关联，激励从执行记录取数。

适用边界：凡是"一份合约、多项内容、分批交付、多人执行"的业务对象都能套用——代账、审计、检测、维保、培训、设计交付、IT运维是典型场景；往宽了说，项目详情、工单详情这类需要多层任务执行的业务对象，同样可以按这套结构去映射。