两年后台工作，我把这些讲给你听

十五、核心指标

供给侧的核心指标是：

• 新增注册数，成功注册的机构数；
• 新增入库数，成功在库内建博主主表数；
• 博主审核速度：审核时间-提交时间，刨去夜间因素；
• 人均处理数，总提交审核数/工作人数；
• 新增上架数：分业务线、分平台、分来源看；
• 动销率：卖出去的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种最核心的抽象。