本文针对B2B2C商城系统整体功能与流程设计展开分享，希望大家可以从中有所收获。
设计一个B2B2C电商系统，店铺对客户，店铺=自营+入驻，客户=C端客户+企业客户，类似京东的模式，平台上有多个店铺，用户可以选择不同的商铺。那么具体应该如何设计呢？
业务模式说明
toc商城：包含平台自营和商家入驻，面向个人消费者，类似京东商城；
tob商城：包含平台自营和品牌方入驻，面向企业用户；
定制平台&独立商城：可以为品牌商提供直营商城，功能服务可定制，类似有赞；
商城整体可分为基础服务层、业务层、UI层三大块
基础服务层：商城基础数据服务采用微服务架构，易于开发和维护，可根据需求，实现细粒度的扩展。输出标准API接口，可快速对接市面上大部分ERP、WMS等系统；
业务层：功能模块包含商品、订单、会员、营销、企业、通用、数据、系统等，按角色可分为平台端，商家端；
UI层：按渠道分为PC商城、微商城、APP、公众号、小程序，按用户类型可分为toc、tob；
商品管理系统属于电商产品中最基础、最核心的系统，是支撑整个电商产品的核心，基本上所有的系统都离不开商品数据，商品贯穿整个电商平台。从商品的采购、到达仓库、商品上架、前台的展示、下单、物流配送、收货、售后服务等，整个流程都离不开商品。
后台商品系统一般分为，类目管理、属性库、品牌管理、商品管理（发布商品、编辑商品、商品上下架、审核、价格库存设置、运费模板设置等）
SPU与SKU的关系一般是一对多或者一对一的关系，SPU包含多个SKU，SKU是SPU的子集，而商品是SKU的具象化实物。
商品管理其实说白了就是对商品的维护管理工作，包括发布商品、商品的上下架、商品修改、商品的查询、审核等。
商品状态分为待编辑商品、审核中、待售商品、在售商品、已删除共5个状态，笔者为大家梳理了一张商品在整个流程中的状态流转图。
平台运营或者商家在发布商品时，若无对应的商品需要走审核流，若有对应的商品无需审核，发布商品成功后，方可直接操作商品的上下架。
订单管理是后台系统中较为重要的一部分，它记录了所有的交易数据，可以对订单进行监控和操作，与用户、运营、财务等都有着密切的关系。订单模块是电商系统的枢纽，在订单这个环节上需求获取多个模块的数据和信息，同时对这些信息进行加工处理后流向下个环节，这一系列就构成了订单的信息流通。
对于现在主流电商来说，通常支持的售后形式包括仅退款，退货退款，换货。用户根据实际场景和诉求选择期望的售后方式。因此本篇以换货流程为例和大家分享下逆向消费场景的设计。
在B2B2C的电商平台的会员管理中，还需要对会员体系进行分层，每个店铺都可以对其会员进行独立管理；提供平台会员、店铺会员体系独立存在，独立运营，并且可交叉匹配，统一管理平台用户信息。
对用户来说：用户通过商家的促销活动，使得用户可以购买到物美价廉的商品；
对平台和商家来说来说：通过促销活动可以达到给店铺快速拉新，给平台带来巨大的流量；通过活动清理了库存，降低了活动占用成本；结合广告做品牌促销，扩大了品牌知名度；用户在促销活动下会不自觉的凑单从而拉高了平台的客单价，拉高GMV的目的等等；
促销形式玩法多样，需要根据实际业务目标和产品所处阶段制定对应的促销形式，每个促销形式的逻辑复杂，需要单独界定其商品规则及边界，这里不单独展开，以下为常见的促销形式：
● 满减促销：消费者只要购买相应商品的规定价格就可以就可以得到一定的减价优惠，主要驱动用户凑单购买更多的商品，分为阶梯满减和每满减两种形式；
● 单品促销：在规定时间内购买指定商品享受一定的价格优惠，可显示折扣或直接显示促销价格；
● 套装促销：组合商品套装出售以组合价出售，分为固定套餐（套餐内所有商品打包销售，消费者需成套购买整个套餐），搭配套餐（套餐内主商品必选，搭配商品任意选，选择后以优惠价格购买）；
● 赠品促销：购买主商品之后，赠送商品，既要选择主商品，也要设置赠品，与套装促销的区别在于，套促销价值高，赠品促销价值相对较低；
● 多买优惠促销：主要参考线下卖场的促销形式，用户在固定商品池中选择购买，分为满m元选n件，n件m折；
● 优惠券促销：通过发券向引导用户购买相应的商品，在下单的时候抵扣一定数量的金额，达到促销，提高客单价目的，分为满减券，折扣券，现金券三种优惠券形式；
● 拼团促销：通过开团，参团，分享模式在社交圈快速传播，利用熟人关系链接订单转化率高，可以快速拉新，快递成团；
组织架构：简单来说，是企业的的架构树状图。
不同的企业复杂度不同，继而组织架构多种多样。例如：复杂的公司组织架构，集团总部／区域划分／区域下的地方性公司／公司下的业务部门／部门里的小组；简单的公司组织架构，公司／部门。
组织架构在B端产品里，最常用的是与数据查看范围关联，账号根据组织架构查看数据统计。例如：上图中的公司1可查看其下所有部门的数据，区域1可查看公司1和公司2的所有数据。
组织架构有时与账号权限相关，即根据组织架分配操作权限。
例如：负责区域1对应的账号A1，负责区域2的对应账号A2，负责公司的1的账号为B1。则A1和A2为同组织级别的可具有相同的操作权限，但A1和A2的数据互不可看。B2为下一层级别，具有的不同于A1和A2的操作权限，可被A1查看，不可被A2查看。
采用业界接受度较高的功能权限模型RBAC（Role-Based Access Control）模型，其基本理念是将“角色”这个概念赋予用户，在系统中用户与权限之间通过角色进行关联，以这样的方法来实现灵活配置。
如下图即是RBAC模型中最基本的模型：用户与角色可为多对一或多对多的关系，当一个用户的角色为多对多时，当前用户的权限是多个角色的并集。
系统的使用者通常称为用户，用户登录后，系统通过各种标识赋予用户操作和查看权限。
后台需要对用户账户、操作权限和数据权限等进行管理。用户管理贯穿业务各个环节，是支撑业务运营的核心部分。
文章来源：信息流广告指南，作者：雪逸；
编辑：云朵匠 | 数商云(微信ID：shushangyun_com)
【数商云www.shushangyun.com】致力于提供企业级的电商平台服务，长期为大中型企业打造数据化、商业化、智能化的电商网站建设解决方案，同时我们还提供B2B交易系统、B2B2C多用户商城系统、B2C电子商务系统、跨境进口电商平台、供应商系统、SRM供应商管理系统、SCM系统、渠道管理系统等一系列系统定制开发服务，通过大数据、云计算等新技术协助企业打造供应端—渠道端—营销端—数据端等全链数字化运营体系，提升企业运营效益与智慧数字化商业转型。
点赞 | 0
