做这个平台之前，研究过不少同类产品，也参考过电商订单系统的逻辑。一开始觉得，生活服务无非是「把商品换成服务」，流程应该差不多。真做进去才发现，根本不是这么回事。
最直接的差异不在界面，而在供给的本质不同。
实物电商的核心供给是 SKU——可以提前生产、集中备货、异步发货，库存是个数字，可以管理、可以预测。生活服务的核心供给是「服务方的时间和能力」，它依附于人，受地理约束，同一时间段只能服务一个客户，用完就消失，无法囤积。
这意味着整个订单系统的设计重心不同。电商是「库存出库」，生活服务是「能力调度」。表面上都是”下单 → 付款 → 履约”，底层逻辑完全不一样。
履约的不确定性也完全不同。电商发货之后基本结束，异常有快递公司兜底。上门服务不一样：服务方可能迟到、现场情况比预期复杂、中途报价需要变动、完工后客户可能有异议。每一个环节都可能卡住，系统必须给每种情况留出处理节点，不能靠打电话沟通来临时补救。
真正难的不是流程，是定价
这是整个系统设计里耗时最长的部分。
最初的想法很直观：平台提前定好每项服务的价格，用户直接下单付款，简洁。但深入研究不同服务类型之后，发现这个思路有一个根本性的问题：不同服务，定价发生的时机完全不同。
安装一个热水器，价格是可以提前定的。工时、材料、难度基本可预测，用户看到价格就能做决策。
但如果是管道漏水，在没上门之前，根本不知道漏点在哪、损坏程度如何。这种情况提前定价，要么偏高要么偏低，对用户或服务方来说都不公平。
还有一种情况介于两者之间：需求描述清楚了，但服务难度差异大，统一定价无法准确反映实际价值。平台需要介入评估，给出符合实际情况的报价，用户确认后再付款。
三种不同的定价时机，对应三种不同的产品逻辑：
下单前定价：价格在详情页就已经确定，用户付款之后进入调度流程。适合标准化程度高的服务，用户决策路径最短。
下单后定价：用户提交需求，平台结合需求复杂度给出专业评估报价，用户接受后再付款，然后进入调度。适合需求差异较大、统一定价会偏离真实价值的场景。
上门后定价：服务方先上门勘查，看清楚现场情况之后再报价。第一次付款是上门勘查费，第二次是施工费。适合完全无法提前估价的场景。上门费不退——它对应的是服务方到访的时间成本。
这三种不是「功能选项」，是三种不同的交易结构。每种结构背后，用户和服务方的信任起点、权益保障方式都不一样。
定价模式确定之后，状态机自然就不一样了
一开始想过能不能用一套通用状态机，加条件分支处理不同情况。试过，很快放弃了。
条件分支叠多之后，每次改一个节点都要检查三条路径，测试成本翻倍，bug 定位困难。更关键的是，三种交易结构在关键节点上的顺序不同——付款在分配之前还是之后、勘查之前还是之后——这种顺序差异不是条件分支能干净处理的。强塞进一套流程，逻辑会非常脆。
最后拆成三套独立的流程，公共节点（分配服务方、确认上门时间、勘查、施工、验收）名称相同，但触发条件和前置状态不同。
下单前定价的流程： 用户下单 → 付款 → 平台分配服务方 → 确认上门时间 → 上门勘查 → 施工 → 用户验收 → 完成
下单后定价的流程： 用户下单 → 等待平台报价 → 用户确认价格 → 付款 → 平台分配服务方 → 确认上门时间 → 上门勘查 → 施工 → 验收 → 完成
上门后定价的流程： 用户下单 → 支付上门费 → 平台分配服务方 → 确认上门时间 → 上门勘查 → 服务方提交报价 → 用户支付施工费 → 施工 → 验收 → 完成
注意付款节点的位置。下单前定价是付款在前、分配在后；下单后定价是报价确认在前、付款在后；上门后定价出现了两次付款节点。三条流程的用户体验完全不同，平台对每个节点的管控方式也不同。把它们硬塞进一套状态机，每个节点都要跑条件判断，代价远高于维护三套独立流程。
分类设计，比我想的难
做完定价模型和流程，我以为大框架稳了。后来发现没有。
服务分类不能脱离定价模式单独做。一个分组内如果混入了不同定价模式的服务——比如同时放了「可以提前定价的清洗」和「必须上门才能报价的维修」——对应的订单流程就不同，系统必须在底层处理这种混乱。这个错误我实际犯过，后来重新拆分的成本很高。
分类还影响需求描述质量。分类太粗，用户选完描述不清楚，服务方接单前要反复打电话确认。这个问题靠优化问卷只能缓解，根子在分类没替用户把「这是什么类型的交易」说清楚。
服务分类不是信息架构问题，它是订单流程的前置分流。分类分错了，后面会连带出一串问题。
落地之后，哪里没做好
写复盘，讲做对了什么意义不大，讲哪里没做好更有参考价值。
平台报价那段等待期，用户预期没管好。
用下单后定价的用户，提交需求之后有一段等待报价的时间。这段时间里，很多用户以为订单卡住了或者出了问题。原因很直接：系统通知只说「已收到您的订单」，没说「我们正在为您评估方案，预计 X 小时内给出报价」。
用户感到不确定，就会反复找客服确认，这个信息缺口本来可以一句话解决。通知文案是容易被忽略的产品细节，但对用户感知的影响很直接。
服务方端的阶段引导不够直接。
服务方收到订单后需要按顺序完成多个步骤。但服务方不是互联网重度用户，他们不会去探索界面，他们需要在每个阶段清楚看到「现在该做什么」「做完之后会发生什么」。早期 App 没有做够这一层引导，操作错误率不低，勘查记录漏传、施工照片忘上传的情况时有发生。后来每个状态页加了操作引导卡，完成率才提上来。
这两个问题的共同根源：系统流程设计对了，但「让人用对」的设计没跟上。
总结一下我的判断
这套系统设计里最关键的一步，不是画流程图，而是先承认：不同类型的服务本来就是不同的交易结构，没有办法塞进同一套逻辑里。
一旦接受这个前提，定价模式的拆分、流程的分叉、分类和定价的绑定，都是自然推论。真正消耗时间的，是从「能不能统一」到「根本不应该统一」的那段说服过程——说服自己。
核心难点不是状态多，是「定价时机不统一」这件事，在系统每一层都有代价。