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

代账公司、会计师事务所、检测机构、IT运维服务商这类企业有个共同点卖的不是货是分多次、由多人、长期执行的服务。合约签下来的那一刻麻烦才刚开始——服务怎么拆、任务怎么派、进度怎么盯、钱按什么节奏收、执行人怎么算提成五件事缠在一起常见的订单模型到这里就开始吃力。这篇内容整理自超兔一体云团队的一轮业务建模复盘。超兔一体云是面向中小微企业的一体化CRM系统客户管理系统、销售管理系统、订单、合同、应收财务跑在同一套数据底座上。我们在给服务型企业客户梳理服务合约管理时把复杂服务型合约的多层任务执行模型完整推演了一遍下面把推演过程摊开来讲供做业务系统设计的同行参考。先把场景看明白一家代账公司签下一笔年度合约里面装着多项服务产品月度代账、年报审计、税务申报。每一项都是客户实打实购买的东西——只不过属于服务型产品以执行、行动、待办的方式交付本质上仍然是产品。复杂度藏在细节里。月度代账买了十二期一年十二次交付一项服务可能要三到四个人接力跟进执行中途还会换人。财务月底要算提成老板随时想知道两件事哪些服务还没派出去派出去的做到哪一步了。把客户的核心诉求列出来其实就三条哪些服务产品还没有派发已派发产品的执行进度到哪一步了按月对执行完成的部分给参与的每个执行人核算提成。这三条看着简单落到数据模型上每一条都要动结构。实物订单的建模思路为什么装不下服务合约传统CRM的订单模型围绕实物商品设计品名、型号、SKU、数量、单价签单后走发货、出库、回款。这套结构处理一手交钱一手交货的生意没有问题问题出在服务合约上——服务没有SKU。一种常见的将就做法是把服务的每次执行当成一条任务手工登记或者建个分组把任务归拢起来集中管理。跑一阵子就会发现任务和合约对不上账换人之后历史记录散落各处月底算提成靠人工翻记录。说白了把服务当任务管管住的只是过程流水把服务当产品管才管得住交付承诺。超兔认为核心在于换一个本体合约里的每一项服务都应该被建模成服务产品这个实体而不是任务清单。产品决定谁来做、做什么、做多少次、按什么顺序做、什么时候开始做。想通这一点后面的结构就顺了。模型怎么抽象五个主体五层结构沿着合约—产品—期次—待办—记录这条线场景里的所有角色可以收进五个主体主体说明关系合约顶层业务对象承载客户签约信息是管理的核心主体1 : N → 服务产品服务产品合约下的每一项产品本质是客户购买的服务型产品1 : N → 期次1 : N → 执行人期次产品交付的时间维度单元每期拥有独立的待办列表1 : N → WBS待办WBS待办某期交付中按固定顺序执行的任务存在前后依赖1 : N → 执行记录执行记录单个待办下多次、多日的执行过程记录—三处关系容易建模出错值得单独说。合约与服务产品是1:N。产品是合约对客户的交付承诺管理目标始终以合约为中心但驱动执行的是产品。期次与待办是1:N而不是共享。每期要有自己独立的一套待办不能十二期共用一张任务清单——否则第一期做完勾掉的任务第二期就没法做了。待办与执行记录是1:N。一个待办往往要拖好几天、来回多次操作执行记录就是这期间的流水日期、内容、执行人都要留痕。把这五层再往通用里抽象一层就得到一套可以跨业务复用的映射合同→交付计划→交付批次→交付任务→执行记录。代账叫期次检测机构叫批次IT运维叫巡检周期叫法不同结构同构。容易被低估的一层服务产品本体五个主体里服务产品是核心实体。若产品的实体和属性不清晰整个业务逻辑都无法立足——这不算夸张因为产品决定了一切下游行为产品决定负责人谁执行写在产品上产品决定待办任务做什么行动事项由产品定义产品的期次决定待办数量买六期生成六套待办买三期生成三套。因此合约是管理主体产品是驱动主体。关键在于服务产品的核心属性不是品名、型号、SKU而是围绕服务交付定义的一组业务属性属性类别属性说明示例负责人该产品由谁负责执行支持一人或多人张三、李四、王五服务主体该产品为客户提供什么服务月度代账、年报审计、税务申报服务相关待办执行该服务需要完成的行动事项收集票据、录入凭证、出具报表期次购买的期数决定待办生成数量12期1~12月各一期WBS结构按固定顺序和规则执行的任务分解先收集→再录入→后审核→终交付交付日期与提醒预计交付日期及前置提醒逻辑10月8日交付提前两周提醒其中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.101-05 联系客户获取票据 │ │ └─ 执行记录1.201-06 收到票据扫描件 │ ├─ WBS待办2录入凭证依赖#1 │ │ └─ 执行记录2.101-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期16期应收已全额回款712期待回款年报审计尚未启动待办全部待开始本月提成张三1200元、李四800元王五因审计未启动暂无。事、钱、人在一个视图里对得上这个模型才算闭环。这套模型在超兔一体云里的承载落回产品层面超兔CRM的合同订单管理中心对服务型业务有专门的承载方式服务型交易用合同和合同视图管理合同之下配套合约交付计划和回款计划把事和钱挂在同一份合同上。财务侧由智能应收引擎衔接签约、开票、发货均可触发应收自动拆分多期金额与百分比双向计算选择合约金额-回款算法时保存合同订单会弹出智能新建回款计划的界面。回款到账后一条回款记录可以智能匹配多个回款计划自动拆分出未回部分应收与回款两边联动避免两本账。执行侧用行动记录和待办任务衔接执行人的跟进行动可一键转待办派给自己或同事人员变更时历史记录跟随产品留在原地不散落。至于按期次核算提成在这套模型里属于激励层的设计目标——执行记录和完成期次已经沉淀为结构化数据核算规则就有了可靠的取数来源。方法小结把复杂合约建模拆成四步这套推演过程可以抽成一个通用方法不只服务合约适用。业务到数据的四步映射步骤动作要问的问题产出物常见反模式1. 识别本体找出驱动一切下游行为的实体谁决定谁来做、做什么服务产品实体把服务当任务清单登记2. 定层拆分沿交付的时间维度分层做几次每次独立什么期次层所有期次共享一套待办3. 挂执行流任务依赖加过程留痕按什么顺序怎么留痕WBS待办执行记录只记结果不记过程4. 接资金流应收、回款、费用、激励钱跟哪一期走应收计划核销关联钱事两张皮月底对不上三条铁律合约是管理主体产品是驱动主体下游行为一律从产品属性推导不做人工二次录入期次是产品与待办之间的桥梁每期独立待办列表互不共享钱和事挂同一棵树应收跟期次走回款靠核销关联激励从执行记录取数。适用边界凡是一份合约、多项内容、分批交付、多人执行的业务对象都能套用——代账、审计、检测、维保、培训、设计交付、IT运维是典型场景往宽了说项目详情、工单详情这类需要多层任务执行的业务对象同样可以按这套结构去映射。