社区电商平台的权限系统设计
最近在构思对自家的社区电商平台进行重构,其中的大头就是权限系统,原有的权限体系已经不能满足需求了,所以根据客户状况及参考了其他一些大神的方案,对整个社区电商平台的权限系统进行了设计。
1. 用户群划分和业务介绍
用户划分
我们是做社区电商的,普通C端用户就是最终端的消费者。分销客是由C端用户“申请”成为,定位是社区或街道的“团长”,当所有用户(包括平台用户与分销客)通过分销客的链接完成交易时,分销客就能获得对应的提成。
商家是商品的提供商,负责上传SKU、处理订单发货、售后等。我们平台主要面向社区,上面的商品不完全是实体的商品,也有很多家政、洗车等服务。
代理商是一个特殊的角色,例如大区代理、省份代理、城市代理。他们帮平台完成很多地区的落地、招商、运营工作,某种程度上他们也是平台的用户,不过只能看到其对应有权限的区域的商家商品、订单信息。
商品客与商家、平台、代理商的关系
当一个用户希望成为分销客时,我们平台是需要用户申请的,如果当地有代理商,则申请会流转给代理商,由代理商根据用户周边情况决定。如果当地没有代理商,则由平台进行审核。而一个商品是否支持分销,由商家和平台/代理商共同决定。分销的模式为分销客可以开设自己的店铺,然后将不同商家的商品添加到自己店铺中,再分享给他人促成购买。
当然,我们也在尝试一些全民分销的活动,尤其是在没有代理商代理的地区,让普通用户都可以尝试将自己看好的商品分享给其他人,一旦促成购买,也有一定的奖励金。
2. 客户端划分
- C端:用户和分销商操作,主要载体是微信小程序、公众号H5、我们的APP,支持注册登录下单支付等功能。
- B端:由商家及其员工操作,一个商家完成注册后,可以设置多个员工账号,拥有不同的权限,进行上传SKU、订单发货、售后服务、财务结算、优惠促销等操作。主要载体和电脑端网页和手机H5网页,其中手机H5网页的功能是简化后的,有些功能只能在电脑端操作。
- 平台端:以电脑端网页为主,并尝试兼容在手机上查看数据。用户为平台运营和代理商们。
代理层级我们就设置了两级,之前其实我们就有一级代理商角色,现在是再增加了一级代理商。可能有的朋友会问,那为什么不一步到位:洲际、国家、区域、省份、城市、区/县、镇/街道这样分呢。主要原因就是我们体量有限、代理商并不多,过于复杂且灵活的体系,担心一来会加重研发周期,二来会干扰运营的操作体验,所以最后就选择了省-市两级的代理。
3. 权限划分
权限划分是整个权限体系设计的最大困难点,我们把权限分为了3种:
权限类型
(1)功能权限
可以访问哪些板块、操作哪些按钮。
功能权限划分
(2)数据权限
数据权限继承
数据权限即该用户可以访问哪些数据,例如一个用户可以访问商家管理板块,同时他可以访问广东地区商家的数据,那么综合在一起,他就能在商家管理板块看到广东地区商家的数据了。
重要的数据包括:
- 商家资料;
- 商家订单;
- 分销订单,比商家订单多出了分销者信息;
- 商品信息;
- 用户资料;
- 分销者资料,在用户资料基础上增加了一些实名信息、业绩、余额等内容;
- 商家员工资料;
- 代理商资料。
其他常见的数据,但是我没有体现在流程图中的:
- 商家优惠券;
- 平台/代理商优惠券;
- 活动及报名信息;
- 广告信息;
- 用户行为数据(登录、驻留时间、访问页面等)。
我们的代理商、分销客都可以拉新,所以当游客通过不同的链接注册后,我们会给予分销客一定的奖励,对于代理商则有一定的手续费返现。分销客和代理商能查看到其拉新用户的“资料摘要”,即简化后的资料信息,我们并不会将一些敏感信息任由他们查看。
查看用户资料的数据权限
平台和代理商都可以招收分销客、商家,分销客和商家的数据权限秉承三个原则:
- 谁招收谁有权查看;
- 上级有权查看;
- 下级不自动继承权限,除非上级下放数据权限。
商家、分销客的数据权限
(3)角色权限
用户的权限由其所属的角色决定,一个用户可以关联多个角色。
平台的代理商及角色关系
如果一共用户的角色是省级代理商,则可以访问该代理商及其下属市集代理商的所有数据。但是市级代理商只能访问自己的数据,无法访问到其关联的省级代理商的数据。代理商如果是平级或不平级、但是无关联,数据也不互通。
在实际应用中可能会出现以下特殊场景:
原本一个市级代理商,现在要承包整个省的代理,如何处理?
如果这个市级代理是单独存在的,我们提供了升级功能,这样他下面就能挂载其他市级代理商了。如果这个市级代理原本属于某个省级代理,那我们应该先解绑,然后再升级。
如果一个大区被承包了如何处理?
我们现在并没有这种场景,虽然不排除以后会有。我们现在遇到的场景是我们将不同的片区的代理商,分给不同的运营和商务处理,这样我们就为他们的账号绑定了多个角色权限,这样他们就能查看这个大区所有代理商的数据了。如果以后有华南区、华中区代理商的需求,我们再增加对应层级。
代理商如果自己有更细的层级划分如何处理?
我们提供接口权限级别的ERP对接业务,代理商可以将自己的ERP与我们系统对接,打通订单、商品、优惠券、商家及用户资料等数据,由代理商的ERP系统对下级权限进行细分。
4. 平台用户字段
平台的用户字段
这里以最复杂的平台端的用户来讲解一下用户、功能、数据、角色的关系,关于商家的员工字段将不再赘述。首先,超级管理员是系统自带的,不能创建和修改权限,第一批用户都由超级管理员创建,我们称为“普通管理员账号”,生产工作中都是使用此类账号。
(1)用户基本资料
登录的账号密码、姓名、身份证号、联系方式等信息。
账号密码、姓名、手机必填,姓名和手机可以帮助对应账号自行修改、找回密码。
(2)功能权限
我们预设了一些功能角色,这样不需要每创建一个用户都要勾选一遍功能列表,这是一个很繁琐的事情,同时我们也提供了功能角色的编辑板块,让平台管理员可以根据实际情况新增一些预设角色。
对于代理商来说,预设的角色若是不满足他们的需求,可以自定义他们的员工及合伙人可以使用的功能。代理商看到的功能列表里,只有当前用户所有的功能,只能从中进行筛选,无法查看、无法勾选其没有的权限的功能。
(3)数据权限与角色
我们并没有单独出一个版块来设置订单数据、商品数据之类的访问权限,而是直接选择该用户的角色,是平台还是某个或某几个代理商。因为只要限定了可访问的板块、用户所属角色,例如可以访问商品管理板块且你是一个地区代理,则你可以查看本地区所有的订单数据。
没有必要做成你可以访问订单管理板块、你需要拥有订单数据权限、你是地区代理身份,这样设置三次的方法来确定权限。
数据权限说明
一个用户若有创建用户的功能权限,则可以创建角色小于等于自己所属角色的用户。例如平台角色用户可以创建更多的平台角色用户,也可以创建省级、市级代理用户。一个省级代理可以为自己及其市级代理创建用户,但是无法为其他省级代理、市级代理、平台角色创建用户。
5. 总结
作为一个社区电商平台,这可能不是最完美的权限系统设计方式,但可能是比较适合我们当前需求的方案。如何设计一套权限系统应该由产品的业务特征决定,如果一个产品是完全自营的,就不会有代理商的概念;如果是传统的线下零售转线上,可能就要预设很多级的角色以满足原有的组织架构。
另外,一个权限系统也不是越复杂、颗粒度越高越好,有些权限系统将功能权限颗粒度细化到了每个接口,这样“看似完美”的设计,最大的优势其实是最容易实现。对于那些需要运营进行权限配置、甚至对外开放的系统而言,在实际操作过程中,由于业务是由接口组合实现的,就有了运营看不懂该怎么配置,或某几个业务是共用同一个接口。于是运营进行一些业务操作时没问题,但是进行另外一些业务操作时报错。
还有前文提到过的,一开始为何就不设计成多级甚至支持无限级的权限系统呢,毕竟研发也要成本,且用不上的层级可能也会带来操作者的疑惑、增加学习和操作成本。
只有根据自己产品的使用场景需要、考虑使用者的用户体验,才能设计出好的权限系统。
本文由 @iCheer 原创发布于人人都是产品经理,未经作者许可,禁止转载。
题图来自Unsplash,基于CC0协议。
你在你岳父岳母眼里你就是个废物,吃软饭的,不要脸,土狗想屁吃
作者有V交流?