编辑导读：B端产品设计千头万绪，一个小功能往往业需要进行很复杂的思考，本文作者从B端零售业中订单轨迹这一小功能的设计出发，来分享一下自己对B端产品功能设计的思考，希望对你有帮助。

笔者目前在负责一个O2O订单中台产品，产品的主要功能为：聚合分发订单以实现订单的履约，所谓聚合，是获取了美团外卖，饿百，有赞等公域和私域的O2O订单，进行了订单数据的一致化标准化。所谓分发，是将数据一致化后的订单分发至门店作业系统，聚合物流系统，ERP系统，统一进行标准化拣货作业，标准化配送，标准化记账与库存管理。

接下来我们了解一下订单轨迹日志是什么：

对于B端产品来说，可用性是产品的基础，可用性一般指两个方面：

1. 解决方案能够解决企业问题；
2. 系统可持续稳定的运行；在产品运营过程中，客户反馈产品不可用，可能并不是业务解决方案有问题。

而监控是降低运维成本，保证系统稳定运行的有效手段，在B端产品中，监控一般分为两个方面:

1. 业务监控：如订单轨迹日志，凭证生成监控等，这些功能本质是对服务层的关键节点的转义描述-问题定义与预警
2. 系统监控：如数据库资源监控，redis监控等，这些功能本质是对存储层的运行情况的描述与预警；

那么我们可以看出，订单日志轨迹是B端产品中的一个业务监控功能。那么订单轨迹日志作为一个监控功能是怎么帮助我们降低运维成本，保证系统稳定运行的呢，就像我们刚刚在业务监控功能本质上描述的一样，主要体现在两个方面：

1. 关键节点的转义描述：以发生时间正序可视化展示订单状态的变更，节省运维过程中查询数据库的时间，降低理解数据库中编码的含义的难度。同时在运维过程中可以清晰的判断订单的业务进行是否正常；
2. 问题定义与预警：如订单未正常同步状态，或者退单长时间没有被审核，可能会造成财务凭证的生成的延迟，造成对账与扣减库存等一系列问题。故需要定义出什么情况下需要识别为问题，并自动进行提醒相关人员，减少运维过程中面对大量订单无法进行便捷的识别问题的现象。

总结以下，订单轨迹日志就是以发生时间正序展示订单状态变更及其变更原因，并提供异常预警的功能。该功能的业务背景和解决方案是清晰的，在中台系统中，相较于其他功能，订单轨迹日志是一个很小的功能，但是小功能在设计过程中，也经历了很复杂的思考。

原因在于：

1、B端零售业订单中台系统的复杂性；

2、B端系统功能设计过程中的资源有限性；

接下来，我从这两个方面给大家介绍，这两个属性带来的一些我们不得不去进行思考的点；

一、系统的复杂性