2017年入职，2019离职，2年社交产品后台的工作，让我对后台产品有了很多思考与总结；汇总成这3万字，分上中下三篇发布，此为下篇。希望能对大家有所帮助。
接中篇。
十五、核心指标
供给侧的核心指标是：
新增注册数，成功注册的机构数；
新增入库数，成功在库内建博主主表数；
博主审核速度：审核时间-提交时间，刨去夜间因素；
人均处理数，总提交审核数/工作人数；
新增上架数：分业务线、分平台、分来源看；
动销率：卖出去的SKU/总SKU；
被下单博主数：被下单数＞0的上架博主数总和；
被支付博主数：被支付订单数＞0的上架博主数总和；
博主数量维度的周转率：被支付博主数/总在架博主数；
博主曝光率：有曝光博主数/无曝光博主数；
有曝光被访博主率：被访问UV数＞0的有曝光博主数总和；
加购率：被加入购物车博主件数之和/总的有曝光博主数。
这几个指标可以独立交易线，看供给侧的健康度和效率情况了；如果某天遇到异常，再往下拆解详细看。
十六、数据驱动
说一个小的数据驱动案例，就是主动渠道入库的分支里的上述的插件功能。
当采购从爆款博主监控工具发掘了目标博主以后，所执行的动作是点击、打开详情页、浏览、判定可入库、贴回浏览器的URL。
此时我看到了一个数据：从点击到入库的平均时长，在7分钟左右——按理说不应该有这么长，详细拆分数据，将这些博主的从打开入库界面到入库的时长在5分钟左右；因为我们处理抓取的任务优先级是先保证对外，再保证对内，而两端的操作、交互行为都是一致的，提交入库后就要等系统的返回通知，否则这个入库就可能会失败，所以5分钟的意思就是内部采购在等待机器返回成功结果通知。
当观察到了这个数据以后做了一个优化，就是在入库页面新增了批量入库的功能，也就是按照一个模板上传URL，等待入库结束的通知。
本以为会提效，没成想又变成降效。
首先这个功能确实抓住了痛点，但是没考虑到，当所有人都去这么使用的时候，方案错了：
第一个是抓取的并发处理出现了问题，大量的任务堆积，导致失败率异常高；
第二是拉长了处理周期；
第三是看似减轻了成本，只不过采购同学由原来的贴近入库界面，变成了攒着贴进excel，路径是一样的。
所以这时候又要重新思考这件事：他们要的是快速的从A到B，而不是一匹马还是一个汽车还是一个火车的问题——如果交通工具没有了才好。
以此为思路，开发了基于主要平台的浏览器入库插件。
在chrome浏览器下，安装插件，登录自己的工作博主，当打开微信、微博等博主主页时，只要右键点击入库，即可完成传递的工作；当真正的入库抓取流程处理完毕，会推送通知提示采购者及时处理工单，这样系统并发也不存在了，处理周期真正缩短，操作路径真正缩短，完成了目标。
所以，最后观察的结果是从点击博主进入博主主页，到入库提交的时间从7分钟降为3分钟，达成真正的优化目的。
十七、第三方服务管理
我们在运行当中会调用很多第三方服务，比如短信通知，第三方支付服务（微信/支付宝/云闪付），企业资质校验的企查查，百度的机器视觉，法大大的电子签章等服务，钉钉的机器语音外呼。所以这对我们的管理和通用化思维提出了比较严格的前瞻性要求。
用短信举例，我们的短信是有3家服务商，最初的考虑是避免在注册收验证码，或者关键通知提醒的节点，因为服务挂了，导致业务进行不下去；可后面发现这块不简单，首先每家短信服务商的价格不一样，对应的就是到达率和及时率的不一样，贵有贵的道理，便宜也有便宜的道理，这就要求我们能够接入并合理运用。
像所有服务商的接入，必须可管理、可透明化运营场景。
以短信为例，我们除去常见的基础信息以外，还会要求收集服务商的业务性数据。
基础信息有供应商名称、服务年限、企业资质、营业执照、调用费用、电子合同、接入人、介入时间、联系人信息等；
业务性数据像哪个消息ID，发送多少个信息，消费多少，成功发出多少，到达多少，及时率多少；
也会有一个综合性数据，供下一个模块消息配置中心所承接。
像其它的逻辑和套路也像短信类似，不重复说了。
相比之下，刚刚说的其它服务可能就没有像短信这么复杂了，像企查查、第三方支付等，都是固定的节点在接入，其它节点也没业务场景和需求，我们只要监控日常的调用数据是否异常，及时报警。
十八、消息配置中心
我们每一个节点基本上都是有短信通知的，有通知补全信息，不成功有提示再来一回，提交有等待审核，长时间无活跃的促活召回等等之类的；这些都是运营该去想哪些要提示，哪些不要提示。而我们产品对于系统化来讲的意义就在于搭建框架，运营可以在里面随心用，怎样的需求基本都能支撑的原则。
短信服务要收集那些关键信息，就是在于每个节点对于服务商的需求是不一样的。比如注册时的验证码，那就要到达率高的，及时率快的；相比之下，召回短信就不用有此依赖，便宜就行，反正90%多的到达率，我一次发个万八千的，也能回来不少。所以这就要求我们在设计消息中心的时候，尽量提供便利性。
便利体现在两点：第一是在于节点识别的便利性，第二是在于服务商识别的便利性。
节点的意思是如何能让运营通俗易懂可视化，哪个节点需要配置，哪个节点在业务中的进程是什么。
我们当前做的是文字状态的展示，但是发现不太好，因为对于新人来讲的接手成本还是有点高。比如，提交后等审核短信，什么叫审核成功，什么叫审核失败，是哪个节点的审核失败？你可能问我或者问一个资深运营马上就能告诉你：是在企业资质资料的阶段，可新人并不一定知道。所以，接下来要迭代的一个大版本，就是一个可视化的配置界面。
这个需求的本源来源是来自BI，他们正在开发基于全系统、全流程、全状态的可视化图表，就像我短信节点这就是很小的一块了。
从注册到上架，到被交易，数据都发生了怎样的状态变更，上下级和分支是怎样，BI都会纳入可视化的范围，去呈现一个报表，供所有相关人查阅；看前一天的业务情况，卡在哪里，转化率锐减，或者哪里转化率不理想，可以提升，洞察问题，诊断问题很方便。
原始需求再那边，我这边只负责梳理状态和对应的状态路径之类的。
在当前现状下，辅助运营能相对方便的识别出哪些节点，可以配置短信，也可以配置灵活的短信策略。比如，最简单的注册，那就是当触发状态，立即发送；最复杂的就是在召回规则里，比如会有某些等级的资源，当非活跃持续7天后，下周1、3、7持续短信召回，精细化甚至可以达到某些类别、某些量级、某些单位区间内交易数量的博主——因为运营很可能会这么写短信：
各位母婴博主，平台最新发布本月母婴博主榜单，请及时查收。
也有一些错误配置的功能，比如注册，一般就会开启“当短信发送失败，立即重新发送”，而召回可能就不用。也会有服务商优先级的配置，刚刚说了，可能最好的是A，优先A，但是也可以把B，C列为第二、第三优先级。
所以这个消息配置中心是一个大支撑模块，所有节点都可以用。
短时间内开发成本确实很高，但是后续来看，是减轻长期开发成本了。
十九、订单中台
接下来是我负责的另一个比较重要的中台服务，就是订单中台；是属于OMS中的底层，偏抽象的，各端的都有各自的订单管理界面，进行独立的展示和管理。
订单中台这个事情做起来要比采购端容易太多了，因为他是具象目标，收敛的，很明确的目标，就是根据之前订单去抽象支撑未来业务发展的订单小中台。业务刚刚说过了，没有库存，也没有优惠营销，所以偏向虚拟服务订单类型，但是相比之下还会稍更简单一些。但是架不住业务本身复杂，还要兼容各种情况的出现。
公司决定整体重构以后，划分了非常多的系统，借此我们也重新梳理了订单流程（也就是订单被创建的标准流程），除去状态机有中台公用的状态机以外，系统流程也是，避免各自为政、管理混乱、统计混乱、重复开发、成本加大的问题。
1. 名词
我先介绍下名词：一个是非标原创，一个是标准通稿，这是由博主的内容质量分所决定的。
非标原创的意思是客户带着需求方向来，需要博主进行自定义的完全创作。比如客户就要做一个面膜的推广，品牌是欧莱雅，时间是双十一，面膜特色是补水、保湿和贵——那可能不同的博主创作出来的内容风格和最终交付的内容都不一样，我们把这类定义为非标原创。
标准通稿就是反过来的——因为业务非标，导致商品非标。
公司为了改善这个问题，在2017年的时候新增了一条标准化业务线，客户带着已经创作好的内容，你帮我发就可以了，不用管内容哪里来的，客户就是要刷屏效应，博主完全不需要二次创作，这叫通稿。
非标业务线与标准业务线的主要差异在于客户权益：
非标业务线有些会出现差旅、版权授权、代言或竞品协议等其它特殊附加费，都是各不相同；
标准业务线就很标准——博主多少钱就是多少钱，下单、支付、发布、验收就可以了。
鉴于非标业务线的特性，也造就这两条业务线在业务中的最大差异：非标业务线会在下单流程中增收保证金，因为沟通和后续成本太高了；另一条就不用了，非标品转化为标品，相对确定性。
对于保证金，在下单的时候会经历业务属性很强的价格预估模型，从而根据此计算保证金，客户有偿下单。而获取最终确定性的订单价格以后，也就是博主的反馈后，会生成子订单——所以第一条父订单是保证金层面，第二条子订单是尾款层面，两笔订单结合构成完整订单。
对于业务线的大划分，有微博/微信/抖音/快手/小红书/B站这几个平台，从最上层进行抽象其实就是两类：文本和视频。
文本的非标下单流程和视频的非标下单流程，哪怕都是非标业务，业务节点也有不一样。比如文本可能会有brief确认、大纲确认、图片素材拍摄确认、软文确认等流程。而视频会更为复杂——会有brief确认、镜头确认、脚本确认、视频确认、发布详情确认等环节。
每条业务线会组合有标品和非标品，所以大体上就是4种最核心的抽象。
当前平台和业务线的划分情况划分的情况，是微信有非标原创、标准通稿，微博只有标准通稿，但是会分为直接发布和转发，只是交互上不一样，订单结构完全相同。抖音/快手/B站，只有非标原创，你做大批量标准通稿，视频平台算法就封杀你了。
这是介绍订单之前的前期概念认知。
2. 下单流程
当客户准备下单的时候，经历的标准流程是非常长的，这里详细介绍下：
当客户进入博主详情页，先去调用我的商品中心，获取商品的所有信息和属性；而后会调用客户中心存储的本客户的客户画像；接着就会在估价模型基础上，结合客户画像的价格模型，输出估价，这样对客户下单前的博主信息标品化工作结束，等待客户触发下单的按钮。
当客户点击下单，首先经过风控中心，检查客户的下单行为是否正常（交互行为和端的行为，如果发生异常，就会下单拦截报错），没有问题的话将会进入下一个环节。
此时订单将会被创建，其中订单上的价格为根据客户选用的SKU上（某些业务线需要交保证金，保证金为估价模型估算的价格，按照一定比例收取的保证金），此时是父订单，这类业务线的订单会在后续生成一条子订单，也就是尾款订单；客户此时需要支付尾款，否则订单不会被触发后续流程。
子订单支付完毕后，父子订单会合并，状态会统一（非保证金业务线，就不会生成子订单了，单一状态线性向下）。
博主回复价格后，继续经过价格模型，根据客户画像和供需模型生成溢价；在客户看到价格并支付后，支付中心会回传支付信息和支付状态，当支付已经完成，会调用订单中心进行订单状态的更新，变为已支付的状态，并订单下推。
此时订单会推送至执行中心（简单来说就是订单将被内部接手，开始与博主端勾兑需求、制作、协调修改的持续过程）；当博主可以做需求，回复订单价格后，会生成子订单，同时系统会生成电子合同，供销售端客户和博主双向确认，一个是服务合同，一个是采购合同，客户必须在合同确认后，才能再支付尾款，补齐差价，此时服务合同建立完成（客户对公司），同时调用支付中心支付成功，采购合同推送至博主端（公司对博主），此时订单才算建立，商业契约达成。
推送采购合同必须客户确认服务合同和支付尾款，若客户只确认合同，则不会告知博主完成采购合同签署，有毁约风险。所以客户端如果确认合同不支付尾款，则可判定客户毁约，按照协议中一定比例违约金（一般就是保证金的100%）进行赔付。
当客户支付后，实际对应博主的伪库存已经减少（也就是：博主在从下单到最终发布的这个时间区间内，其它客户虽然可以接，但是时间尽量不允许与之交叉——本着对客户负责的态度，所以这就是刚刚介绍的伪库存减库存的概念）。
订单详情都详细记录了预计什么时候发布，这时候会通知到库存模型：当客户访问页面，调用报价模型的时候，报价里面库存模型的这个模块的作用就发挥出来了——首先加溢价，我们尽量拦截，如果执意下单我们也乐得赚钱，同时页面去提示客户换个档期，可能就好了（页面这时候也会出现同等博主的协同推荐，引导客户去换个博主）。
总之要周知：这个博主这段时间可能没有档期了，就要提示这个时候下单是有高风险的；可能博主会不接单，可能价格会很贵，可能出来的内容会不满意，客户谨慎下单，起到前置提示的作用。
再之后就是相对常规的沟通、修改，订单不会再动了；当完成内容发布后，客户可以进行操作确认（相当于确认收货）。
在博主提交完成的同时，我们会触发机器质检，生成数据趋势图，用于辅助客户判断传播真假；客户可以在这个区间内任意时间进行确认，目前是7天；而后就是评价，评价后订单才会真正完结。
评价是商品中心必不可少的，既可以用于其他客户决策参考，还可以供我们更新对博主的评估模型以及推荐模型。
质检主要就是根据订单中的关键信息，比如哪个博主，什么时候发布，标题是什么，这时候机器就会机器介入服务，在发布时间区间范围启动抓取服务，进行内容发布的识别。
产出主要有2个，一是供客户通知用，当识别到发布，就会告知客户之前的订单发布了，可以来看看效果了；二是识别数据，进行数据汇总呈现报表。
这里我们和线下服务的业务还不一样：线下业务的确认收货节点是到店核销，但是我们大多数没有明确的确认节点。
对于非标的创意来讲，每个人的理解可能都是不一样的——你可能满意，他可能就不满意，所以这个节点目前必须客户手动进行操作，才算结束。
若客户没有点击确认，点击投诉（相当于电商中的退货申请），此时订单状态变为处理中，客户中心将会接手，会进行对客户、对博主的双向协商，直到达成一致；在线上录入协商结果后，无论是按比例退款还是赔偿，都只可以在客服中心修改一次；客户通过后，订单同样记录完结，若发生退款，订单中心会先生成冲红订单，将订单退款额抵消，同时订单状态变为部分已退款，实际等同完结，进入评价环节。
3. 商品评价
在交易完成后双方必须对双方进行双向评价，目前包含内容评分（客户端）、客户评分（博主端）、服务态度评分、平台易用性评分，三大维度，均可以打星或自主评价。
内容评分是对博主最重要的，客户的评价好坏会直接影响博主的等级修正和价格修正，当星级变为3星或以下时，自主评价为必须填写，每条评价内容人工均会审核，审核通过后会展示在博主详情页供下一个客户参考，同时根据此评价整理反馈单，直接提交至模型中，进行学习和修正。
至此，整个交易流程结束。
我们的整体下单流程非常长，也非常复杂。
4. 保证金
对于保证金制度，主要有2种：按照次付和预存（相当于押金）。
次付就是上述根据每笔订单按比例计算出来所需要交付的保证金。这个相对麻烦，要和客户进行协商，只有这笔钱变为消费金额以后才会开具发票，也就是最终变为结算状态。
预存押金制度相对流程友善，对客户决策成本有较高考验；比如押10万，那么每次下单的时候都会检查保证金是否为正，如果发生订单在预付阶段的取消，就要判责后从10万保证金予以扣减，并给客户开具对应的收款发票。
5. 订单元素
接下来说一下我们订单上的必要元素，包含交易时间，其中下单时间、支付时间、确认时间、评价时间，财务上的结算时间、打款时间等，会单独一套财务，打款单里有。投诉时间也是在客服中心的，中台订单中心是没有的；交易双方信息，甲方名称、乙方名称；订单基础信息，父订单ID、子订单ID、订单ID、订单状态、订单类型；商品信息，商品名称、SKU信息、规格、商品快照、价格。
价格有2个：第一个是模型的预测价格；第二个是此订单的实际金额，支付信息，支付方式、支付单号、总金额、实付款金额、券抵扣金额、信用账户抵扣金额、总抵扣金额、备注，备注。主要是供API、SaaS形式的下单用的，意为在内部走完财务OA之后，读取审批通过的那个人信息，也就是支付人。
最后，是其它信息——发票状态、下单平台、销售经理、执行者、博主运营、下单者。整体构成了我们订单的全部信息，最重要的是订单状态，其它的在供给端讲解的时候基本都说到了，不重复了。
6. 订单逻辑
介绍一下订单上的一些通用逻辑，这个是不能变的。
比如：
下单时甲方验证过的企业名字就是公司与甲方签署服务协议的甲方公司，下单时选中的博主验证过的机构名字，就是公司与乙方签署采购协议中的乙方；
商品信息随下单时选择的写入，快照是必须的，避免后续纠纷；
当时的非销售属性条款最为重要，价格会有两个：预估价和预付款，子订单对应的就是博主反馈后生成的预估价和尾款。
支付信息一般从支付中心调取信息直接使用，其它信息中的发票状态随最终订单结算后，财务会根据结算状态的订单按顺序开具收款发票快递至客户端，平台一般有内部平台和外部平台的自助、SaaS、API和代理商，以及客户的销售经理、这笔订单的执行客服、博主的入库审核的运营人。
最后的下单者即当时登录博主的下单者，用于后续的追责。
除支付状态和除下单的时间外，所有信息必须在生成订单的一刻全部完整，否则订单将创建失败；
订单执行的必要条件为是上述所有订单信息全部完整，否则订单将会执行失败。
需要交保证金业务线的订单，不支持多个订单一起下——因为保证金和尾款实际是父子订单连在一起，如果也支持多个订单一起下，相当于父子孙订单，实在不划算。
所以：需要交保证金的业务线，会稍复杂些：当预付款支付完毕后，博主响应后，随即生成子订单，子订单状态是初始状态待支付，用于后续流程；
非保证金业务线即可多个博主一起下单，父子两层完全结构复用。
7. 订单运营规则
像一般的订单运营的规则就不多说了，比如下单后多久不支付自动取消，我们目前是12天——因为2B平台的因素，会遇到提前下单锁档的客户，是正常的需求；什么节点可以取消订单，目前是随时可取消；但运营根据配置的赔偿规则，有一定的有损取消条件，一般情况下在已经执行后，就不可以全额取消了，客服审核不会通过的，只可以协调部分退款。
还有就像执行后多久自动确认，目前是7天；投诉目前每个订单只能有1次，刚刚也说过原因了；确认后多久自动评价，目前也是7天，评价不可为空，如果客户不填写，所在的订单执行是要负责补上的；以及财务接手的，订单被评价的完结后，博主什么时候可以提现，目前是随时可体现，但要支付一定的提现手续费，原因是我们要尽可能的让钱趴在平台上时间久一点，产生相对稳定的资金池沉淀，钱生钱。业务线不同，免费提现的时间也不同，一般是30-60天不等。
8. 状态机
下面说下重点的订单状态机：
我们的目标是抽象小中台，供以后交易线复用快速实现，并且能够统筹管理，对于报表层面也是友好的，所以我们开始做的一件事就是分析订单的历史数据。
按照业务线，无论是微博、微信，还是抖音、快手，首先分成两大类订单类型：文本交易和视频交易，而文本交易又划分为非标原创交易、标准化通稿交易——这就意味着至少有3大组业务线。
文本非标原创不同于标准化，其中需要有大纲往复确认，内容发布前的最终确认过程；标准化的通稿就没有，因为本身就是广告主带着来的，所以这是一组特征；再看视频原创交易，与文本原创交易相近的是把大纲改成了脚本，拍摄内容，最后还多了一步是发布详情，也就是发布的细则最终确定。
这些基本都是属于不同业务线，属于自己的状态机。
那么这时候就可以按照电商大体的框架去搭建真正的小中台订单中心了：
根据分析历史订单结果去找交集点，发现和电商非常像。先订立起止状态，订单起状态即创建订单，状态为待支付，订单止状态正常结束为评价结束后的已完结，异常结束为已取消或部分退款已完成。中间取各业务线之间弱耦合的通用状态连接，小中台订单核心状态机大体分为待支付、已支付、待确认、待评价和完结，以及逆向流程的处理中、部分已退款、已取消状态。对应的现金流状态为支付后的冻结，产生冻结流水。当订单完结状态时，现金从冻结变为消费，并生成消费流水——这是两条最大的脉络。
逐一业务线去实现。
先看微信原创订单：
微信订单状态机一般会分为待支付保证金、已支付保证金、待响应需求、待支付尾款（子订单待支付）、已支付尾款（子订单支付）、（订单合并）、大纲确认（次数会挂在每个订单的合同中）、内容确认（次数同上）、待执行、待确认、待评价、完结。
对应的交互状态也就是下单之后的待支付保证金状态，客户进行支付保证金，状态变为已支付保证金，博主收到需求，回复需求的确定性价格，客户收到待支付尾款，客户支付尾款，博主开始创作，大纲创作完毕等客户确认，客户确认后进行内容创作，内容创作完毕后等待按照订单上的约定时间发布，博主发布后等待客户进行确认，客户确认后客户评价，评价完成后订单完结，推送至财务准备结算。
所以可以在小中台订单中心去实现：
在中台订单中创建订单，待支付状态，支付完毕保证金后，订单状态冻结，博主响应填写报价后，会在此订单基础下生成子订单，当客户支付完毕尾款时，调用中台订单中心订单状态变为已支付，并且父子订单状态合并，进入沟通和创作环节。
期间内的所有状态变更都是业务线自己的行为，当博主发布内容后，调用中台订单中心变为待确认；当客户确认后，调用中台订单中心变为待评价状态，当评价完毕后调用订单中心变为已完结状态。
微信通稿订单同样的逻辑，但是支付环节就没有保证金一说了，跟业务线需求和逻辑走，支付后就直接已支付，支付完成后就直接等待发布就可以。
因为是通稿，客户带着文案来的，你帮忙发就行；所以博主在规定时间执行完毕，质检接入，机器判定执行状态后，自动帮客户进行确认，直接变成待评价状态，评价完毕后订单完结。
除中台订单中心以外的状态和调用逻辑、规则，均可以按照自己的业务线自定义，但是订单中的必要节点必须要调用中台订单系统，否则订单就是卡住的状态。
说一类特殊的订单类型——预充值的CPC业务线：
客户会先输入预算，提交后，中台订单会根据客户自己输入的预算，建立充值订单，状态为待支付；
客户进行支付后，状态变更为已支付，扣费模型会接到客户创建的需求明细，进行按照click的扣费计算，直至消耗光，订单自动变为确认和完结；
或者客户在投放过程中发现异常，主动进行停止，停止后订单变为结算状态，同时生成冲红订单退回未消耗的钱款至客户的充值来源。
再来说一下父子订单：
和一般电商一样，我们也是有购物车的，内部叫选号车。当从购物车选中多件博主时，并下单进行支付，这次整体的购买行为记录在父订单下，针对父订单进行结算，其实就是将多个订单合并的过程；当提交订单后，系统再更新订单。
在投诉状态、财务状态的时候，针对子订单，也就是当下多个订单被合并为一个父订单后，业务上的确认和评价动作是针对父订单的，每个子订单是不会再有了。如果子订单发生异议，可以在14天内（自动确认的T+7，自动评价的T+7）进行投诉，和父订状态单独不互相干扰——这也就是为什么保证金业务线，就不能再多个订单一起下了，保证金+尾款本身就是父子订单了，再技术多做一层不划算，不如在业务端进行拦截。
9. 合单
合并订单的逻辑是：
下单时间就是子订单合并创建父订单的时刻，支付时间是支付父订单的时刻，并会覆盖至子订单上；
父订单的确认时间：若子订单发生投诉，父订单还未确认的时候，则子订单没有确认时间，当客服处理完毕后的时刻就是子订单的确认时间；父订单已确认，则确认时间就是父订单确认的时刻，处理完毕的时刻也不会进行覆盖，评价时间也是评价提交的时间，并会覆盖至子订单上。
交易双方信息甲方信息就是客户名称，主体一致，乙方名称为所有商品名称的标题聚合，最多255字；
订单状态取所有子订单状态中最慢的状态，一般就到待确认，客户在所有内容都满意以后才会进行确认；
同步所有子订单的SKUID和规格ID，商品快照可以为空；
价格取实际金额的total，预测金额会以子订单为维度进行内部分析，不会放在父订单上；
支付信息取自支付中心；
发票状态会取子订单中最慢的状态，一般发票状态就分为待开票、已开票、邮寄中、已关联——也就是当全部子订单都变为已关联，父订单才变为已关联，否则就以最慢的状态为准；
下单平台、下单者，取任意自子订单，应该每个子订单都是完全一致。
10. 拆单
有合并订单，必定会有拆单的维度和逻辑。
拆分订单的维度主要分为供应商（店铺）、平台。同一个父订单会包含多个博主子订单，可能博主从属于的供应商都是不一样的，这从业务上就必须要拆开。
同一个机构的订单放在一起，主要服务于后续的结算和打款，基本是在父订单完结后才会触发这个逻辑的拆单；平台的维度主要服务于执行中心，因为不同平台的执行流程、执行组的跟进都是不同的，所以也要进行拆单后推送至执行中心。
——这里是支付后立即就要拆，并且要返回前端用于展示；我们也不会像电商不同品类之间要拆，不同货仓要拆，分箱拆单之类的复杂，虚拟业务相对来讲简单一些。
最初我们还想把业务线变为拆单的维度，但是通过运营规则的约束成功把拆单的问题避免了，前端不让跨业务下单。
拆单的逻辑是：在下单后立即触发按照平台维度的拆单，将子订单中统一平台的订单进行拆出，并进行合并生成新的按平台的父订单。
“拆合并”的逻辑和上述“合并拆”的逻辑反过来就可以，所有父订单的字段信息都可以从子订单取到，拆单后会推送至执行中心进行按照父订单分配的逻辑进行执行；后续的供应商维度的拆单合并，推送至财务中心基本是一致的。
11. 投诉
投诉也就是退货的逻辑，要比电商容易一些，因为我们是非标业务，又是虚拟业务，没有实体物品的交付，也就无法口径、概念认知完全一致，也就必定会有人工的沟通在里面。所以这也就是刚刚说为什么新做了一条业务线是CPC，我们就可以三方口径一致，大家都按真实阅读扣费、计费，数据横在这就可以减少很多人工了。
所以我们的退货，都是要经过客服中心去人工调解，在平台最终进行判罚。也没有像电商系统需要拦截出库，暂停发货的复杂流程；更没有想退货，上门取件，回仓等复杂流程；我们只有退钱，所以是相对简单的。
刚刚介绍过，先要经过风控，去判断是否恶意，后客服中心生成工单，进行执行、客户、博主的三方沟通，调解，调解完毕后输入退款数额或者比例，客户端确认即可完成整体的投诉退货的流程。
12. 财务
我们的业务所有都是预付，但是对大客户不得不开放账期，所以我们的账户分为3个：现金账户、信用账户和返券账户。
一般情况下，客户只会用到现金和返券，也就是充多少就会进入到先进里面，下单、支付、冻结的所有过程都是在现金账户里。对于大客会有信用账户去支持账期的需求，也就是钱没过来，但是可以先透支下单；最后结算后报备，客户就可以充值进现金账户从而平账信用账户。
当订单被支付后，其实订单就已经进入财务环节了（也就是我们作为收款者需要开具收款发票，供对方查账用）。会分为2张票：订单实际金额和服务费票，两张加一起为真正的实收。
当订单完结后，这笔钱就会进入到博主的可用余额账户了。
我们的打款结算是被动进行的，也就是博主进行申请才会进入后续。当博主申请后，需要先输入要提现多少，并确定收款主体等信息，等待邮寄或上传电子发票，输入快递号；当系统识别发票已收到后，财务会第二次介入，收到订单进行处理，主要是审核发票与打款主体和订单信息，是否满足打款条件；审核通过后会生成打款申请单，多个不同银行的不同模板进行配置，主要就是打多少钱和对方的收款信息以及票据，供银行对公打款使用，将表格直接导入至银行系统中，完成对公打款流程，整体交易流程就结束了。
13. 私有化
对于大客，我们还兼容了API形式的接入和SaaS形式的私有化部署，主要体现在流程上有些许不同：
当客户在自家系统输入完毕需求后，传入内部的撮合模型，进行结果集信息的返回，客户点击博主详情后，请求商品中心与价格模型、库存模型返回详情页面数据，客户点击下单后，通知财务检查保证金金额和剩余可用押金（大客一般都是压一笔）情况，系统判断可扣减余额后父订单变为支付状态，订单激活，内部执行开始介入。
当博主返回确定性价格后，会生成子订单，并建立相关合同信息，返回客户采购平台，客户在内部决策后，通过或拒绝合同；若通过合同，回传我司后进入财务，财务立即请求客户OA系统并建立采购单，建立者即为通过合同人员信息，审批采购合同的财务为固定按规则分组的法务；法务审批通过后，合同回传至我司财务，进行服务合同部分的留存，同时会再次调用客户OA下行审批流，将留存的合同文件以附件形式创建，下行审批角色为固定规则分配的客户财务，财务通过后，支付状态返回公司支付中心，后通过支付中心通知订单中心，刷新订单状态，变为已支付，订单被激活。
另外，在客户完成支付后，建立对博主的采购合同，并发送至博主的邮箱；从而完整建立双方的服务、采购合同约束过程，最终完成无缝接入大客户的内部审批流程。
整体流程是一致的，但是实现会更为复杂，参与的人和系统也会更多一些。
二十、项目结果
目前重构完成后，技术部提供的量化数据中，在中台订单上线后，可降低每次新业务线订单开发约30人/天工作量，主要取决于必要节点的开发、接入无需再重复开发，主要体现在和财务、供给、销售侧的对接上。
1. 核心指标
一般情况下，订单这里最关注的数据：
统计周期内的GMV（统计周期可以是日、周、月或自定义）；
客单价：统计周期内，已支付的订单平均金额；
加购数：统计周期内加入选号车的博主数；
每个订单的产生桑基图，包括在订单创建之前的商品浏览、加入购物车、提交购物车等关键步骤的转化率。
2. 小优化
非常早的时候做过一个优化，虽然不大，但是至今非常深刻。
我因为是对公业务，导致大部分是充值、记账，实际是对公业务打款。那就有一个问题：录入充值信息的时候，总会出错（这个出错的直接后果就是充错钱，充别人账上去了）；虽然频率不会很高，但是每一次发生后的处理都是财务开发修改数据库，手动将充错的削掉，加到正确的客户账上。资源消耗非常严重，而且也是可避免的。
当时就思考如何解决。
我司系统和银行系统做对接是不现实的，银行不可能允许。但是银行的充值流水数据是可以接入的，他们可以吐数据，我们就想中间缺的就是一个连起来的标记。
当时做的方案是：将每个客户的打款信息栏，增加一个唯一标记，要求客户在窗口申请对公打款的时候，务必将标记填写至备注列；标记是我们生成的，客户写在备注列，打款单备注列也会带上，我们根据银行的数据和我们库内的唯一标记对比，就知道哪个客户充值进来多少钱，直接读取在平台上生成充值流水。
这样的好处是：流程再也没有人的参与，人工的失误被避免了。
自此以后，充值错误的发生数为0，节省了人工。
还有一个是数据驱动的优化，是在之前我架设新的交易线的时候，发现一个令我不解的数据，就是在博主执行以后，需要把执行的地址贴回来，系统会参与质检，客户端也能看到。但是有个数据异常——贴链接的操作人，80%以上都是内部的执行人员，发现许多博主很忙，就可能忘记再回来填写；而执行组认为博主不填写，那么这个工作就是他应该做的，也没人反馈，所以他们就默默做了。
虽然是很小的一个节点，但是还是能提升效率，毕竟是必要节点。
我就想到入库时候的抓取服务：首先我们知道博主的唯一监控ID，意味着这个人我想什么时候监控都可以，无非是鉴于成本考虑，我们不可能24小时都去监控。
但是好在我们的订单执行细节都是留存在平台上的，一是为了避免后续产生纠纷，二可以进行定制化抓取服务的开发，也就变成了从执行中心推送一个定时任务到抓取服务，抓取只要拿着关键的信息蹲守，把链接获取，更新至系统里就可以了，再一次减少了人工的低价值劳动。
二十一、总结
以上就是我在这份工作中负责的全部工作和经历，希望可以给正在经历此环节的企业或者老板一些帮助。
最后小广告：目前还在找坑，有需求的老板随时骚扰，中后台方向/供给侧/中台订单，谢谢观看。
相关阅读
两年后台工作，我把这些讲给你听（上）
两年后台工作，我把这些讲给你听（中）
