07订单中心

产品经理电商系统之订单系统(OMS)概况：概况、订单下单、订单拆单、订单逆向流程、服务订单流程、订单数据统计、—购物车。

07订单中心

• 概况
  • 不同行业的订单
    • 类型不同、规则不同
  • 订单来源
    • 自营平台
    • 第三方平台(天猫、京东等)
    • 线下订单
  • 下单方式
    • 购物车下单和直接下单
  • 订单状态
    • 多种订单状态、变化多样
• 订单下单
  • 用户下单时，订单信息在各个系统之间进行信息校验和流转，最后生成订单
  • 内容
    • 用户信息
    • 订单基础信息
    • 收货信息
    • 商品信息
    • 优惠信息
    • 支付信息
    • 物流信息
    • 其他信息
    • …
  • 父订单与子订单
    • 从购物车选中多个店铺的多件商品时，会将这次购买行为拆分成三个店铺的子订单
      • 这次整体的购买行为记录在父订单下，当系统首次提交订单结算时，会合并子订单，针对父订单进行结算
      • 当提交订单后结算中断，或结算之后，系统在更新订单状态、物流追踪时，针对的就是子订单
    • 自营商城，不同仓库的商品合并提交，或订单的商品过量时，都会拆分成多个子订单
    • 拆单时机
      • 生成订单前拆单
      • 生成订单后拆包裹
  • 优惠分摊
    • 优惠来源
      • 促销活动
      • 优惠券
      • 积分抵扣
      • 会员折扣
    • 订单实付金额
      • 订单实付金额=商品金额(SKU金额合计)＋运费–总优惠金额
      • 其中:总优惠金额=促销活动优惠金额＋优惠券优惠金额＋积分抵扣金额
    • Question
      • 订单部分取消时，怎么退款?
      • 跨店优惠的订单，财务上怎么结算?
      • 多个子订单,菜一个子订单取消时怎么退款
      • 使用了多种优惠,叠加后每个商品到底实付了多少?
    • 优惠分摊
      • 系统规则vS人性
        • 跨店优惠活动、优惠券:促进销量
        • “菇羊毛”党:恶意退货退款
      • 退货退款的原则--优惠分摊，偏向用户
      • 下单时就将优惠金额、实付金额按比例分摊到子订单、商品上，方便退款处理
    • 实际中的多种服务
      • 第三方支付、分期付款、活动付款...
      • 其他渠道订单
        • 京东
        • 天猫
        • 有赞
      • 在订单处理上，会出现多种情况，随机应变。业务约复杂，订单的金额处理越复杂!
  • 订单状态
    • 待付款
      • 用户刚提交订单，尚未付款，等待用户支付。由于待付款状态会锁定库存，所以一般会设置超时自动取消
    • 待发货
      • 用户付款之后，等待上架发货
    • 待收货
      • 商家已发货，等待用户收货
    • 交易成功
      • 用户确认收货之后,订单已完成交易
    • 已取消
      • 付款之前取消订单。超时未付款或用户取消订单都会产生这种订单状态
    • 售后中
      • 用户在付款后发货前申请退款，或商家发货后用户申请退换货，都会产生这种订单状态。订单售后状态又分许多种
    • 交易关闭
      • 当售后完成后的订单状态。“已取消”的订单状态可以合并到“交易关闭”中
• 订单拆单
  • 拆单的影响因素
    • 父订单/子订单
      • 客户在下单时，为了发货和结算方便,需要对订单进行拆分
    • 拆单的影响因素
      • 平台的不同店铺商家
        • 商品归属权不同，涉及财务结算和发货的问题，店铺商家不同需要拆分订单
        • 如:京东自营和平台各商家的商品在下单时会拆分成不同的子订单，因为售后入口不同;不同淘宝、天猫店同时下单会按照店铺进行拆单
      • 不同发货仓库
        • 由于发货仓库不同，按照商品归属的仓库进行拆单，若有多仓有货，还应按照地域时效选择仓库进行拆单
      • 品类特殊包装要求
        • 由于商品属性和价值的不同，同样会产生拆单需求
        • 如:易碎品需要特殊包装，超大物品(儿童座椅、轮胎）需要单独包装。
        • 甚至有些品类不同的商品不能放在一起，都需要按不同情况来定义拆单规则
      • 物流因素
        • 不同物流公司对单个包裹的重量或体积都由特殊要求。
        • 需要依据SKU的毛重和体积计算包裹总重量和体积，超出物流公司限制的也需要拆单
      • 商品价值
        • 海涛消费限额、贵重物品单独发货
        • 根据当前国家政策规定
          • 跨境电商零售进商品的单词交易限制为人民币2000元
          • 个人黏度交易限值为人民币2万元
          • 当单次购买超过2000元(单仓)之后，就需要对订单拆单
  • 拆单节点
    • 拆单时间点
      • 下单时，拆订单
        • 父订单——子订单
      • 支付后，拆发货单
        • 订单——多包裹
      • 最好在下单过程中能拆好就拆好，避免后续判断;
      • 生成订单后，仍有需求拆单。如:第三方商城订单、仓库发货限制等各种因素
    • 拆单后的前端显示
      • 购物车提交订单，合并支付
      • 中断流程后，再操作针对子订单
      • 同一个子订单可能会对应多个物流单
• 订单逆向流程
  • 发起售后的时间节点
    • 待付款状态下取消订单
      • 待付款
        • 用户取消订单/超时未支付
          • 已取消
      • 当用户提交订单后，主动取消订单或用户超时未支付时，订单的状态变更为“已取消”
    • 待发货状态下取消订单
      • 在用户支付订单后，发货单可能已经推送至WMS，甚至已经交接发货，状态未及时回传更新。为避免损失，先暂停订单出库，在调度中心查询订单是否推送至仓库
        • 若尚未推送，则停止推送
        • 退已经推送个，则去WMS拦截发货，暂停出库流程。
          • 若暂停失败，则拒绝“取消订单”申请，回复原因“订单已出库”
          • 若暂停成功，“取消订单”申请通过，进入退款流程，同时通知调度中心该订单取消，wMS订单进入返库流程。
      • 当“待发货”状态时，用户申请取消订单，判断当前订单走到哪个流程，能不能中断发货
        • 如果可以，取消成功。如果不行，拒绝申请
      • 如果支持订单部分商品退款，情况比较复杂
        • 当SKU全退时，原订单状态直接变成“交易关闭”
        • 当发生订单中部分商品退款时，原订单状态不变，维持“待发货”状态，同时生成部分售后订单
    • 待收货状态下申请退货或退款or 交易成功状态下申请退货或退款
      • 当发货之后，售后申请需求退货
      • 部分商品退货
        • 当SKU全退时，原订单的状态直接变成“交易关闭”。
        • 当发生订单中部分商品退货、退款时，原订单状态不变，维持“待收货”或“交易成功”状态。同时生成部分售后订单。剩余的订单商品仍l旧允许进行售后
      • 订单售后状态
        • 待审核
          • 用户提交退货、退款申请之后，等待审核的状态
        • 待退货入库
          • 退货申请审核通过，等待用户退货入库
        • 待退款
          • 退货入库成功后，等待退款给用户
        • 待换货入库
          • 换货申请审核通过，等待用户换货入库
        • 换货出库中
          • 换货入库之后，生成换货出库单，订单出库
        • 售后成功
          • 当退货、退款成功或换货成功之后，流转至“售后成功”状态。
          • 退货退款的售后成功在主流程下属于“交易关闭”
      • 思考
        • 怎么允许用户发起多次售后?譬如换货之后换货
        • 财务上对售后订单数据的记录，每一次订单数据的变化都需要生成相应单据凭证
      • 注意:在设计逆向流程时，应保证数据变化的可追溯性，否则会对财务数据和订单统计数据造成影响。
  • 售后发起方式
    • 用户主动发起
    • 客服发起
• 服务订单流程
  • 实物商品订单
  • 纯服务订单
    • 线上购买服务，线下接受服务
      • 如:线上电影票
    • “待付款”状态时，取消订单或超时未支付，订单关闭
    • “待服务”状态时，申请取消订单，判断核销码是否使用，作废核销码之后进行退款
    • 当“交易成功”后用户申请售后，就需要客服介入，当确认申诉属实时，进行退款。
  • 商品服务订单
    • 线上购买商品，商品收货之后，去指定门店接收商品附加服务如:轮胎服务订单
    • 对商品服务订单，商品发货之后将服务核销码发送给用户，当商品到货后，提醒用户进行商品附加服务。
      • 服务核销后，交易流程才算结束
    • 在系统中，可以将服务当作一种特殊类型的SKU来处理如:购买轮胎，赠送轮胎安装服务当安装服务绑定到轮胎上，类似赠品
    • 当购买此类商品后，订单进入商品服务订单流程。
    • 在下单时客户可选择服务门店，也可以不选，后期通过人工客服指定门店。
    • 当选择门店之后，可选择送货到家或直接送到门店，当商品到货后，进行商品服务。
    • 商品服务订单录成不同与一般商品的流程在于
      • 当实物商品发生售后时，服务核销仍有效。
      • 服务商提供服务后，还涉及相应服务的结算，为避免服务商刷单，应提供相应核销码作废功能
• 订单数据统计
  • 订单数据
    • 常规统计
      • 倾向于财务统计，包括
        • 销售额
        • 毛利
        • 成本
        • 纯利润
        • 客单价
        • -…"
  • 流量分析统计
    • 订单交易纬度
    • 商品纬度
    • 订单来源
  • 订单交易纬度
    • 统计周期内的订单销售额(统计周期可以是日、周、月或自定义)订单量:统计周期内的订单量
    • 客单价:统计周期内，已支付的订单平均金额
    • 下单用户数与支付用户数
    • 支付新用户数与支付老用户数
    • 订单金额分布:订单金额在个价位之间的占比
    • 地域分布:分析各区域的购买转化率及订单量、客单价，有针对性地进行营销
  • 商品分析纬度
    • 被下单商品数
      • 统计周期内，被下单数>0的上架商品数总和
    • 被支付商品数
      • 统计周期内，被支付订单数>0的上架商品数总和
    • 被访商品数
      • 统计周期内，被访问UV数>0的上架商品数总和
    • 商品收藏次数
      • 统计周期内，商品被来访者收藏的次数
    • 商品销量统计
      • 统计周期内，按单一商品纬度统计上架商品的销售数量，按品类统计销售额、销量
    • 加购件数
      • 统计周期内，买家加入购物车商品件数之和。
  • 订单来源纬度
    • 订单的来源媒介
      • 站外广告渠道
      • APP
      • 用户端
      • H5商城
      • PC端
    • 记录每个订单的产生流程，等关键步骤的数据分析，包括
      • 在订单创建之前的商品浏览
      • 加入购物车
      • 提交购物车
    • 追踪订单来源，包括
      • 来源媒介
      • 来源关键词
      • 来源网站
• 购物车
  • 购物车的妙用
    • 凑单
    • 促销
    • 收藏
  • 购物车的设计
    • 展示信息
      • 商品标题、商品图片、价格、数量、规格(颜色、尺码等)
      • 商家（自营或店铺)、库存状态(是否紧张或缺货）等。如果是跨境商品，还需要显示税费。
      • 初次打开或刷新时，商品信息、促销信息都同步更新
    • 商品选中策略
      • 默认全选
      • 默认全不选
      • 云端同步选中状态
    • 离线购物车
      • 在未登录状态下把商品加入购物车，登陆后和现有购物车合并
    • 库存监控
      • 在库存紧张或无货的时候，会在前端给予提示
      • 无效商品进入无效商品列表中，可批量清除
    • 排序分类
      • 购物车底部，添加为商品推荐区域
      • 商家店铺，将不同店铺的商品分开
      • 优惠不同，在购物车中将优惠活动相同的商品聚合在一起
      • 加入时间，按照加入购物车的时间倒序排列，最近添加的商品排列在前
      • 显示促销相关信息，类似满减、满增、赠品等信息
    • 促销信息
      • 在购物车展示促销信息对提高客单价有良好效果，京东是目前做得最好的
    • 商品推荐
      • 在购物车底部，是最好的商品宣传位
    • 价格监控
      • 购物车的商品价格变动时给用户提示，会对用户的消费决策产生影响
    • 编辑
      • 删除商品、加减商品数量、更改商品规格等
  • 购物车结算
    • 在购物车中计算订单金额时，需要将优惠金额算进去，但是这部分优惠只包括促销活动，无法计算优惠券等优惠。
    • 购物车在PC端和移动端的设计不同