产品需求-数据状态的变化以及完结节点的确定

时间:2022-05-11 17:52:18 阅读: 最新文章 文档下载
说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。
数据状态的变化以及完结节点的确定

状态的变化和完结节点的存在作用是什么?确定这一链路可以从什么要素进行思考呢?

首先感谢大家,第一次发文《6个月的B端产品新人掉残迹日记》就有8000+阅读量,对于一个小菜鸟实在是有极大的鼓励,为了回报大家,我决定发奋图强,写更多的文,遇更大的坑…

不过对于产品或者说,所谓见过鬼才会怕黑,只有自己努力去思考过,掉坑过,才能提升。看别人掉坑其实帮助非常有限。因此在新的一年里,我祝大家掉坑好,好掉坑,掉好坑~

这次和大家分析数据状态的精神状态变化以及完结节点的确定。 B端业务复杂,用到系统的工作人员众多,角色分工也多。

如果要确定一条数据的状态变化节点,则要从角色关心数据的什么,关心到哪入手。举个大家不太熟悉的例子,就电商公司部门而言,有:供应链、物流、财务、仓储、销售五个角色(客服、推广、运营等暂省略)。

一件货物从供应商处购买到售卖给买家前,进货的流程只要有:产品开发、采购、供应商发货、抵达仓库、仓库储存(产生库存)、买家下单付款、发货、物流运输、买家收货。那么五个角色要管理到的项目管理点应该是:

假设:一堆货物(产品种类和数量确定)在上架前用一个流转单号来记录它在仓库的流转状态,那么以供应链的视角来看,这个流转单号(这批货物)的状态应该有:已生成单号(初始状态)、待(已)签收、待(已)测试、待(已)入库。

有个真实的情况是,到了旺季货物较多,部门为了按时完成货物入库的操作,会先把快要超期的货物直接标记为“已测试”“已入库”,然后再“撤销入库”(多么聪明、多么为别人着想)。可是这个


功能终究被去掉了。因为财务部门盯着,在追踪到具体责任时,仓储部门无故承担部分了一大批没看到却“已入库”的货物责任。 再举个大家熟悉的栗子,网购商品的订单状态,完整的应该是:买家提交订单、买家付款、卖家订单确认、包裹等待物流公司揽件、物流公司已揽件、包裹在途中、包裹等待签收、买家已签收、买家提交评价(不重新考虑退单等特殊情况)。

购买者买家属于交易之中的买家角色,不会关心卖家的发货情况,因此后台系统只需要在特定节点返回状态变更的可以信息到前端网站即可。根据买家想要看到的信息,拆成这里可以分成三种状态变化:

订单:提交订单、付款、卖家发货、签收(完成)

其中,卖家发货就查证包涵了卖家订单确认、包裹等待揽件、物流公司已揽件、包裹在途、包裹待签收五个状态,但由于这里是订单维度的状态变化,因此具体的包裹交接状态就不必在这里展示。如果买家想要看到具体的包裹物流信息,则可以去看订单物流信息: 物流:卖家已发货、物流公司已揽件、包裹在途中、包裹等待签收、已签收(完成)

其中包裹在途中,确实可以细化到包裹在哪出库了,中转到哪,最后到达物流的哪个数据流,由哪位员工负责送货上门,再附上员工的身份再信息和联系方式,提高快递的存在感,也让买家更放心。 顺便一提,按理说订单的完结,应该是以订单被签收的作为节点(已签收)。

不过某宝的供货状态变化是:下单、付款、发货、收货、评价 把评价作为产品销售的完结点,能对买家去褒奖起赞许促进作用(差一步不去点太难受了),从中能看出某宝是希望买家去评价,给店铺和其他潜在的买家给予反馈的。

总结:


状态的变化和完结节点的存在是为了完成任务的交接,让管理者可以追踪定责到具体环节。因此节点的重绘设定要有的放矢的业务流程。还有就是有关联到系统数据变化作为操作才能的节点触发状态的变更哦。


本文来源:https://www.wddqw.com/doc/5a13534d30687e21af45b307e87101f69e31fb36.html