知识分享

  • 首页
  • 市场分析
  • 需求分析
  • UI设计
  • 产品运营
  • 产品设计
  • 项目管理
  • 新玩意儿
不积跬步无以至千里
不要停留,欣赏沿途的风景
  1. 首页
  2. 产品设计
  3. 正文

如何设计电商订单产品?

2021年9月13日 687点热度 0人点赞 0条评论

编辑导语:订单系统连接了用户和商家,用户可以通过订单看到商品购买详情,商家则可以通过订单看到购买用户信息等。而整个订单系统囊括了许多模块,如订单生成、订单计算等。本篇文章里,作者就电商订单系统设计做了梳理和总结,一起来看一下。

各位小伙伴好,本文是电商产品设计系列文章的第八篇,订单产品。在电商系统中,订单是连接用户和商家之间最重要的交易信息系统,本文就来讨论一下订单相关的内容。

一、订单的生成与状态

1. 下单过程

电商下单的过程相信大家都不陌生,我们以从购物车下单为例,可以看到一次下单过程涉及的主要前端页面有购物车选择商品页、订单确认页、收银台支付页、订单详情页、订单列表页。

可以看到,下单过程中重点有3个,分别是订单金额计算、库存校验、过程信息清晰展示。

商品金额计算包括商品价格、运费、优惠活动的计算。

库存校验主要判断库存是否足够、用户是否有购买限制、库存的锁定与扣减。

过程信息清晰展示包括优惠明细、子订单明细、商品主图/名称/规格/数量的展示、运费/优惠券/促销的展示。

其中订单详情包含了最多的信息,主要包括用户信息、基础信息、收货信息、商品信息、优惠信息、支付信息、物流信息、其他信息,包括的详细信息见下图:

总结来看订单的下单过程如下:

2. 订单计算

在下单过程中,金额的计算是流程中最重要也是用户最关心的部分,订单应付金额=商品金额(SKU金额合计)+运费-总优惠金额。

我们分别来看这几个值。商品金额即商品原价,不扣除任何优惠金额,但是注意和划线价进行区分。我们在购物时,可以在商品详情页查看商品的运费金额,商品详情页的运费是根据商品的运费模板来计算。

以下图为例,我们可以看到商品是满一件包邮,其他常见的包邮规则还有满XX元包邮,某一区域包邮等。

以下图的运费模板为例,我们可以配置的关键信息有计费方式、配送区域、指定区域的首费与续费,若想设置包邮将对应条件下的邮费设置为0即可。

实际生活中我们经常会发现有些商品特价促销,9.9包邮,而我们日常寄快递都需要6元及以上,他们是怎么做到这么低的价格包邮的呢?

实际当寄件具有规模效应后,实际运费能压到非常低的价格,一般作为物流公司大客户来进行议价。

影响议价的因素主要有单量、所在地区(如义务优势)、包装重量与大小等。我们从某商家论坛找到的数据显示日均单量的200单以上时,价格可以谈至1.5元左右一单,实际运费较低。

但是随着电商发展至今,我们我们发现越来越多的商品都有包邮的服务,现在很多小伙伴如果发现商品不包邮相信都会犹豫之后再下单,所以在包邮盛行的今日,越来越多的商家会将运费计入商品成本,从而提供包邮服务,降低用户下单决策成本。

订单的优惠来源包括促销活动、优惠券、积分抵扣、会员折扣等。当涉及多种优惠活动同时进行、不同商品参与不同促销互动时,优惠金额的计算详见后续章节。

订单计算完成后最后一步是订单支付,这一部分主要包括支付方式,目前主流的是使用第三方支付,如微信支付和支付宝支付,这部分的对接详见第三方支付API文档,这部分后续我也会单独写一篇文章介绍一下。

订单的支付主要包括直接支付父订单,或者选择部分子订单进行支付。

3. 订单状态

在一次完整的订单过程中,订单有非常多的状态,主要的订单状态包括待付款、待发货、待收货、已完成。

  • 待付款:用户提交订单,尚未支付的状态。由于待支付状态会锁定库存,所以一般会设置超时自动取消。
  • 待发货:用户付款之后,等待商家发货。
  • 待收货:商家已发货,等待用户收货。
  • 交易成功:用户确认收货后,订单已完成交易。
  • 交易关闭:付款之前取消订单,或售后完成后订单全额退款。
  • 售后中:非订单状态,指订单有对应的进行中的售后单,如用户退换货、退款。

我们知道,订单状态决定相应服务体系,如“待收货”状态下是否可以确认收货、申请退款。同时,订单状态与售后状态相互独立,他们不是一个状态字段但是可以做关联。我们上述说的是订单的外部状态,即展示给用户查看的状态,而订单内部的状态指订单在仓库层相关的操作,这部分的操作对应的是“待发货”状态。

二、父子订单拆分

1. 父子订单

当我们在在线商城购物时,经常会遇到商品属于不同卖家或因商品数量、重量等问题需要拆单的现象。这个时候我们通常会生成两种订单号,一种是拆单前订单的订单号,另一种是拆单后的订单后。

其中父订单用于记录用户这一次下多单的行为,还有合并支付。如果有跨商家优惠,父订单可以对应到相应的优惠,然后对各个商家进行分摊、子订单用于追踪发货物流、售后以及财务结算的依据,用于记录优惠信息。用户关心的是订单的订单状态、物流状态、售后状态、售后金额,这些都会以子订单为单位进行跟踪。

注意,在订单产品架构的设计中,如果使用了父子订单的设计,系统中并不是需要拆单的订单才有父子订单,而是所有的订单都需要生成父子订单。

2. 订单拆单

影响父子订单拆单的规则有多个,主要有平台的不同店铺商家、不同的发货仓库、品类特殊包装要求、物流因素、商品价值等。

根据拆单时间的不同,我们可以分为支付前与支付后的拆单,支付前主要是拆订单——拆成父子订单。支付后主要拆发货单——拆成子订单和多个包裹。

最好在下单过程中能拆好就拆好,避免后续判断。但是比如第三方商城订单、仓库发货限制等因素会导致生成订单后仍有需求拆单。

3. 优惠分摊

订单支付时非常重要的一个环节就是计算优惠的分摊,即订单内所有商品参与一个活动后,活动优惠的金额分摊各个商品后的金额。

为什么要计算优惠分摊呢,主要作用有:

  1. 使用优惠后计算每个商品实付金额,用于后续核算商品利润。
  2. 作财务上的结算用。
  3. 商品售后时计算应退商品金额。我们以一个实例来分析订单金额的计算:

子订单1中各商品分摊的优惠:

如果退回了子订单1中的商品1,此商品实付205.12元,若退全款则退款205.12元。除了退现金外,虚拟资产也要退回,例如积分、充值费用等。比如该商品若全额退款可退回1.03元——103个淘金币。若全额退款则部分情况下优惠券退回,部分退款则一般不退优惠券。

三、从下单到发货

1. 订单发货流程

用户下单后,接下来就是安排发货。

根据商家体量的不同,发货方式也会有差异。小商家一般采用手动打包、线下跟踪。发货后,在商家后台填写物流信息;中小商家利用第三方ERP管理订单,统一发货,并自动回传物流信息;大商家或自营平台则有自己独立的ERP或独立的WMS,并且会有适合业务的定制化流程。

订单发货时首先涉及的是拆单,因为仓库都是根据订单为单位去进行发货,我们来梳理一下订单全流程中,拆单的过程:

第一次拆单拆的是订单,指用户同时从购物车提交订单,拆分生成多个子订单。第二次拆单是拆发货单,如果一个订单需要拆分成多个包裹发出,我们需要在调度层进行拆单,下发给仓库多个订单。

注意,这里一般不建议在仓库层拆单,因为在仓库层拆单不好监控。

上图展示的是订单的前台显示状态,但是对应后台订单层订单发货的状态非常复杂,一个前台订单状态对应非常多后台发货相关步骤的流转,具体见下:

上面讲的是普通实物商品的常规发货流程,实际我们还会碰到其他的订单类型,不同业务有不同的订单,不同的订单有不同的订单流程。

实物商品中,最常见的是普通实物商品,走的是上述的常规订单流程。第二种是实物+服务的商品,比如售卖家电并提供上门安装调试服务。在这种情况下,实物子订单和安装服务子订单相互独立,在一个父订单下绑定,等后续安装服务完成后,订单状态才算完结。若客户不要求安装服务,则涉及到服务费用退款。

虚拟商品中,一种是纯线上的服务如话费充值、游戏充值,这种生成订单后,会调用第三方服务,完成发货。注意这种订单需要设置多久内允许取消。另一种是线上下单线下服务的,如OTA、O2O等,这种订单要确保用户享受到服务、进行财务结算,注意这种类型订单的退款流程。

2. 订单数据分析

订单在交易的过程中,系统会记录订单的数据,便于数据分析指导之后的经营生产。我们需要从订单的流量、品类、交易三个维度进行分析。

首先是流量维度,即分析店铺、商品的访问与转化等数据。流量分析核心指标有:

  • 浏览量PV、访客数UV、跳失率、人均浏览量、老用户占比;
  • 商品访客数、商品浏览量、加购人数·下单转化率、下单金额、下单数;
  • 支付金额、支付用户数、支付转化率·客单价、整体转化率。

流量的分析维度有整体、流量来源、核心页面。

其次是订单商品品类分析,分析核心指标有:

  • 商品访客数、商品浏览量、商品收藏人数、商品加购人数;
  • 加购转化率、收藏转化率;
  • 下单用户数、下单件数、下单金额、下单转化率;
  • 支付用户数、支付件数、支付金额、支付转化率;
  • 客单价、访客平均价值。

品类分析维度有品类、商品、新品。

最后是订单交易数据分析,其交易核心指标有:

  • 访客数、下单用户数、下单金额;
  • 支付买家数、支付金额、客单价;
  • 下单转化率、下单支付转化率、支付转化率;
  • 商品成本、运费成本、确认收货金额。

交易分析维度有整体、明细。

四、总结

总结一下本文内容,主要有三部分的内容:订单的生成、父子订单、订单的发货三部分。

  1. 掌握订单生成:从用户提交订单,到支付、发货、收货的订单状态变化,订单信息结构,对于订单可以进行的操作等。
  2. 父子订单:父子订单的作用,优惠分摊规则与作用,如何计算订单金额。
  3. 订单发货:了解订单发货的过程,内部状态和外部状态的区别,多种订单类型(不同的业务场景,订单处理流程有区别),订单数据分析(交易、商品)。

下图是整个订单的产品架构:

在电商系统中,订单是非常重要的模块,订单记录了关于本次交易的所有信息,包括商品信息、价格信息、支付信息、物流信息、收货信息等等,并且随着订单的变化其状态也在发生变化,我们需要将这些状态清晰的展示在前台,展示给用户。

关于仓库层的一些变化本文并未作详细讲解,后续我会单独写一篇文章探讨一下WMS系统相关的内容。

以上就是订单模块所有的内容了,下一期,我将分享在线支付模块相关的内容,尽请期待。

 

作者:书丰,公众号:书丰产品记

本文由@书丰 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!

标签: 暂无
最后更新:2021年9月13日

小虾米

同理心,洞察力!

点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复
最新 热点 随机
最新 热点 随机
拍10部火1部,道观也来凑热闹,短剧成吸金神器? 为什么二次确认后,用户依然会误删? 新零售SaaS架构:面向中小连锁的SaaS系统整体规划 AI时代下浅谈XR中的渲染技术 基金理财之客户需求分析 业财一体化数字化(一) 酒店代理的灰产江湖:0库存、赚4成差价、月入16万 探索工具型产品体验度量模型-行为度量理论篇 飞猪、携程们的下半场:吃工具属性老本,补内容短板 AI产品经理 | 入行AI的必备知识 3D 文件格式的江湖纷争 在线音乐等待“第三极” 小程序里卖剧,8天赚1亿? 卖爆抖音后,中式汉堡将成为一场“虚火”? 电商包邮背后隐藏的小心思 县城咖啡之战的最后赢家是谁? 字节跳动再战长视频,这次有何不一样? 网文IP的风,吹到“下饭剧”? 提升B端产品易用性:搭建帮助体系 小红书关停“自营电商平台”,作何打算?
从虚拟偶像到虚拟主播,一场TO C到 TO B生意的大迁徙今天我们来聊一聊小红书电商盘点一下那些虚实结合的文本输入方式自动驾驶,又到黎明前?万亿规模能源产业互联网【能链】为何一枝独秀?经营指标层面深度解读骑手需要的不是同情,而是尊重数据更新|不只是一个更新按钮而已名实唯一性:数字与AI经济里的那些潜规则实战分享!系统可见原则在交互方案中的运用从商业模式入手,搭建一款产品的底层拆解框架小红书走到命运拐点微信的聊天记录占比,被网友玩成了新一代 MBTI ?SaaS产品数据分析之指标与标签一篇文章搞懂一个系统之 SRM 系统一个真秀才倒下去,十个假靳东站起来谈谈在B端落地第三方大模型的步骤从0开始设计产品搜索功能(一)瑞幸的“9块9”突围战,只需几滴茅台?如何从0-1建设企业微信SCRM顶流网红“秀才”翻车,“中老年收割机”易主?
产品周报156期 | 拼多多年活跃买家数达8.24亿,“淘宝特价版”APP正式更名为“淘特” 需求价值量化及优先级排序方法 一个真秀才倒下去,十个假靳东站起来 探索新媒体时代的内容营销,挖掘UGC传播的关键点 【Axure教程】高保真密码输入框 淘特凶猛,拼多多持重 在线K歌:起于K歌,长于社交 为什么微信读书后,还要推出微信听书? 家装产业化的新特点与新机会 从B转C后,我对C端产品经理的3个能力,有了更深认知 贴吧豆瓣类圈子社区(二)圈子主题大小有上限 起点会员7周年钜惠来袭,大额优惠券免费领!最高立减1000元! 订阅制的后台设计应该怎么做? 熊猫不走3:未来3-5年发展面临的新挑战与应对战略建议 视频号商业化的底层逻辑 大厂暗战线上演唱会,靠情怀赚吆喝? 基金理财之客户需求分析 「24小时直播商超」取代「四大天王」? Axure高级教程:模拟Axure文件上传进度条效果 提升用户分享率的N个套路(上),让你睡觉的时候用户依然增长

COPYRIGHT © 2023 知识分享. ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang