后台系统_订单管理操作流程

发布时间: 2022-03-14 11:39:05
订单管理是后台系统中较为重要的一部分,它记录了所有的交易数据,可以对订单进行监控和操作,与用户、运营、财务等都有着密切的关系。以下就来总结一下后台系统中订单管理的设计。

一般来说,订单管理后台的操作用户都是公司内部人员,但需要支持的实际上还有C端用户的需求。所以在设计时,订单管理系统需要包括两部分的内容:

一是要能够与C端用户在整个订单流程中各个场景的操作相对应;
另一个是要能满足公司内部相关部门的需求,包括财务、采购、运营等。
订单流程
首先,在设计后台前,需要明确的就是C端用户的操作场景以及在该场景中后台需要支持的操作。如下图所示,是一个简单的订单运转流程:
当然,在实际业务中,订单流程远没这么简单。比如在用户结算付款/取消订单/退款/退货流程中,可能还会涉及到满减、满赠、优惠券、打折、积分抵扣等情况,这种订单金额不仅仅只包含了商品金额,一般来说,订单金额=商品金额+运费-优惠-积分抵扣等。

所以,在用户结算时,就会涉及到不同模块和数据的交互(一般来说,满减满赠或者运营活动相关的数据,都是有单独的表记录的),反之,取消订单/退款/退货也是如此。

订单状态
明确了订单流程之后,就可以知道从订单创建到交易完成这整个过程中所包含的状态。
整个流程可分为未付款、已付款待发货、已发货和已收货四个阶段。而涉及到的模块主要有支付和库存。以下就来介绍一下订单在各个阶段所涉及到的内容:


订单列表设计
首先,列表即是数据的展现。而数据的展现又来自于实际的需求,除了上述所说的状态及操作外。还有一个重要因素就是订单信息,信息的详细与否直接关系到订单的跟踪以及后续数据的分析。对于整个系统来说,数据是极为重要的部分吗,所以在设计字段信息时,需要尽可能的全面。


补充:在实际公司业务中,可能还会涉及到向经销商直接供货的情况,可能是线上,也可能是线下,但即使是线下,订单也是需要进入到系统的,因此在设计时,需要实现了解业务操作的细节;如果是线下订单,需要考虑订单的创建人可能会是哪些角色,不同角色创建的订单流程也会有所不同。

从结构上来说,订单页面其实也就是个列表页,主要包括搜索区、列表区和操作区。

列表区域
前面已经介绍了订单详情,包含的信息较多,所以后台列表中不可能直接显示订单相关的所有字段,此时就需要有所取舍,选择比较重要的字段比如订单编号、支付流水号、订单状态、退款状态等信息。而剩余的其他信息,可以通过下级页面或自定义菜单来显示。 这里需要特别注意的就是订单的状态和操作,在设计前,需要对业务流程相当熟悉,明确场景中的每种状态以及各状态下的操作权限。

其他因素
1. 订单是否需要拆分:比如OTA中的订单系统,一张订单可能会被拆分为酒店子订单和各种单项子订单,而这些子订单有可能是由不同的人去处理,而且有的时候是需要支持客服人员可以在订单中继续增加子订单的,电商平台也一样,通常都会包含一个主订单号和多个子订单号,这时就需要考虑在退货/退款时是否支持根据子订单的维度退款;
2. 订单的取消:除了用户,内部人员在哪些情况下可以主动取消订单,而该种情况下取消订单,流程该如何操作,又该给用户怎样的反馈;
3. 产品/商品来源:在用户下单前,是否已有库存,当然,在一般的电商系统中,基本上都是已经有库存才可以售卖的,但比如在OTA这样的订单系统中,产品即服务,是具有不确定性的,所以在生成订单的时候,同时要根据其子订单生成对应的供应商订单,用户下单后,企业再去向供应商下单预订,其实就比较类似于代售的情况;
4. 订单生成规则:一般情况下,商品的来源和渠道各不相同,很多时候为了便于区分,可能就需要在订单的生成规则里加入一些特殊的字符进行标识;
5. 活动订单:当平台在做活动时,商品的价格一般都会出现大的波动,那么就需要考虑此时下的订单是否需要单独管理;
6. 订单数据问题:在实际运转中,可能还会出现不同表的订单时间不一致、数据延时、订单重复、漏单等情况,这些都需要引起重视,及时优化程序;
7. 权限问题:不同部门、不同级别的账号,会拥有不同的数据权限和操作权限。

操作区域
对于订单的操作,基本上就是一些确认、审核、锁单、跟进、退款等。

搜索区域
在订单列表中,因为涉及到的信息和状态比较多,所以为了提高工作效率,需要将常用的重要的条件作为筛选项,以便于快速查找。 一般情况下,搜索区域主要包括:订单编号、订单状态、付款状态、退款状态、交易时间、支付渠道、平台、区域等,根据业务范围而定,当然,显示哪些条件,还要看权限等级。