大家好，很高兴继续和大家一块继续学习DDD的相关知识，接下来我会用整篇的文章介绍电商的12个主要核心业务系统，咱们本节课会把电商的所有核心业务流程梳理明白，在以后的课程中用DDD的规范去带着大家落地项目实战。
一、那些年我们一起追的架构师

作为一名架构师，我们要专业，不仅会设计模式、架构分层、高效算法、MVC、DDD等专业知识，还要会服务器选型、异地多活、数据冷热备份，更要会项目管理、风险把控、团队管理。 作为一名优秀的架构师，我们不仅需要写出惊天地、泣鬼神的代码，还要在同事出现问题或者撂挑子不干的时候，你要主动给老板一个肯定的眼神，不怕有我在。还需要在团队或者项目出现风险的时候，需要你主动突击，重点突破，化风险为安全，有你在地方团队就是江湖。 作为一名优秀的架构师，更需要你在会议上滔滔不绝、如若无人、眉飞色舞、眼神暧昧，让不懂架构的研发小弟听你的方案拆解，只一刹那间，便有"众里寻他千百度，蓦然回首，方案就在灯火阑珊处"的拍案叫绝，让不懂技术的产品运营妹子看你的眼神迷离，就好像"落霞与孤鹜齐飞，秋水共长天一色"。

二、谈虎色变的电商业务流程

笔者前段时间作为项目负责人和技术负责人，因为是国际项目，深度参与了某国家电商业务的上线交付工作，从业务需求的沟通到技术方案的制定以及各个阶段里程碑的划分，深感作为电商相关的工作实属不易，这其中光每个团队的负责人（包括业务、产品、技术、测试、财务、仓储、物流、供应商、法务、支付、商务）就达一百多人，光部门就横跨几十个，还没有带上每个团队具体负责的同学，想想对接就是一个大型工作量。 还好，在全体同学共同努力之下，交付工作超预期达成。在这之前，笔者只是负责技术方案设计和架构设计工作，这是第一次和业务同学（法务、财务、仓储、物流、支付、供应商）直接对接，真的是属于人生的一笔财富，在后面的课程中，我眼中的风景会一一讲给大家听。

系统的业务流程通常包括商品管理、订单管理、内容管理（产品显示页）、用户会员管理、营销活动管理、支付管理、订单履约、发票管理、财务管理、仓储管理、物流配送、客服管理、客户管理、售后管理等多个环节。通过电商系统，企业可以将产品信息上传至网站，并且配合推广活动，吸引用户进行浏览和购买；同时，用户下单后，系统会自动生成订单，进行支付处理，并且安排物流配送；最后，系统还要实时地管理客户信息和反馈。因此，一个完善的电商系统需要包括多个模块。

三、曾经的那些电商造富神话

电商行业现如今有很多成熟的商业模式，大体有一下几种

• B2C ：企业与消费者之间的电子商务，类似天猫、京东是属于此类模式，企业在电子商务平台上售卖，消费者进行购买，是最常见的电子商务模式。

• B2B ：企业与企业之间的电子商务，也可以说是供应方与采购方之间的电子商务，此类模式是解决了上游到中游的采购问题，降低采购成本，类似阿里巴巴的1688。

• C2C ：消费者与消费者之间的电子商务，此类模式对商家的包容性更大，很多是个人，比如：淘宝、微店都是此类。

• O2O ：线上到线下再到线上，线上消费，线下服务，线上核销，例如：美团、饿了么。

• F2C/M2C ：factory/manufacturers to customer，指生产厂商对个人消费者的电子商务，如网易严选。

• C2M ：customer to manufacturers，指个人对生产厂商的电子商务，强调个性化工业定制，如必要商城。

• 分销电商 ：在法律允许范围内，每个人都可以成为分销商，利用社交圈进行商品销售传播，如云集。

四、攻克电商中的"十二金刚"，打通电商DDD任督二脉

（一）、商品管理

1.商品管理的重要性

商品是电商平台运营的关键，一般在后台创建，在前台展示，有了商品，上架才能展示前端用户。同时，商品也是电商后台产品的基础，有了后台商品管理系统，才能为同类型产品提供标准化的属性，便于统一产品，为运营人员方便管理商品的上下架。通过商品管理系统将商品呈现到用户面前，才能将商品转化成订单、仓库管理、采购补货、售后处理退换货等流程
商品管理系统，是整个电商系统的数据基础，用于记录与商品有关的数据，虽然系统逻辑不复杂，但是由于操作的数据比较多，需要掌控细节，订单，营销，支付，物流等环节都需要从商品中心获取数据。

2.商品管理的典型业务场景

（1）分类管理 管理商品分类，主要起到对不同商品的归类和；分类也叫做类目，是商品管理系统最重要也是最基础的部分，当我们在设计商品系统的时候应该先设计分类系统。分类顾名思义就是将东西进行分门别类，这是衣服，这是裤子，方便我们的辨认。同时商品，规格，参数，品牌都是要挂靠在分类之下的。

商品分类如何设计？我们平时在设计分类的时候，如果只考虑设计一个分类，可能只有前台分类，然后分类的标题在前端展示，这种方式其实并不好，原因有以下几点：

• 不利于营销 ，如果我们只有一个分类我们给他起名字我们要考虑到后台的操作性，还要兼顾用户的体验是非常困难的。对于用户这个分类可以叫优秀的架构师，但是对于后台录入来说就会想什么是优秀的架构师呢。

• 不利于管理 ，如果想要删掉某一个分类，但是分类下有很多商品？这个时候就很头疼了。

• 不利于检索 ，设置丰富的前台类目可以让用户更好的找到分类，可以利用大数据分析用户喜欢搜索什么，然后给分类起名字。

解决方法就是设计两个分类，一个前端分类，一个后端分类。 后端分类是给我们自己看的，我们要把商品挂靠在后端分类之下，前端分类是给用户看的，用户喜欢什么我们就起什么名字，也就是说给分类起一个昵称，后端分类就好比我们的姓名，前端分类就好比我们额游戏ID。后端类目要尽量简洁明了让人一看就知道什么意思，同时要易于管理可以加上编号之类的，前台类目根据需求随便其就行了。 那么具体怎么设计呢？
在后台设置两个菜单一个是后台类目，一个是前台类目，后台类目就是我们平时设计的主要包含以下字段：

• 分类名称 ：分类的名称，自己起；

• 前台类目：对应的前台类目是什么；

• 描述：对分类的描述；

• 库存：这个分类下还有多少库存；

• 创建时间，修改时间：什么时候建的，什么时候修改的；

• 操作：只可以编辑，不可以删除（后台类目不可删除，谨慎）。

  
  

前台类目 ：前台类目和后台类目基本相同，不同之处在于，我们在创建前端分类的时候要注意下，要选择前端分类是挂靠在哪个后端分类之下的，具体挂靠规则我一会再说，不过前端类目一定是要挂靠在后端类目之下的哦，不然就是小黑孩，没有身份。 另外前台类目可以编辑，删除，屏蔽，即便分类下有商品删除也没有关系，因为商品是在后台分类下的，这样的话我们就可以根据营销额需求灵活的变动前端的类目。
情人节到了，那就多弄关于礼物，玫瑰花之类的分类，将其他分类屏蔽掉，冬天的时候可以将关于夏季的服装分类全部屏蔽或者删除。

（2）商品分类层级
那啥，我说说这个分类层级的问题，根据规模和业务的不同，分类的层级肯定也是不同的。那么这里呢，我是建议统一设置成三级，上衣------羽绒服------男士羽绒服，层级太少，如果商品太多是不易于管理的，层级太深也不行，太深的话就会不利于寻找，找了半天找不到也是问题，所以直接设置成三级类目。
后台具体设计的时候，我建议是后台分类直接设计成三级，然后就不要动了。这样方便管理

（3）挂靠管理 下面说说挂靠规则，首先前台分类一定是要挂靠在后台分类之下的，商品是必须挂靠在后台分类之下的，并且：
商品必须挂靠在最下级分类之下，也就是最小分类，并且只能挂靠一个分类。为什么呢？因为我们创建规格，属性，品牌都必须挂靠在最小分类之下。为啥呢，因为易于管理，如果你不挂靠在最小分类的下面，那你创建这个下级分类的目的是什么，同时挂靠多级会造成理解困难，这个商品到底是什么分类，可能想不明白。
前端分类必须挂靠在后端分类之下，对应关系是比较灵活的，一个前端分类可以对应一个后端分类，同时也可以一对N，N对1，N对N，自由组合，因为商品的挂靠已经有后台分类决定了，前台在后台的挂靠只是因为具体需要灵活运用，对逻辑没有影响。因为不管怎么样，前端显示就会寻找前端分类对应那些后端分类，而这些分类下有哪些商品。

（4）商品搜索比如我们会输出关键字查询数据、根据商品价格排序、根据其他属性搜索商品等。

（5）商品管理
商品添加、商品修改、商品删除、商品上下架、价格管理、促销管理、标签管理、商家管理、库存管理。

（6）商品评价
商品评价主要是用户收货后对商品的评价，功能点主要涉及敏感词的处理，评价的形式，以及评价的管理。评论这一块需要我们建立敏感词库，对用户的输入进行过滤。评价一般我们会分好多种形式，比如：文字评论、图文评论、视频评论、星级平评论、标签评论。 用户发表评论之后，一般需要后台进行审核，如果审核不通过需要给出原因说明，也可以设置默认好评或者评价显示的优先级等规则。

（7）商品推荐
商品推荐是商城系统比较常见的功能模块，推荐位置有很多，首页推荐，搜索结果页推荐，购物猜你喜欢。 商品推荐属于营销模块，推荐位置是非常珍贵的，一款软件就那么大，推荐的效果不仅影响用户体验还影响商业盈利，如果推荐的商品用户老是不喜欢，那么用户就会对软件产生厌倦，因为没有我想要的东西，同时也就没有商业盈利了，商品推荐分类常规推荐和个性化推荐两种

• 常规推荐 ：手动往推荐位置添加商品，或是根据简单的筛选添加推荐商品，比如销量，浏览量，上传时间等，方式比较简单，对技术要求不高，但是推荐效果不好

• 个性化推荐：个性化推荐是属于产品智能模块，比如只能排序都属于产品智能。

个性化推荐流程 ：首先要选择相关数据，就是哪些数据会影响推荐效果，哪些数据可以成为推荐的因素，主要是根据用户的行为数据进行用户行为分析，然后创造用户画像，得出用户画像与不同商品的相关性，设计算法模型，最后进行推荐。
常规推荐流程 ：数据的采集，数据的分析，用户个性化推荐，不过个性化推荐对用户规模有一定要求，运用大数据是要依赖庞大的数据基础的，这样得出的算法模型才具有实际意义，对于用户量不是太多的商城，基本是采取常规推荐。

（二）、内容系统

1.内容系统的重要性
在商城中，每个商品都有比较特别的展示方式，在品牌商城中尤为明显，因为不同的商品设计的产品显示图片也是不一样的，这样的工作量如果放在程序员进行开发，将无疑是一个很大的工作量，需要我们把业务相关的配置进行抽象剥离，把属于运营配置类的工作交给业务同学去维护，所以说，我们在后台做出好多套模版或者页面编辑之类的系统，让业务同学编辑自己习惯的页面风格。

2.典型应用场景

（1）商品列表页商品在前端的展示首先会以列表的形式，可能在首页，搜索结果页等其他页面，不管在什么页面其展示形式是固定的，一般是每行一个或者每行两个，展示商品主图，展示信息主要有商品的标题，价格，原价，标签，付款人数，点击进入商品详情页面，商品详情页面是商品信息展示的重要页面，商品的信息基本都在闲情页面展示

（2）商品详情页
商品详情页面是商品信息展示的重要页面，商城的信息流也主要是围绕着商品进行的商品页面一般有如下信息： 商品的多张图片，或者视频介绍，商品的价格区间，商品原价，商品的标题，如果自营显示自营标签，商品的点赞人数，分享按钮，添加购物车按钮，商品发货地址，快递费，销量，优惠券信息，领券按钮，服务信息，规格选择，参数选择，还有评价，详情，商品推荐。 详情页底部一般有店铺入口，客服，收藏按钮，加入购物车和立即购买。

（三）、订单系统

1.订单系统的重要性

• 对用户来说：用户在下单后实时查看订单发货状态，物流信息状态和最后交易纠纷的售后流程等。

• 对商家来说：商家管理订单状态，实时发货，处理售后纠纷处理等，更好更快的满足用户需求，提升处理效率等。

• 对平台来说：在平台运营上，监管订单，处理平台介入异常订单信息，处理需求和供给两端的纠纷，提供业务支撑，实现业务闭环，提升用户价值，完善用户体验等。

2.订单系统的难点

• 业务类型不同，订单规则不同 。订单系统搭建需要考虑实际业务情况，分商品实物订单，虚拟订单等不同业务其订单系统的设计区别都是很大，如：实物商品售卖，付费课程售卖和服务餐饮业务其电商设计都是根据实际业务划分。

• 流程复杂，分正向逆向流程 。前端用户下单时正常时的正向流程为从商品下单，发货，收货到最后的订单交易成功；发生售后异常时的逆向流程：用户申请退货，到退款结算一系列售后流程；其规则又有很大的不同。

• 信息交互复杂，逻辑性强。从订单下单产生的订单经过大约20个不同子系统的一系列信息的流转，前端展现简单的页面展现，可能后端会经过大量的系统信息校验和流转。

（三）、订单系统典型业务场景从用户下单总体流程为：用户下单：选择下单方式（购物车，直接下单）------订单下单------订单拆单------生成订单查看订单状态------交易成功或申请售后逆向流程等等；商家后台系统更改订单状态，对接发货，物流，售后和最终的数据统计等。

（1）下单方式：购物车的设计

• 基本逻辑 ：购物车入口逻辑，购物车商品库存逻辑（锁定扣减逻辑），购物车的商品分开展示逻辑；

• 价格计算器：优惠类型划分，优惠计算逻辑及展示；

• 离线购物车：登录加购逻辑，未登录加购逻辑；

• 立即购买：立即购买流程；

• 异常处理：失效商品逻辑及展示，优惠失败逻辑及展示；

• 其他逻辑：凑单逻辑，商品推荐逻辑，对接的系统信息流转逻辑。

（2）订单下单：订单信息展示

• 用户信息 ：用户账号，用户等级；

• 订单基础信息：父订单，子订单，订单编号，订单状态，订单时间；

• 收货信息：收货地址，收货人姓名，联系电话，邮箱；

• 商品信息：SKU信息，规格，商品数量，价格，商品图片，商家，商品链接；

• 优惠信息：优惠券，促销活动，虚拟币抵扣金额；

• 支付信息：支付方式，支付单号，支付状态，支付时间，商品总金额，实付金额，运费，虚拟币抵扣金额，促销优惠金额，优惠券优惠金额，总优惠金额；

• 物流信息：物流公司，物流状态，物流单号；

• 其他信息：发票信息，下单平台，分销渠道。

（3）订单下单：订单拆单

• 下单时拆订单：父订单拆子订单

• 平台的不同店铺商家需拆单 ：因为涉及到商品归属权不同，其财务结算，发货情况不同所以需要拆单。

• 仓库不同，需要拆单：一物多仓的情况下，可能按照地域时效选择仓库发货物流信息不同需要拆单。

• 支付后拆发货单：子订单拆多个包裹。

• 品类特殊包装要求需要拆单 ：如易碎品需要特殊包装，超大物品需要单独包装，有些不同品类的商品不能放在一起；

• 物流因素，超过物流运输限制需要拆单，如超过规定物流公司重量需要拆单；

• 商品价值：海淘商品消费限额，贵重物品商品价格高需要单独发货，需要拆单。

（4）订单下单：订单的计算

• 订单实付金额 = 商品总金额+运费-商品优惠总金额

• 商品优惠总金额 = 优惠券+促销活动+积分抵扣+会员抵扣

（5）生成订单：订单状态

不同业务类型商品订单状态不同，实物商品订单和虚拟商品订单状态都有所不同，订单状态最重要的是各个时间节点的数据流转，这里介绍下实物商品订单的订单流转状态：

• 待付款 ：用户提交订单，尚未付款，等待用户支付，由于待付款状态会锁定库存，所以一般会设置超时自动取消；

• 待发货 ：用户付款之后，等待商家发货；

• 待收货 ：商家已发货，等待用户收货；

• 交易成功 ：用户确认收货后，订单已完成交易；

• 已取消 ：付款之前取消订单，超时未付款或用户自动取消订单都会产生这种订单状态；

• 售后中 ：用户在付款后发货前申请退款，或商家发货后用户申请退换货状态，需要注意的是售后状态也有单独的订单流转状态：待审核，待退货入库，待退款，待换货入库，换货出库中，售后成功；

• 交易失败：当售后完成后的订单状态，"已取消"的订单状态可以合并到"交易关闭"中。

（6）订单的售后：订单逆向流程订单的逆向流程可以是用户主动发起或者客服发起，需要注意的是不同节点申请退换货，系统的处理方式不同，逆向流程复杂，还涉及到优惠分摊返还的逻辑，这里不详细介绍，以下为各个时间节点的订单售后流转情况：

• 待付款取消订单 ：用户提交订单后，主动取消订单或超时未支付时候，订单状态为"已取消"；

• 待发货取消订单 ：用户支付订单后，到"待发货"状态时，用户申请取消订单需要判断数据到哪个环节了，订单未到调度中心和就在调度中心未下发到仓库管理系统或从调度中心到了仓库管理系统（WMS系统）但拦截下来了，则可以取消成功；否则取消失败，订单继续发货；

• 待收货/交易成功取消订单：收到货物后，当SKU全退时，原订单变成"交易关闭"；当发生订单部分退货，退款时候，原订单保持不变，维持"待收货"或"交易成功"状态，同时生成部分售后订单，剩余的订单还可以进行售后。

（7）订单的数据统计

a.订单交易维度

• 统计周期内订单销售额（GMV）【最重要】

• 订单量：统计周期内订单量

• 客单价：统计周期内，已支付的订单平均金额

• 下单用户数支付用户数，订单金额分布，地域分布等等

b.商品分析维度

• 被下单的商品数：统计周期内，被下单数>0的上架商品总和

• 被支付的商品数：统计周期内，被支付订单数>0的上架商品总和

• 被访商品数：统计周期内，被访问uv数>0的上架商品总和

• 商品收藏次数，商品销售统计，加购件数等等。

c.订单来源维度

• 统计每个订单的来源：如H5，公众号，APP，小程序，pc端；

• 记录每个订单的产生过程，包括在创建之前的商品浏览，加入购物车，提交订单等关键路径的数据分析；

• 追踪订单来源：包括来源的网站，关键词，来源网站等等。

(四)、营销活动系统

1.营销活动系统重要性
一个好的活动营销不仅能够吸引消费者的注意力，成功的拉新、引流、转化，还能传递出品牌的核心价值，进而提升品牌的影响力。因此，越来越多的产品以及品牌重视营销活动。那么，营销活动应该如何设计呢？超级营销也好，一般的活动策划也好，都需要考虑到最基本的三个方面：用户、社会和企业。

• **用户：**活动需要有核心利益，更需要有意义。如果你有大把的补贴，那就把这些钱花的更加有调性一点。集五福的活动的核心利益是瓜分现金，活动的意义是公益和社会责任；

• 社会 ：好风凭借力，送我上青云。活动策划要了解我们今天所处的社会环境和文化，要学会借势，因利是导。春节是国人最为重视的节日，所以设计中一定要有传统的元素。

• 企业：企业需需要一场超级营销活动来完成自己的种种目标；但如果你把一场超级营销活动变成一个超级IP，那就更好了。就像维密的秀之余它的内衣，集五福之余支付宝。

2.营销活动典型业务场景
下面我们分别就这2个体系进行简要的介绍和拆解。

（1）奖品体系

a.优惠券
优惠券按照不同的分类维度和标准，主要有以下的分法：

• 按优惠方式可以分为 ：满减券(无门槛券可视为满0元减XX元)，满折券。

• 按优惠对象可以分为：单品券(只能买具体某个SKU)、品牌券(某个品牌如华为、小米下的所有商品)、品类券(如只能购买牛肉这个大类的商品)。

• 按发放主体可以分为：商家券(如京东品胜旗舰店自己发放的费用自行承担的优惠券，只能购买品胜这个商家的对应商品)、平台券(由京东平台发放的券，可以跨店使用的券)。

所属行业不同，优惠券的差异也很大。比如我们常见的电商类优惠券和金融借贷产品的金融优惠券差别就很大。相信有的读者会疑问，商品什么不直接降低价格，而是使用优惠券才可以享受优惠？ 这里面涉及到一个重要的经济学概念：差别定价（也可以叫做价格歧视），简单理解就是不同的顾客将会以不同的价格购买同样的商品，从而实现商家或平台利益最大化。
举个例子：一杯咖啡成本5元，假设定价10元时100人会接受此价格进行购买，定价15元时只有60人会购买。前者利润100*（10-5）=500元，后者60*（15-5）=600元。那么问题来了：商家应该定价10元还是15元或者介于10-15元之间12元、14元呢？
按照上述的差别定价理论，商家可以将其定价为15元，然后再面向那40位最高支付意愿为10元的顾客发放5元优惠券，剩下的60位消费者不发券，这样就变相实现了差别定价。此时商家的利润可以达到最大化60*（15-5）+40*（15-5-5）=800元。
至于怎么把5元的优惠券发放给40位顾客，以及怎么不被其它60位顾客发现自己被差别对待了，这又是一个很大的范畴，此处不足展开。
小结：优惠券从本质上来讲，是一种"价格歧视"策略，是商家针对不同消费者ABC的需求而进行的价格差异化，是商家追求利润最大化的合理定价行为。

b.积分类
为什么产品需要积分？积分有什么意义？有很多公司或产品，在没有想清楚上面这个问题的时候，就在产品体系（或用户体系）中加入了积分，并用"提升用户活跃和忠诚度，提升用户参与感和成就感"这个逻辑来解释上面的问题。但是，这个逻辑行的通么？

• 提升活跃度 ：我活跃于知乎是因为能增长奇奇怪怪的知识，是因为我有问题需要解惑，是因为我想在知乎上建立我的个人品牌和影响力，而不是因为有积分我才愿意来知乎。百度贴吧虽然给了我双倍的积分，但我会去上面解决我的上述问题么？

• 提升成就感：我是B站和网易云音乐的重度使用用户，我认可也赞同用户等级如LV6给我带来的身份认同感和成就感，但这个是用户成长值和活跃值等综合评估而来的，并不全是所谓的积分带来的。

有很多公司和产品在做积分和会员(等级)的时候，容易把两者混在一起。毕竟积分和会员经常成对出现，导致大家以为是同一个东西，其实不然。积分是依附在会员而存在的，会员除了积分之外，还有等级、权益、成长成就等细分的领域。 积分是产品内一种虚拟货币，可以通过各种方式获得，也可以通过各种途径消耗(如消费时抵扣现金，或兑换积分商品)，它会消耗，会涉及到成本，是公司的一种债务。
会员(等级)是用户在产品内身份和价值的直观评估，ABC三个客户我们怎么客观评价他们在产品内的忠诚度和客户价值呢？会员等级或许是个简单直观的方式，LV9大概率都会比LV1更值得我们投入更多的精力来做用户的分层运营。

c.现金红包 为什么有了优惠券和积分之后，还需要现金红包？
上文说过优惠券是因为价格歧视和利益最大化的原因而出现，积分主要是做用户忠诚度和参与度而存在的，现金红包产生的业务背景是怎样的呢？
就我所知，现金红包主要是因为公司或产品运营推广，特别是老带新拉新获客的场景而产生的。真金白银的现金红包奖励，对于老客户或推广者或邀请人的吸引力，要远远高于华而不实的优惠券或者积分(在大多数用户眼中，现金红包的价值要高于积分和优惠券的)。
当然积分某种程度上似乎也能部分满足上述要求，但红包的一些业务规则限制决定了如果用积分作为现金红包的替代品或等价物，则需要对积分做较大的改造。
比如现金红包需要实名，红包提现需要绑定银行卡，发放的时候存在先领后发(例如4月23日发放30元面额的现金红包，该红包5月1日生效)，红包需要做提现限制，红包需要先转到钱包再从钱包提现到银行卡等等。
上述的这些限制如果是基于已有的积分体系来实现，理论上也是可行的，但实际上开发和业务架构不建议这么做。因为有些产品的积分还承载着用户等级和权益的功能，基于此去做红包的适应性改造会将积分做的特别臃肿耦合度会特别高，不利于后期的扩展维护。
有些公司旗下有多款产品，产品间的积分可以按比例互相兑换（例如QQ音乐10积分兑换QQ会员20积分），简单来说就是积分和红包的功能属性和使用场景决定了还是各自独立最合适。
基于这些原因，所以现金红包应运而生。

d.实物产品
顾名思义，就是将真实存在的物品作为奖品。比如网易蜗牛读书购买年费会员赠送《明朝那些事儿》实体图书全套，比如网易邮箱积分抽奖活动的一等奖奖品是iPhone手机。
实物产品吸引力度与现金红包不相上下，但需要客户填写收货地址，平台或运营需要进行物流发货，几十份可能还好，但如果发放的数量较多的话则意味着有极大的工作量。

e.三方权益
无法归纳到上述4种类型的其他奖品体系我们姑且称之为三方权益（这是本文中的叫法）。

• 比如肯德基和麦当劳的大神卡和早餐卡，盒马的年费会员，淘宝的88VIP。

• 比如瑞幸咖啡的咖啡钱包，新希望鲜活GO的奶卡。

• 比如电信运营商的话费和流量包，游戏公司或平台的游戏币或QQ币之类的。

• 比如满足用户吃喝玩乐、吃穿用行方面需求的产品如饿了么、爱优腾、滴滴、唯品会的月度/季度/年度会员。

• 三方权益&积分&优惠券，例如爱奇艺100积分，拼多多满20减5元优惠券，购物分期免息券。

f.礼包类
将上述奖品1-5任意打包组合形成新的礼包，有的地方也叫套装商品。如充值1999元送礼包A，充值5999送礼包B。

（2）活动体系

a.领券活动 刚才对奖品体系--优惠券做了简单的介绍，假定此时我的优惠券奖品已经配置好了，那么怎么发放给用户呢？ 其实有多种途径和方法。自动送券新用户在产品内完成注册后系统自动发放优惠券，当然这个注册事件也可以根据平台或者产品希望用户完成的行为或者事件来做调整。比如实名或绑卡或授信或激活账号或者是浏览商品列表页XX秒或完成首单支付或首单确认收货，当然也可以每完成一个动作或触发一个事件，系统自动送券。
手动领券用户需要在应用首页或领券中心或商品列表或商品详情页或活动页自己手动领券，主要促进用户的登录和活跃，毕竟用户不登录产品或不进入对应页面是无法看到并领取优惠券的。

b.老用户带新用户活动 老带新活动也可以称之为MGM即Member Get Member活动，是一种典型的裂变拉新活动。拼多多的"天天领现金"活动，微信读书的"每日一答"、花小猪的"百万现金天天领"等都是比较典型的MGM活动。它可以帮助产品在有限的成本下快速获取到流量和用户增长。
老带新活动其实是由早期的推广员系统演变而来，推广员系统在2005年端游的鼎盛时期几乎是各大端游厂商的标配。其做法也相对简单，每位推广员（也就是邀请人）都有唯一的身份ID或者邀请码，新用户在游戏内注册时只要填写了该邀请码，系统就会将其和推广者建立绑定关系。
推广员每邀请1名新玩家注册，达到XX级，充值满XX元，即可获取对应的奖励。该奖励以推广佣金为主，推广员佣金达到一定门槛时即可进行提现。当然，新玩家填写了邀请码也会额外获得礼包的奖励，奖励内容主要是游戏内的货币和道具礼包等。
后来这种玩法从PC互联网时代延续到了移动互联网时代，并且有了更高大上的名字叫做分销裂变。
当然有的公司会叫做老带新，有的叫MGM系统，但本质原理都是一样的：就是老客户邀请新客户。根据新用户在产品内不同的节点给予奖励。当然，这个玩法也在不断的与时俱进，不断地进行着迭代和改良

c.抽奖类活动
顾名思义，用户完成某些事件或行为后可以获得抽奖的筹码，然后通过消耗筹码来获得抽奖资格。早期的抽奖页面基本都是大转盘，后面又衍生出了九宫格，老虎机、刮刮乐等各种花里胡哨的形式，但其本质都是抽奖。
常见的抽奖活动：大转盘、九宫格、摇一摇、水果机、刮刮乐、砸金蛋、翻牌子、红包雨、扭蛋机、点击抽奖等。

d.收集类活动 最最常见的收集类活动就是支付宝每年的集五福活动，与此同时也衍生出了一些新颖的玩法，如龙年集龙形碎片，然后拼成一幅中国龙的图片。完成收集的用户会瓜分奖品池，或者获得抽奖资格参与抽奖活动。

e.答题类活动 最早期的答题类活动是网络游戏中一种常见的玩法，比如每天定时开启一场答题活动，玩家进入活动内可以参与答题，答对XX道或者通关后可以获得奖励。
该活动主要是为了吸引玩家上线促进活跃的，其次很多玩家为了能获得高分便会在网络上悬赏或搜索XX游戏答题活动题库，进而增加游戏的搜索热度和曝光度，这点可能也是游戏活动设计者始料未及的。
后来该活动被移植到了很多产品内，比如微信读书，同时又将玩法升级可以进行用户间的答题PK，再配合答题排行榜，可以极大程度的勾起用户的好胜心满足其虚荣心，促进活跃。

• 有奖竞猜其实也可以算是答题活动的进阶玩法，用户可以"测"出其相关的结果。然后通过个性化的内容吸引用户转发到朋友圈，甚至刷屏，进而促进该产品的曝光和传播。

• 题库设计：需要提前准备好各类的题库导入到系统内，或者在管理后台允许录入各类问题。

• 活动奖励：在规定时间内连续答对XX道，即可获得固定奖励，或者是获得N次抽奖资格，然后参与另外一个抽奖活动。当然该活动的奖品、中奖概率是提前配置好的。

• 进阶玩法：答题过程中可以再设计几种道具，如换题卡、复活卡之类的，增加玩法的趣味性和参与度。

f.打卡签到
每天打卡签到可获得奖励，连续打卡签到会获得更多的奖励，奖励可以是勋章或积分或其余奖品。这种玩法比较适用于提升用户活跃，增加用户粘性。通常在健身、阅读、购物等应用中比较常见。 活动同样会关联到奖品体系内设置好的奖品。打卡签到活动是促进产品活跃的重要活动方式，只不过有些门槛低只需要点击打卡，有些则需要满足一定的条件，例如微信读书需要阅读图书内容10秒以上才算打卡成功；有些游戏类比如微乐斗地主则需要分享。 有些打卡签到活动允许用户在某天忘记打卡的时候补签，有些则不允许补签。两者各有利弊，产品经理在设计的时候可以通过A/B测试来评估下哪种效果好。

g.满减满折满赠 这三种活动是电商产品内最最常见的活动形式，没有之一。

• 满减活动

常见的是购买商品满XX件或满XX元，订单总价减掉XX元，或者是订单总价减到XX元。减掉比较常见，减到则比较少见（有些类似于淘宝的购物车改价，但系统自动减到省去了人工改价。也有点像组合产品降价销售，但省去了配置N多个组合商品的麻烦）。当然，满减会有重复满减和阶梯满减两种细分的模式。

• 满折活动

常见的是购买商品满XX件或满XX元，订单总价打XX折。为避免营销折让力度太高，再设置活动的时候一般也会设置折扣金额的上限。例如满10000打8折上限1200元，则顾客的实付金额应该为8800而不是8000元。用一句不恰当但容易理解的比喻就是又菜又爱玩，又想搞活动又舍不得让利给顾客。

• 满赠活动

常见的是购买商品满XX件或满XX元，赠送某商品XX件，或赠送商品A和B各XX件。后期衍生出了更灵活的玩法，赠送商品的赠品池有赠品M种，用户可任选N种（N<=M），这里的赠品M也可以是优惠券或三方权益。

举个例子：活动方在整理库房或库房盘点的时候发现了4种即将过期的呆滞商品，具体为400包火腿肠、800包方便面、600包螺蛳粉和1200个卤蛋，如果每样商品各取1个只能配置出400个赠品包，无法把这些呆滞商品最大限度的消耗完。
这个时候如果4个赠品任选3件，则可以配置出1000份赠品，活动受益人群扩大的同时，还能更大限度的处理呆滞品。
当然上面的例子还是有漏洞可以钻，因为4种赠品每种的实际售价无法保证完全一致，顾客在选择困难症的时候会选择价格最高的产品，例如全部选了火腿肠，这对于后续参加活动的顾客有失公平且吸引力也会不足。
这时可以再加一层限制条件即4种商品每种最多选X样。即4种赠品ABCD最多只能选3件控制总数量，赠品ABCD单独设置限定量如AC最多2件，BD最多1件。当然，对应的代价就是后台配置和开发实现会更加的复杂。
前面2种活动会涉及应付金额和实付金额的差异，优惠金额需要在参与优惠的商品上面按比例分摊。满赠活动则需要将赠品的价值分摊到对应的商品上。

h.限购活动
限购活动是指某个或某些SKU限制用户在某个时间段内的购买次数或数量。但有些读者可能会问，作为卖家或者平台而言，不应该是多多益善卖的越多越好么？为什么要做限购呢？
其实认真思考就不难发现，限购是有真实场景存在的。比如现在iPhone16在京东新品发布，如果不做限购可能会导致有限的商品被极少数买家或者黄牛抢完，真正有需要的用户可能无法买到新款产品，影响用户体验。
简单来说，平台或者卖家希望这款较为稀缺或者极具吸引力的产品能够由100个客户每人买1个，这样产品或平台的流量会更多，而不是被某位土豪或黄牛1人购买100个。
除了传统意义上用户购买次数和购买数量的限制外，限购活动还应该有风控的维度，风控基本会涉及到风控模型、大数据和算法。比如收货地址维度、手机设备IEME、收货手机号维度等。
拼多多百亿补贴里面的iPhone很多都是买到就赚到，所以很多用户都会去薅羊毛，但拼多多的风控机制会甄别出"投机"用户进而自动取消订单。

i.秒杀活动 可能有读者会问，限购和秒杀都是限定顾客在活动时间内的购买次数和购买数量，感觉两者是同一个活动，为什么有些平台会搞2种活动形式出来呢？
其实两者还是有些区别存在的，具体如下：
秒杀活动的时间相对于限购活动更短，活动力度可能更大。比如官网售价4998的iPhone15手机，限购活动是4688元活动时间1个月商品库存数5000名，秒杀活动时间可能是每周五12点开始限定300台价格4588元。秒杀活动更有稀缺性，对顾客的吸引力更大，可以给顾客一种紧迫感，可促使一部分有需求的顾客尽快下单。
秒杀活动会有活动开始前的预告，活动开始后的结束倒计时，以及活动商品库存余量的实时显示。相反限购活动不会有这些信息，它只会在商品详情页或购物车显示商品限购XX件。有些平台会允许秒杀商品和正价商品一起购买，但限购活动商品则不能和正价商品一次性加购物车进行结算（已参加限购活动后再次购买时只能买正价商品）。
限购活动一般是作为长期固化活动来做，而秒杀活动最大的特点就是活动时间短。

j.拼团活动 拼团活动简单来说就是购买人数满1、3、5人时分别可以享受到不同的价格。
拼多多是把拼团活动做到极致的典型案例。拼团活动非常适合社群、社区、社交型电商，而拼团本身除了能直接参团的活动外，还有新人团、助力砍价团等形式，非常适合做传播。 拼团类型的普通拼团是任意用户都能发起参与，老带新拼团则只有老客能发起新客能参与。为了鼓励或调动拼团积极性，可以将团长价格设置的比参团群众的价格低一部分。当然简单起见也可以设置为一致。=如果想侧重于拉新，可以尝试老带新拼团，让老用户分享扩散，拉新人成团。为了提高成团几率，可以在老带新拼团的模式上设置老客拼团价和新客拼团价，新老客的判断标准和逻辑可以根据平台和行业的性质类确定，有些是无任何购买记录的视为新客，有些则是N天内无购买的视为新客。
拼团人数与拼团成功率成反比，与扩散规模则是正相关。为了让用户有更强的动力主动传播拉更多的人参团，可以设置多个阶梯，参团人数越多价格越低。
为了提高成团几率，可以设置虚拟成团模拟买家凑满人数。

k.打包一口价 即XX元任选M件活动。网易考拉是把N元任选活动做到极致的案例。零食客单价低，SKU零散，如果不做满减，做N元任选也是比较好的促销方式，京东图书频道也经常搞类似的XX元N本活动。
打包一口价或XX元N件活动的优势很明显，简单归纳如下：

• 促进客户增购 ：打包购买更优惠，客户为了凑单，不由自主地买买买。给客户更多选择，客户自由选择活动商品，根据喜好搭配购买，满足个性化需求。

• 解决积压库存：清仓甩卖、新货带旧货，短时间内即可缓解库存压力。

• 营造促销气氛：新店开业、节庆活动，用"一口价"优惠吸引客户眼球，制造促销氛围。

l.预售活动
预售活动一般是顾客提前支付定金，达到活动节点后再支付尾款。最最常见的预售活动是天猫和京东双11的预售活动玩法，那么问题来了，为什么会有预售活动这种活动形式呢？

• 新品上市 ：比如说前段时间香菜火锅很火爆，白象方便面紧抓热点研发出了白象香菜方便面。但问题来了，这款产品顾客能不能接受，市场调研和用户调研的数据跟实际的用户反馈是不是一致的？是否能达到预期的销售效果？白象厂家可能自己也没谱。于是白象厂家借着618的契机推出了预售活动，看看网上投票支持的顾客会有多少人真金白银的买单。这样商家就可以提前了解到消费者需求，在线下及时调配货源或调整销售策略，甚至可以调整生产计划，避免出现产品库存积压以及备货不足市场缺货的情况。

• 促销活动：针对已有产品的常规市场活动，最典型的就是双11活动。白象厂家不确定到底有多少顾客会在双11期间下单囤货，生产计划评估很不好做。为了最大限度的降低库存呆滞提高周转率，白象推出了双11预售活动。通过预售可以发现哪类产品需求比较大，如果备货不足，可以让车间增加产量提高备货，保证促销活动取得更大的效果。

• 提高周转：白象厂家的最大理想可能就是方便面刚下生产线后就立马装车运输，减去产品在工厂内部转运储存和保管的成本，降低库存的周转天数（理想化状态是0天，即刚下产线马上装车），毕竟内部储存是有管理成本和资金占用成本的。

但预售活动是典型的双刃剑。

• 从消费者的角度来看 ，预售会消磨消费者的耐心，让客户放弃本产品去选择其他产品造成客户流失。另一方面，如果卖家的产品有其独特性和不可取代性，那么预售可以很好地起到培养客户忠诚度的作用。

• 从商家的角度来看，预售可以有效预测销量以销定产，不用担心积压库存，极大的提高库存周转率。虽然会一定程度上造成订单流失，但也节省了成本和库存的风险。

预售活动在规划设计时可能会存在以下的坑：

• 某款产能可能会存在正常销售和预售同时存在的情况，订单和ERP、WMS要做相应的区分和适应性改造。

• 如果平台存在白条或者额度之类的设计，则定金的还款日期和尾款的还款日期会存在较大的时间差，处理起来会稍微麻烦些。

• 预售产品可能存定金、尾款2次支付的情况，也存在一次性付全款的情况。

顾客支付定金的时候大概率会用优惠券，付尾款时应限制其再次用券（否则平台容易亏本）。

m.周期购活动
对于具备同城属性的低温鲜奶、饮用水、鲜花等行业或产品来说，顾客会经常性的下单购买该产品，但频繁的让用户下单体验较为不好，顾客如果忘记下单会面临无法使用的情况。"买家一次付款，商家多次发货"是这些产品极其重要的消费场景。
华西鲜活go订奶小程序就推出了周期购模式，有赞新零售也有类似的"随心订"功能。顾客一次性购买1-12个月的用量如30盒-360盒牛奶，配送员按照顾客指定的配送模式进行送奶到户，极大的优化了用户体验。
相比市面上其他"周期购"类工具，随心订在帮助商家更便捷管理周期性配送商品的同时，还优化了消费者下单时的体验，能够更有效的降低用户流失，提升用户LTV。
周期购模式适合所有周期类销售商品的行业：如鲜奶、鲜花绿植、生鲜水果、饮用水、粮油米面、滋补保健等。具备以下优点：
大幅提升用户的消费体验。周期购相对于传统的常购模式，满足客户一次订购多次配送的实际使用场景。客户在下单时可以自定义配送的周期、数量和时段，生成专属的配送计划。同时还可以根据顾客的日程变动（比如五一出游、暑假回老家）自己修改配送计划，对其进行停送。
周期购可以助力商家提升数字化经营效率。帮助商家快速锁定用户、降低促销成本、快速回笼资金、提高单客价值、提升用户粘性。在提升客户使用体验和粘性的同时，也减少了商家的售后咨询量。
在订单管理上，来自周期购的订单将订单和配送单进行了拆分，配送计划支持退改换停操作。退即针对未配送的牛奶进行退款，改即修改配送计划如从每日送改为隔日送（也可以改数量），换即修改配送的产品（方便推新品），停即暂停配送。 在用户管理上，商家可以通过周期购查看每个用户的订单到期时间，并且支持用户一键复购，帮助商家提前锁定高净值用户。

n.加价购
加价购是一种商业销售策略，也称为"附加购买"或"附加费用购买"。它是一种营销手段，通过向消费者提供额外的产品或服务，来增加他们原本打算购买的物品的总价。这种策略在零售业、服务业以及电子商务中广泛应用。
例如一部iPhone15的基本版售价为6199元，但消费者可以选择加价购一年的延长保修服务，额外费用为649元。此外，还可以选择购买附带的1年只换不修服务119元。这种加价购策略可以增加消费者对产品的价值认知，并为商家带来额外的利润。
消费者心理：加价购可能会让消费者感受到更多选择，但也可能引起购买决策的困惑或焦虑。
价格透明度：商家需要确保价格结构清晰明了，以免消费者感到被误导或欺诈。 品牌信任：加价购策略的成功与否往往取决于消费者对品牌的信任和忠诚度。

o.二次营销
二次营销，也被称为客户经营，是一种针对相同客户在不同时期、不同地点的不同需求进行管理的策略。这种营销方式的核心在于利用现有的客户资源，通过不同的策略和手段，促进客户的重复消费或交叉销售。
举个例子，方便快速理解这个概念。
平台搞完618大促活动之后，卖家可以抓住这个时机做一波二次营销。有些加购物车但没付款的客户，有些下单后并未支付的顾客，其实都是有很大的购买意愿，都可以对其进行转化，可以针对他们做一波返场促销。当然，已经购买过的顾客可以引导他们再次参加复购。

p.交叉销售 交叉销售（cross-sell）是企业向已经购买产品或服务的客户，销售其他类型产品或服务的过程，满足客户多样性需求。比如客户在买苹果的时候，销售向客户推荐香蕉。
可能有些读者会有疑问，这个交叉销售感觉和加价购很像，有必要搞2个活动形式么？其实不然。
加价购是在顾客决策和购买中推荐其它关联的商品或服务，交叉销售是向已成交客户推荐其它产品和服务。
交叉销售更多的是基于已有的订单数据和客户数据，甄选出转化可行性较高的产品和客户，进而配置对应的活动。举个例子，购买了iPhone15的顾客有200位，其中有部分是iPad产品的潜在客户，有部分是Macbook的潜在客户，如何把他们精准的识别出来，就是交叉销售的要义所在。

q.精准营销 精准营销是针对现有客户，以激发品牌忠诚度和购买行为。精准营销更少地依赖于创造有说服力的广告，而更多地依赖于创造交易、优惠和噱头来吸引现有客户。
精准营销的核心思想是精确、精密、可衡量，精准营销通过可量化的精确的市场定位技术、先进的数据库技术、网络通信技术及现代物流等手段保障企业和客户的长期个性化沟通，使营销达到可衡量、可调控等精准要求。
为了做到这一点，精准营销在很大程度上依赖于市场细分：一种将市场细分为更小、更具体、有独特需求的客户群的技术。

r.砍价助力 砍价助力活动的本质就是邀请好友参与活动，快速获取新客提升客户活跃。老客也可以参与助力，但砍价助力的效果显然不如新客。常见的就是拼多多的现金红包助力活动，提现200元可能只需要5名左右的新客，但老客则需要15名甚至更多（数据为大致预估，非真实测算数据）。
砍价活动：消费者主动将活动或商品链接发送给好友后邀请其帮助砍价，参与的人越多价格则会越低。该活动方式可以帮助商家快速传播商品信息让更多消费者参与进来，快速裂变线上顾客。简单来说价格是越砍越低。
助力活动：本质上与砍价活动类似，都是消费者主动将活动链接发送给好友后邀请其帮忙助力，参与的人越多则消费者距离目标的差距越小，例如拼多多的助力活动，初始红包金额为198元，红包满200元才能提现，邀请的人越多则提现的差额越小。
我们以砍价为例，来聊聊该活动的管理后台或者具体的实现方式是怎样的。已知某商品原价100元，可以砍到的最低价格为60元（需要财务核算不会亏本）。我在网上找了很久都没有找到拼多多相关的人出来现身说法，很多电商产品也都是根据前端呈现的效果来倒推的实现过程。
这些方式的共性有：

• 砍价人数 ：即最多有多少人可以参与砍价，消费者自己能不能砍。

• 商品底价：即该商品最低能砍到多少元，这个决定了商品会不会亏。

• 砍价有效期：即砍价发起到砍价结束的时间，这个时间区别于活动时间。例如活动时间是5/1-5/7，但砍价有效期可能只会有3小时，通过时间的紧迫性促使消费者更多的邀友分享。

每次砍价是固定金额还是随机金额，前者实现简单但会让顾客觉得活动真实性欠缺，后者一般会设置一个随机金额区间。假定可以10人参与砍价，可以砍掉的金额总计40元，平均每人可以随机砍掉4元。

（五）、用户会员体系

1.会员体系的重要性
电商系统，会员系统主要分为to C和to B，相对比于传统企业的CRM客户管理系统，功能相对是比较简单的。电商业务to C的会员管理主要包含会员基础信息管理、会员成长体系和积分体系这三部分。有to B业务的会员管理系统还涉及到B端用户的组织架构管理、客户拓展等功能。在B2B2C的电商平台的会员管理中，还需要对会员体系进行分层。每个店铺都可以对其会员进行独立管理。提供平台会员、店铺会员体系独立存在，独立运营。这样更有助于用户的精准化管理和营销。 2.会员体系典型业务场景 （1）会员基础信息管理

• 基本信息 ：包括注册时间、注册手机号、性别、会员等级、会员积分、会员余额以及收货地址等相关信息。

• 优惠券信息：用户账户中的优惠券明细及状态，优惠券金额、使用条件、领取时间、使用时间、有效期及使用状态等。优惠券可链接到优惠券明细。

• 订单信息：用户的订单记录列表，显示订单主要信息（下单时间、状态、金额、收货信息等）。可链接至订单管理中的订单详情，对订单进行相关操作（退货退款等。）

• 售后信息：用户的售后记录列表，显示售后主要信息 （下单时间、售后申请时间、状态、金额、收货信息等） ，可链接至订单售后管理。

• 会员等级：主要是会员成长明细，记录成长值增减的原因和时间，以及升级历史，可以修改用户等级。

• 会员积分：会员积分变动明细，记录积分的来源、消耗。

（2）会员成长体系

在会员等级管理中，用户的成长值决定了用户的会员等级，笔者所负责的会员体系是按照用户的积分数进行划分的。
以目前最大的两家电商平台为例，淘宝的成长值叫做"淘气值"，不同的淘气值对应不同的会员等级（普通会员、超级会员、APASS）；京东的成长值就叫做"成长值"，不同的成长值对应不同的会员等级（注册会员、铜牌会员、银牌会员、金牌会员、钻石会员 ）。
这两家电商的会员成长体系采用的是两种不同的模型：RFM模型（RFM是客户消费行为特征分析模型，RFM代表Recency（最近一次消费时间），Frequency（某一个时间范围内的消费频次），Monetary（某一个时间范围内的平均客单价或累计交易额）。RFM模型是衡量用户价值的重要工具和手段，对会员价值进行多维度动态指标综合加权计算。）和用户行为增长模型，也是目前应用最广泛的两类模型。会员成长值是根据不同的成长策略进行量化赋分。电商中主要对用户的登录、购物、评价、晒单等行为进行评估，来计算会员的成长值。

（3）用户会员增长模型
电商网站中，一般对用户的登录、购物、评价、晒单等行为进行成长值评估。以京东为例，其成长值增长策略为：

• 登录 ：除注册会员外，每日第一次手动登录后可获得成长值奖励；

• 购物 ：订单完成后获得成长值（购物成长值=结算金额×加速系数）；

• 评价 ：评价20元以上商品（虚拟商品除外），审核成功获得20个成长值；

• 晒单 ：前10名晒单20元以上商品（虚拟商品除外）的用户，审核成功后获得20个成长值 。

当然还有一些成长值回退策略，退货、评论被删等行为相应的成长值扣减回退。 通过用户行为增长模型来评价用户的成长值，在用户进入平台初期有很大的激励作用，但是后期乏力。当用户成长值较高、用户等级较高时，就很难再激励为了成长值用户持续购物。但RFM模型一个动态评估模型，当用户消费倾向下降时，成长值就会停滞不前甚至下降，能持续激励用户去消费。例如已经成为了超级会员，但是半年没消费开始掉级，变成了普通会员，这样的降级动作就可以重新唤醒用户。
在设计会员等级与成长值的对应管理时，首先就要想清楚会员等级和会员权益的对应关系。在数据的基础上划分会员等级，保证最高等级到最低等级的会员分布比例，而不能随性定级。

（4）积分体系
积分体系是很多线上线下商家都会采用的用户消费激励体系。积分可以正向累加，对用户的某些行为（如交易行为、互动行为等）产生与价值相匹配的积分；也可以被客户进行主动消耗抵用，目前主流的三种积分消费方式：订单结算抵扣、积分商城购买商品、用户权益置换等，这样积分的生成和消耗就形成完整的闭环。
获取积分也是通过签到、购物、评价、晒单、分享、充值等行为进行积分返还，例如购物送积分：每消费 xxx 元，送 xxx 积分，一次性消费 xxx 元，额外送 xx 积分。还可以界定商品、会员等级、营销活动等不同的条件界定返回积分的区别。京东的京豆、淘宝的淘金币（已取消）、信用卡积分等都属于积分的一种形态。 积分和用户成长值有所相同，也有所不同。成长值增加时，积分并不一定会增加。会员成长值和会员等级相挂钩，而积分和会员等级并没有直接关系，而且积分是可以使用消费的。

（5）会员体系分层
当电商平台上有店铺时，那会员体系就变得立体。如图3所示，用户（VIP1-7）等人属于平台的会员；都在店铺中发生过消费，又属于店铺的会员；甚至有会员属于不同店铺的会员，如VIP2既是店铺1的会员，同时也是店铺2的会员。

（六）、支付系统 1.支付系统的重要性 用户选择完成心仪的商品加入购物车，下单支付前选择对应的支付方式（银行卡、信用卡、微信、支付宝、各自商城的支付方式等等），最终用户输入密码进行订单支付。
支付系统是每个电商系统都必备的模块之一，也是众多模块中最核心的功能，如果支付出现问题，那么意味着会直接影响到产品收益，事故严重程度高。
支付中心系统对内为各个业务线提供统一的支付、退款等服务，对外对接三方支付或银行服务实现资金的流转

2.支付系统典型业务场景
a.订单正向支付
用户选择在支付页面选择对应的收货地址、收件人信息、选择对应的支付方式（微信、支付宝、银行卡等）进行输入密码支付，订单变更为已支付状态。
b.订单逆向退款
先查找用户的订单支付记录，进行支付系统退款，然后退相对应的积分、优惠券等等操作，变更订单操作状态。 c.订单超时关闭 如果用户长时间没有支付，一般都会有一个超时时间（如上图业务收银台的支付剩余时间），到达这个超时时间支付单会自动关闭。
d.支付结果通知上游容错
在回调通知上游业务系统支付结果时，可能会回调失败，比如网络异常或上游系统发生短时故障，如果发生这种情况我们单靠简单的重试是无法完全解决问题的。
为了尽可能的通知成功，我们需要针对没有通知成功的数据，每隔一段时间通知一次，那这个需求和我们上一个问题差不多，所以可以复用我们的延时重试队列。
e.支付网关

• 唯一的请求入口；

• 统一的身份认证、签名

• 加解密

• 流控/熔断

• 协议转换；如HTTP转换为RPC

• API 发布管理；

• API 调用计费；

• API 的监控、报警分析；

f.风控欺诈 事前

• 入网审核

• 风险评估

• 单笔限额设置

• 单日限额设置

• 频次设置

事中

• 实时分析

• 多维度判断

• 拒绝

• 拦截 -- 进一步验证-- 人工介入

• 延迟操作（例如用户大额提现，需要时间段进行复核）

事后

• 数据分析

• 巡查、警告

• 降低评级

• 升级防范措施

• 逻辑完善

• 反馈至事前、事中规则中

g.账务系统

• 账务生成

• 内部对账

• 原始账单下载

• 生成标准账单

• 对账

• 差错处理

账务生成后首先进行内部对账，一直后进行原始账单下载，再生成标准账单，进行对账之后进行差错处理。

（七）、订单履约系统（OC）

1.订单履约系统的重要性 很多公司，除了自营商城以外，还有其它渠道（如天猫、京东等），多个渠道的订单该如何集中履约？订单履约全流程是怎样的？"所谓订单履约，就是从订单交易产生以后，到用户最终收到商品，包括售后的整个过程。所以我们的订单履约系统的主要实现目标是能高效且透明的完成订单履约全过程，保证用户体验。"
从订单数据上下传通道来看，整个订单履约从上往下涉及3层系统：订单转换中心、订单履约中心、仓储路由中心。
订单履约系统的上游是订单转换中心，用以对接各个销售平台。因为各平台的订单结构不尽相同，为了能统一在履约系统中对订单进行管理，保证订单内部流转的标准化，不至于因为某个平台的调整而动了主体结构，所以在订单转换中心中针对各个平台配置不同的适配器，将订单标准化以后再与履约系统进行通讯。
需要适配的信息包括商品、地址、订单状态、物流公司等。
履约系统的下游是仓储路由中心，用以与各个仓库系统和门店新零售系统进行交互，将订单路由分发至目标库房进行生产，同时将目标库房的发货信息收集并回传至订单履约中心。
订单履约系统负责处理订单履约的全过程，对上通过订单转换中心与销售平台进行信息同步，对下通过仓储路由中心将订单信息上下传，内部通过调度中央库存、配送系统等多个外围系统对订单信息进行层层拆解和组装，将订单加工为满足履约条件的可执行指令。

（2）订单履约典型业务场景 从系统层面看，一张实物类的订单从销售平台下单，到最终用户签收，会经历10余个履约节点，涉及销售平台、订单转换中心、履约系统、中央库存、配送系统、仓储路由中心、仓库/新零售系统等多个系统。
所以，履约流程最核心的诉求是协同和顺畅，只有各系统相互协作，订单自始至终很流畅的执行完各个节点，才能保证在约定时效内完成履约。其中任何一个节点出现卡壳，都会导致履约时效拉长，影响的是客户对平台的信任。

a. 订单正向流程

• 新订单

订单系统接到新单的状态，此处根据业务分为两块逻辑处理：三方平台（如天猫、京东）的订单，客户在销售平台上完成了交易，由订单系统接到销售平台同步的订单后的状态。自营平台的订单，客户提交订单后，订单系统便生成一张新订单，不过此订单需判断若为在线支付订单，需付款以后才能继续往下流转。

• 订单拆分

为了更好的购物体验，大部分电商平台支持合并提交支付，在订单生成以后，需按照商家、仓库、商品、金额、物流等规则进行订单拆分，分为多个子订单发货。

• 订单预分仓

为防止超卖，已经下单的订单需尽快进行库存预占，以免库存被其它订单占用，分仓过程由中央库存提供服务。 订单预分仓可以提前锁定订单发货仓库，若订单核心信息发生变化，再重新分仓。若业务上允许一个订单被拆分为多个库房发货，订单需再次拆分。
需要注意的是：只有实物库存满足的订单才能预分仓成功，预售类的订单，可在订单拆分后进行截停等待，待真实库存采购入库以后再进行分仓流转。

• 订单拦截处理

某些不符合业务规则的订单，如疑似恶意订单，在订单系统中打上拦截标记，待人工审核通过后才能继续放行。若明确为恶意订单，则将订单取消。（订单拦截规则因为行业、公司、业务不同，要根据实际业务情况进行梳理，不在这里详述。另外，到底是先分仓预占，还是先拦截订单？木笔认为应该先进行分仓，虽然恶意订单可能会占用部分库存，但处理完以后，订单会被取消释放库存。此种处理方式好过一些疑似但不是恶意的订单因为被拦截了而没有分仓，导致后续库存被其它订单占用而引起超卖的情况。）

• 合并订单处理

为降低运费成本和库房作业成本，在一定时段内，满足合并条件的订单，在订单系统中合并为一单下发库房/门店发货。

• 订单审核

某些业务规则下，会要求订单在人工审核处理后方能继续流转，例如：被拦截的订单、客户有特殊需求的订单等。 为提升履约效率，其它订单可自动审核而无需人工一一处理。当然此审核功能可以直接放在履约系统中供客服使用，也可以提供服务供客服系统调用。

• 订单重新分仓

若在人工审核处理环节，客服修改了订单收货地址、商品及数量等分仓相关信息，从而影响了预分仓的结果，需要重新进行分仓预占，并清除原预分仓结果。

• 订单分物流

由于全国各仓的物流是单独签约，根据仓库所处的位置不同，签约的物流可能不尽相同。所以，在明确了发货库房以后，履约系统调用物流配送系统提供的物流服务进行物流商的匹配，以及调用物流公司接口获取电子面单相关信息。

• 下发库房

物流公司分配完成以后，订单履约需要的信息已组装完全，订单履约系统根据订单距离和物流信息试算履约时效（履约时效主要用于服务承诺，为库房波次提供参考），并将订单下传仓储路由中心，经此系统路由至目标库房或门店生产发货。

• 波次下发

仓库/门店系统接到订单后，根据配送方向、时效承诺、订单类型等因素将订单生成波次，并按照出库策略对波次进行定位，生成库房拣货任务。在此过程中，若仓库零散货位库存不足而整件货位库存充裕，会产生波次补货。

• 生成批拣单

系统或库房操作员将定位成功后可以一起拣货的订单（如相同物流公司、相同拣货区域等）打包生成一张批拣单，在非自动化作业模式下，一张批拣单中含多少订单合适？一般按照拣货员推着拣货容器一次性能放下的拣货箱上限即可。例如一个拣货小车上能放下12个拣货箱，则可以设定1张批拣单含12张订单。

• 订单打印

打单员按照批拣单将每张订单的面单、纸质发票、发货清单打印出来并按订单顺序整理存放。

• 拣货

拣货员按批拣单领取拣货任务（纸单或PDA），并按拣货路径完成拣货任务（若拣货区域过大，可将批拣单再拆分为多个拣货任务，按区域完成拣货）。若是边拣边分模式，拣货员一边拣货一边将批拣的商品分拣到每个拣货箱,拣货完成也分拣完成；若是先拣后分模式，待拣货员拣货完成后再集中进行集货分拣。

• 复核打包

复核员按照订单的下单明细对商品进行复核确认，无误后交由打包员打包并粘贴物流运单。

• 订单发货

发货员将包裹交由快递员揽收，并在系统中操作发货，代表订单从库房发出。发货以后，若实际发货物流有变化，回传实际的物流公司及物流单号至履约系统，履约系统再通过订单转换中心将物流信息回传销售平台。 若是新零售下的自提业务，则由门店店员打包以后，等待客户上门自提。

• 物流揽件

物流公司快递员收到包裹后，在系统中操作揽件，揽件操作信息可由配送系统调用物流公司提供的接口获取，解析完后回传订单系统。

• 物流运输

包裹从物流公司的分拣中心分拨发出。

• 物流派件

包裹到达配送站点，派件员按照路线进行派件上门。

• 物流签收

包裹送达客户手中，完成签收。 以上便是一个实物订单的履约全流向，虚拟订单因为不涉及到库房发货和物流配送等环节，需走另外的系统流程。"

b.订单取消场景 取消场景主要有3类：

• 顾客发起的取消 ：客户在用户端发起的取消；

• 客服代为取消 ：客服代替顾客取消订单，此操作一般在后台客服系统或者在订单履约系统中直接操作；

• 系统取消 ：若客户下单后超时未支付，或系统判定为恶意订单，会自动取消订单。

业务流程处理
根据订单在取消时可能存在于订单系统工作流、仓库作业、配送等多个环节，取消订单时需根据订单所处不同的状态执行不同的系统处理逻辑：

• 订单处于预分仓之前的状态 ：直接取消，更新订单状态为"已取消"，并判断是否需要退款触发退款流程。

• 订单已分仓，但尚未下发库房 ：取消订单，并通知中央库存清除订单预占。

• 订单已下发库房，但尚未发货 ：由履约系统对仓储系统发起询问，若仓储系统未发货且拦截订单成功，履约系统再取消订单，并通知中央库存清除订单预占。

• 订单已发货但尚未签收 ：若是自营配送，或者配送系统已与物流公司接口打通，则发货以后仍可以取消订单，履约系统询问配送系统，若配送系统拦截包裹成功，则履约系统更新订单状态为"已取消"，此阶段无需处理库存。

• 订单已签收 ：已经签收的订单，不支持取消，若想将货退回，只能走售后退货流程。

c.订单拆单场景 订单拆分是将一张订单拆分为多张子单独立发货的过程。订单履约过程中非常核心的一个环节，和订单取消一样，订单拆分会出现在订单履约的多个环节中，可以是系统自动拆单，也可以是人工拆单。
所以，订单拆分也应该设计为一个公共服务。
拆分以后，父单作废，子单继续完成履约过程。但在前台和履约系统中需要有很明晰的父单和子单的对应关系。
拆分过程中，对订单的处理逻辑如下：

• 基本信息（下单人、收货人、渠道等公共信息） ：将父单信息复制到子单 。

• 财务信息 ：订单应付总金额/已支付金额/发票金额/物流运费=按照各子订单的商品总价比例进行分摊，最后一个订单金额为剩余未分配金额。建议保留2位小数。

• 商品信息 ：按照需要拆分的sku或者数量进行拆分，保证所有子单的sku及数量之和与父单一致。

• 促销信息 ：针对整单的促销（例如整单优惠、满减、平台优惠券、积分抵扣等），拆分时按照订单中sku金额比例分摊；若是针对单sku的促销，拆分时仅考虑参与促销的单sku维度，其它sku 不参与促销分摊。"

d.订单合并场景
"将相同客户的多张订单合并一起发货，有诸多好处，于客户而言，多张订单一起送货，只需要签收一次包裹；于公司而言，可以节省库房的作业成本和配送的物流成本。所以订单履约系统中增加订单合并功能是很有必要的。
履约系统设计时可以设置订单集中等待10到15min，在此等待时间内进入履约系统的订单，若符合合并条件，可自动进行合并；超过等待时期进入系统的订单，可由客服手工合并。

e.订单反审核场景
在订单履约过程中，已经审核过的订单，常常会被要求修改信息（例如客户要求修改地址、库房要求拆包裹发货等），客服需要将订单拉回至审核之前的状态，然后修改之后重新审核下发，此动作即为反审核。
反审核的系统处理逻辑为：
将原订单做取消处理；根据要求修改后生成一张新订单重新下发完成履约流程。新订单是否需要生成新的单号？取决于下游的仓库/门店系统是否兼容多个相同的订单号。若兼容，则无需更改单号，若不支持，则生成一个新订单号。订单在未下发仓库系统之前，原则上无需重新生成单号，系统记录一条反审日志即可。

（八）、发票系统

1.发票系统的重要性
简而言之，发票就是发生的成本、费用或收入的原始凭证，正因为发票是唯一凭证，所以每张发票都会有一个特定的发票号码。
其实我们实际生活中涉及到发票的场景非常多：吃饭、住宿需要找店家开张发票，线上购物找商家开发票......
对于商家来说，发票主要是公司做账的依据，同时也是缴税的费用凭证。而对于消费者来说，发票主要是用来报销的。
生活中会出现一种场景，商家反馈本月度票用完了，承诺给消费者下个月开票。这是因为公司会定期从税务机关购买发票，如当月票已被用完的话，一般都会下月补开。
发票分为普通发票和增值税专用发票，增值税专用发票能用于抵扣，增值税普通发票只能做记账凭证。
目前专票只支持纸质发票，而普通发票电子、纸质票都支持。

2.发票系统典型业务场景

a.发票数据的基本操作

• 开具发票

需要输入哪些发票信息，提交信息后如何开票。对于抬头信息、电子邮箱或者邮寄地址是需要用户来录入的，像税率、纳税人识别号、开票人信息等都是公司自己配置好的，自动带入即可。 当信息填写完成后，大部分中小型公司都是会通过调用第三方系统进行开票。当开票成功后，就如上文所说，生成一个特定的发票号码。

• 查询发票

查询条件有哪些，支持哪些数据的展示。要明确的是，查询项的主要目的是用于定位数据。除了最基础的一些查询项，如发票申请时间、开票成功的时间，还要根据业务日常的操作诉求进行设计，比如是否需要根据提交人进行查询、是否需要通过交易订单号查询等。

• 查看发票

除了发票本身信息以外，还支持查看哪些信息。查看发票详情里的字段一般是包含了查询项以及提交项的内容，除此之外集合实际业务场景考虑是否增设其他信息，还如自动带入的配置信息、订单信息、商品信息等。

• 修改发票

发票中哪些信息支持修改，修改的功能主要会涉及到安全问题。所以这里要考虑功能的权限配置，同时还要给出修改规则，即哪些字段可以修改，哪些不能。

如用户自己提交的信息基本都是可以修改的，而像系统自动带出的字段都是不允许修改的。

b.发票数据状态的流转 "用户提交一条数据---发票系统生成一条数据---提交三方系统开票--返回开票结果"，这是一张发票在系统的正向流转过程。 简单来说就是未开始---进行中---已完成/失败，我们可以发现，这里其实有涉及到数据的状态变更，同时还用考虑在对应不同的状态下，会有不同相关联的操作。
比如说对于已成功开具的发票，我们可以对此进行红冲。
红冲后，我们就会得到一张"红票"，未红冲的开成功的票即"蓝票"（虽然"红票"是基于对"蓝票"进行红冲后生成的，但实际上这属于两张发票，有各自不同的发票号码。）
再比如，开票失败以后我们可以再次开票等等。

c. 与不同系统之间的关联 我们上文说过，发票是发生的成本、费用或收入的原始凭证，是有一个前置动作的。 所以对于发票系统来说，他不会是一个完全独立的系统，要从订单系统、退费系统、商品系统中获取信息，从而对发票信息进行判断。
如在开发票时，发票系统需要去订单系统抓取订单状态进行判断，当订单状态为"已付款"或"已收货"（具体状态因业务场景而定）时才能发起。
像京东这样的电商平台，会自动抓取订单"已签收"状态进行自动开电子票。同时发票系统也要去判断当前订单是否重复开票，同理，当订单状态为"已退费"时，发票系统也需要对之前开过的票进行红冲。 所以熟悉发票系统的前提下，也要求对其他系统有一定熟悉。

（九）、财务系统

1.财务系统的重要性记录账户流水和余额，最基本的作用。信用额度控制，同时提供一种支付方式，这是原本有的功能。按照会计规则建立一套分户账户，提供会计核算，业务对账的基础，这是方案的核心点。

2.财务系统典型业务场景 一套完备的账户包括：收入、成本、费用、库存、应收、应付、实收，实付几大类账户。 （1）账户系统如何记账 下面以交易过程中几个简单的例子描述账户系统如何记账。

• 销售订单交易

一笔销售交易订单的生命周期经理客户下单，支付，订单发货，确认完成4个关键步骤，交易系统会记录下这4个节点，账户系统完成支付相关的分户账户记账，财务系统根据业务系统交易单据完成财务记账，并同步会计分录流水进分户账户。

• 供应链交易

一笔采购订单交易的生命周期，具有入库，到票，支付3个关键步骤，财务系统对3个节点分别记账，并同步分录流水到账户系统。 整个记账&对账协作参与系统包括：

• 交易系统 ：记录业务单据

• 支付系统 ：控制资金的流出与流入

• 财务系统 ：负责财务记账

• 资金管理系统 ：负责账单数据的采集

• 账户系统 ：负责分户账户记账及对账

（2）账户系统对账对账的整体规划为：账户系统承担集团内各个系统间的对账，资金系统和支付系统会承担外部渠道对账；内部对账包括：业务账，财务账，资金账。账户系统接过对账后，由于账户天然存在期初，期末值，粗颗粒度只需要核对期初期末值是否一致；细颗粒度则只需要导出账户的账单明细与其他系统提供的明细进行核对即可

• 财务对账

账户系统分户账户按照会计规则建立，因此每一个会计科目对应一个汇总账户，每一个会计科目不同的核算维度不同则对应一个单独的账户。财务对账就是核对会计科目余额与分户账户余额的过程，极大的减轻了财务对账麻烦程度。

• 资金对账

流水和余额的记录是账户系统的基本功能，资金管理平台的资金流水变动都需要同步到账户系统，实时记录公司各个银行，其他货币资金账号的余额；财务凭证的挂银行科目的分录流水也会同步到账户系统，记录到对应的账户里，因此只需要比对内部的账户余额就可以完成简单的资金对账

• 业务对账

由于交易系统业务单据的流转都会引发账户系统账户的变动，当业务系统需要对账，只需要导出账户的账单明细与业务系统提供的业务单据明细即可核对

（3）报表
有了这套账户甚至可以协助完成部分报表服务，例如库存报表/仓库采购入库/销售退货入库/盘盈入库等本期增加数，以及销售出库/采购退货/盘亏等本期减少数都能通过账户拉取账户的期末值减去期初值得到。报表的生成只需要将各个账户的名称展示在表头，账单明细展示在行上面就能形成一张报表。

（十）、仓库系统

1.仓库系统重要性
什么是仓储物流呢？仓储物流，就是利用自建或租赁库房、场地，储存、保管、装卸搬运、配送货物。传统的仓储定义是从物资储备的角度给出的。现代"仓储"不是传统意义上的"仓库"、"仓库管理"，而是在经济全球化与供应链一体化背景下的仓储，是现代物流系统中的仓储。而电商仓储物流就是专门为电商设计，完全贴合电商的需求而开设的仓储物流。WMS系统主要是库内作业的管理，包括物料管理、货主管理、入库、出库、配发货、上架/调拨以及库内盘点。

2.仓储典型业务场景

• 仓库划分 ：仪器库、机械库、恒温恒湿库、危险品库、低耗品库

• 库位管理 ：整库位、零库位、移动库位、临时库位。

• 入库管理 ：采购入库、生产入库、退货入库，会生成相对应的入库单。

• 出库管理 ：销售出库、保损出库、返厂出库。

• 配货发货管理 ：检验分离、错检错验、拣货路径、PDA设备，会生成对应的发货单。

• 上架、调拨管理 ：质检。

• 库存盘点 ：实时盘点、日盘点、全库盘点。

（十一）、物流系统

1.物流系统的重要性电商目前提供的物流服务主要有三种：普通快递、同城配送、门店自提。三种方式都有着对应的应用场景，消费体验和成本有着较大区别。普通物流是目前电商中运用最广泛的方式，商家负责商品售卖，第三方物流公司负责运输。 本文仅讨论普通快递的运费设计情况。电商商城中，用户在前台看到的运费其实与实际的物流运费有着很大的区别。卖家会考虑以简单地方式来呈现给用户，所以一般都以包邮或者满*包邮的运费方案。实际的运费和收取的运费肯定是有差距的，所以前段收取运费时，也要核算成本。前端运费是通过运费模板来判断的。

2.运费的计算方式

（1）基于商品的单品级为店铺内的每个商品设置自己独有的运费收取方式，每个商品的运费独立计算算（一个订单下属于统一单品运费模板的商品，一起计算），当一个订单的商品属于多个单品运费时，可以选择按叠加/取最大值的方式计算订单最终的运费值。

（2）店铺级即整个店铺采用统一的运费标准，可设置收取固定费用，例如收取固定运费10元；或者满额包邮。例如：订单满69元包邮，不满69元收取10元运费。支持不同区域设置不同的的运费标准。

（3）混合型 在该种模式下，店铺运费模板与单品运费模板同时生效，店铺运费优先判断。当订单金额满足运费上设置的免邮金额，按照店铺运费模式计算，不满足时，按照单品运费计算。
需要特殊说明的是，如果单品运费模版上设置了单品运费优先店铺运费，单品运费模版绑定的商品的运费单独计算，即使订单金额满足店铺免邮，也会按照单品运费模版计算运费。该种方式集合了单品和店铺运费模式的优点，商家自主选择单品运费和店铺运费优先级。

（十二）、售后系统

1.售后系统的重要性在电商系统中，订单售后是整个平台系统最为重要的组成部分之一，好的售后产品能够极大提升用户对于整个电商产品的用户体验，提高口碑。产生售后的原因很多，处理平台本身的问题还有其他物流时效、配送员服务态度等因素，产品能做的就是设计一个高效的售后产品，可以快速响应用户的售后申请

2.售后系统典型业务场景 （1）申请换货

（2）申请退货

（3）取消订单

售后是针对订单中的商品发起的，最常见的实物快递类型订单有四个状态：待支付、待发货、待收货、交易成功。常见的售后类型有取消订单、退款、退货退款、换货四种，维修类型的售后用的较少。
在订单的不同节点，用户可以发起的售后类型也不一样，订单待支付状态下，用户可以取消订单；待发货状态下，用户可以发起退款；待收货与交易成功状态下，用户可以发起退款/退货/换货三种类型的售后。
需要注意的是，交易成功状态下售后申请有时效限制，一般是7天或15天，超过后就需要用户与商家自行商量了。用户申请的售后会产生售后单，售后单与订单相互独立，对应的有不同的售后状态，共用的初始状态有待审核，结束状态有售后成功或售后关闭，中间的状态有待客户发货、待退货入库、待换货出库、待退款等状态。
用户下单后可以对订单中的商品发起售后，支持对某一商品单独售后或对订单中的商品全部售后，根据不同的情况可以发起不同的售后类型。选择商品和售后类型后，用户需根据实际情况填写申请信息，包括申请原因、描述、凭证等信息，若发起退货类型售后则需填写退货地址，若发起换货类型售后也需填写换货的售后地址。发起售后，客服审核完成则最终流转至售后完成状态或售后关闭状态，至此，售后流程完结。
售后流程中有一个核心的环节---退款，在我之前写的订单相关的文章中就讲到过订单优惠的分摊，主要是涉及优惠活动、使用了优惠权益之后，就会涉及到商品实付款的计算。从下图我们可以看出订单经过一系列的优惠分摊后，应付款和实付款会有差异，差异的这部分就是优惠的金额。具体优惠分摊相关的内容可以查看我之前的内容。
不论是何种类型的售后，退款时会有一些共同的规则：

• 商品金额 ，商品退款时只退商品实付金额与支付时抵扣用的金币，使用的优惠券或促销活动产生的优惠概不退还，即只退商品的实付金额。

• 运费 ，一般情况下发货后运费默认不退。

• 客服权限 ，客服拥有很大的自主权，可以修改退款金额，补贴运费。也可以根据用户情况判断责任。或者根据实际情况对用户补偿优惠券。即系统规则计算售后金额后，若用户产生了疑异，客服会介入处理。

若发起的是退款类型的售后，则会生成一张对应的售后单和一张退款单，若发起的是退货类型的售后，除了退款单还会生成一张退货单用于商品的退换。

五、本节总结

到目前笔者已经把电商业务中核心的12个系统业务功能和大家讲解明白了，相信大家对电商流程有了一个比较详细的了解，后面咱们就在这个基础之上按照DDD规范进行拆解电商中的订单交易平台和营销活动平台。

你说，学习太辛苦了，怎么样可以医学习之苦啊？我听说过有这样药可医学习之苦，九叶重楼二两，冬至蚕蛹一钱，煎入隔年雪，可医世人学习之疾苦！可你疑惑啊，重楼七叶一枝花，冬至何来蛹，怎能采取隔年雪？学习怎可解？

后来方知，夏枯即为九重楼，挖地三尺寒蝉现，除夕子时雪，落地已隔年，到了用知识的时候，学习亦可解！同学们若非求知若渴入骨，又何以药来解，此药不比学习苦，怎能解得躺平毒呢？世人总是一叶障目，躺平失去是互相的，可学习是用来提高自己的。

直到千帆过尽，才恍然大悟，夏枯难得九重叶，三尺蝉蛹非寒蝉，唯有落雪似可觅。同学们，其实，这就是咱们奋斗的动力，只要动力足，万事皆可解。

欢迎大家和我一起走进DDD的世界，让DDD为复杂业务插上一双梦想的翅膀，让DDD不再那么神秘！