2B路由可视规划

大家好，最近出差了一趟，收集了一些物流运营/系统类问题，其中一个就是今天要聊的主题——路由可视。这个大家应该很熟悉，日常京东/天猫买东西，都会跟进下自己的货物都哪了，什么时候到，商家发哪个快递公司等，这些都是路由可视的一部分。目前各个商城都做得差不多一样。2C是相对简单的场景，今天聊聊2B的，这个相对来说复杂点。

首先，先理解下2B客户对可视需求。

1、在哪里看路由可视内容，2C你用京东商城下单你就在京东商城看路由可视就行，但是2B如果公司场景复杂就不一样。可能会涉及到很多个系统，小编目前接触的2B复杂起来居然有10个系统。这个是主要的区别。

2、路由可视内容都哪些：

a.从哪里发货，运输方式是什么，用哪个物流，物流单号多少

b.预计什么时候能到

c.仓配路由节点：货物目前在哪个环节哪个位置，是否出库，是否揽收，运输到哪了，谁来派送联系方式多少，签收场景及签收状态，路由可视有图文两种结合。

3、什么时间可以看：

a.下单前：可以看到b预计什么时候到或者a预计什么时候发货

b.下单时：可以选择预计什么时候发或者什么时候到

c.下单后：可以abc所有内容（部分节点到节点后展示）

针对2B客户需求，解决方案大致思路

1、各场景可视系统梳理，涉及到系统多个，可以抓主要系统来展示可视

2、可视内容梳理，大致内容如上提到的abc几个点。因为2B渠道一般会有很多项目如前面几篇提到的物流降本一些策略，这些项目会影响路由轨迹的预计发货时间/预计送达时间，所以最好有个项目标签让客户知晓为什么时效会是这样。

3、可视的视角及单位。可视有2个视角-客户和物流部门。

客户视角一般是看订单：若订单≤物流最小单位时候，1个订单1个路由轨迹；若订单>物流最小单位时候，1个订单会有n个路由轨迹，类似目前快递的子母件一样，轨迹展示就会复杂。

物流视角是看最小单位：如快递最小单位：快递单号，有子母件时是子件单号、母件单号（本质是物流的箱）；零担最小单位：零担单号+箱号，箱号一般是单号+01/02/nn（本质也是物流的箱）；城配最小单位：配送交接单号，一个车送一个点的货物集合。

4、可视时间节点，需要根据各个场景进行设置，遵守一个原则，若当下能获取的可视信息全量展示就行。很多节点信息受到下单、库存、分仓、进单、出库、定时等节点影响，这些就会影响到发货时间、到达时间等计算。所以节点可以粗分3个下单前、下单时、下单后。

5、可视时间影响因素及计算规则。这个是2B最复杂的地方，2C大部分追求有订单及时发及时送达。以预计送达时间为例，预计送达时间=预计/实际发货时间+标准在途/实际在途（有实际时实际优先），发货时间的影响因素有运输方式、发货仓/商的截单时间、订单是否超售、订单是否锁单、订单是否需要hold单、是否需要合单/集单/拼单、发车班次等。在途时间的影响因素有是否要换仓发货、是否有改地址需求、是否需要定时送达、标准时效的参数准确性及细化颗粒度等。这个影响因素看每家公司关于订单处理的规则情况。

6、可视体验，这个是最容易被2B的可视方案忽略的。目标2C可视基本是两个层级，第一不需要点击物流看订单就能看到预计什么时候送达，有点写材料需要结论先行的感觉，这样可能都不需要再点击查询物流查看了，第二个就是需要点击查询物流查看，这个时候看的是全量的可视内容，当然很多2B的可视还会比2C少了个地图可视。这个也是一个体验点。还有一个就是可视节点归类，目前主流是6个归类：已下单、仓库处理中、已揽收、运输中、派送中、签收。

7、可视信息存储，实际可视数据是多个系统数据组合起来的，下单是销售系统、涉及库存还需要进销存系统、仓库处理信息是仓储系统、运输是运输系统、快递/零担出库到签收是承运商系统回传，城配类数据是司机app操作回传。所以需要一个系统进行组合信息存储。然后需要的系统从这拿数即可。

以上，关于2B路由可视的一些看法，大家有更好的建议欢迎留言或私信讨论。