无论是2B产品,还是2C产品,用户系统都是基础。对于非互联网产品从业者,2C用户系统的场景和功能通过日常各类APP的使用,大家都非常熟悉。因此,笔者通过和2C产品的对比,谈谈2B SaaS产品的用户系统设计。 一、商业的本质差异,决定了产品的核心目标 2C产品面向的用户是个人,用户系统的核心是获客,因此大多2C产品的用户系统设计重点在于方便用户注册、登录,能够建立精准的用户画像,从而达到流量变现的目标。 2B产品面向的用户是企业,用户系统的核心是组织、员工精细化管理,提升人效,从而实现节约成本的目标。 二、业务场景的需求差异,决定了产品的细节功能 1.注册场景 2C产品的注册主要用于个人用户注册场景,重点在于提供多种渠道的注册方式,如账号、手机、第三方社交应用(微信、微博等),其核心目标是既能方便用户注册,又能多渠道多平台账号打通。 2B产品的注册分为两部分:企业管理员代表企业注册和企业员工注册。 2B平台型SaaS产品,和2C最大的区别在于产品需要用户付费。因此,平台方为企业(平台租户)提供了注册入口,一方面需要方便租户能够通过其他渠道快速注册试用产品,一方面需要验证企业相关信息,识别该用户确实为潜在用户。 1)企业注册: 当企业管理员代表企业注册时,需要提供的注册信息:管理员昵称、手机号、邮箱、企业工商信息(名称、组织机构代码、地址、法人信息等)。 其中工商信息的完整度,不同的产品要求不一样,需要根据具体产品而定。如果方便注册拉新,尽量减少工商信息填写要求,如果产品安全性要求较高,可以尽量要求工商信息填写完整。 2)企业工商信息认证: 这部分并非强需求场景,取决于产品的安全性要求。一般安全性要求较高的平台产品,会在企业注册后,进入到企业工商信息认证环节。此环节要么是平台管理员人工审核,要么通过第三方认证验证企业工商信息是否合规。企业完成认证后,即可试用产品。 如非安全性要求较高的产品,可以直接跳过该环节,租户通过注册页信息填写完整后既注册成功。 3)企业员工注册: 注册信息:昵称、手机号、邮箱、其他个人信息; 被动邀请:一般B端产品多作为企业员工日常作业工具,因此多采用管理员开通账号制,管理员通过后台将员工信息注册至系统,员工即可登录。被动邀请制员工和公司属于强绑定关系,员工账号不可以独立存在; 主动注册:员工主动注册场景中,员工主动注册产品账号,然后再申请加入企业,由企业管理员审核通过后,和企业进行关联。该方式个人用户既可以独立作为平台产品用户,又能够以某公司员工的身份作为平台用户。钉钉即为典型代表,该类产品,一个员工可同时加入多个企业; 个人资料:员工注册后,该员工信息注册至系统,并能够在系统中展示、查询、完善个人信息资料。 2. 登录场景 登录场景比较容易理解,目前B端产品相较C端产品仍然比较传统,多采用邮箱/手机进行登录。 未来也希望可以实现,B端产品能够和更多C端产品平台打通,可通过通用的第三方账号进行登录,实现业务与社交的连接。 3. 用户画像 用户画像是2C产品至关重要的内容,只有精准的用户画像,才能更精准的服务好用户。无论是电商,还是资讯平台,基于用户画像的精准营销投放才是产品的核心。 2B的产品很少有讲用户画像相关的内容,事实上对于2B产品而言,用户画像也至关重要。 笔者目前从事CRM产品相关工作,CRM核心要解决的问题就是帮助你的客户获客,那么如何去建立客户的企业标签,去按照企业标签属性,借助大数据分析,帮你的客户找到他的客户群,是笔者近期在研究的课题。 建立企业属性维度标签:如行业、规模、业务范围、客群范围。 竞争企业标签关联性模型分析:便于了解市场环境、分析竞争企业,及时调整公司战略。 潜在客群(企业)标签关联性模型分析:利用数据分析模型,帮助企业识别潜在客户,提高企业获客率。 4. 组织结构 2C的产品从本质上来讲不存在组织结构,个人用户即为产品主体,但会存在群组/社群的概念。 2B产品的应用主体是企业,而组织结构是企业运营管理的必要手段和方式。因此组织结构管理是用户系统的重要组成部分。 1)建立组织结构 组织的单元是部门,因此管理员需要能够按照企业组织结构建立、调整(编辑、合并)、删除部门。 2)部门树结构 部门作为组织结构的单元,只是组织结构的分子,而要形成组织,就要按照企业的业务形态要求形成一定的层级体系。因此部门不仅仅只是简单的信息描述,还需要有层级描述,这就需要我们在建立部门时按照层级结构建立部门,定义清楚所建立的部门是上级部门、下级部门。 3)通讯录展示 管理员通过后台创建完组织结构后,企业员工可通过前台查询按照部门结构展示的通讯录。 5. 角色管理(该部分是2B用户系统设计的重点和难点) 角色管理是B端产品的特有功能,企业员工按其所负责的业务模块划分不同的岗位职责。 由于企业数据具有较高的安全性和私密性要求,按照岗位职责的不同,不同岗位的员工对于业务数据的操作/查看权限不同。 因此,我们设计了角色管理,该角色并非严格意义上的岗位职能角色,而为了区分不同的员工不同的系统权限所设计的系统角色,这就是RBAC设计。 1)建立角色 建立角色的主要目标即为建立一个用户权限组,该权限组内的用户具有相同的权限。 2)分配角色权限 基于角色分配系统权限,以实现不同的角色下的用户拥有不同的权限。 功能权限:用于设定该角色能够使用哪些产品功能,如果不属于该角色业务范畴内的功能可以直接对该用户屏蔽,避免过多的功能菜单干扰用户对产品的使用。 功能操作权限:企业管理越精细,员工负责的工作越具体,一个功能内,不同的人按照其职责进行不同的操作划分,为了保证数据的正确性和安全性,需要给不同的角色分配同一功能下不同的操作权限。 功能内的描述字段权限:一个业务功能中有不同的属性描述字段,但不同的角色关心的属性不一样,为了能够进行区分,需要给不同的角色去设定不同字段的读/写权限。 数据权限:企业数据本质上是企业资源,既具有私密性又具有共享性。一个角色具有该功能的一定操作权限,但是他能操作该功能下哪些数据?只能操作他本人创建的数据,还是能操作其他员工创建的数据需要通过数据?这就需要用数据权限来控制。这就要求当数据被创建,该条数据也需要相应的字段来描述该条数据的所属关系,该数据属于哪个用户,属于哪个部门,最终才可实现人和数据的关联,以实现基于员工角色的权限管理。 6. 员工管理 员工管理是B端产品的特有功能,员工是企业组织的重要组成部分,员工也是产品真正的终端用户。 B端产品从本质上是要能够帮助企业员工提升工作效率,提高企业人效,以实现企业管理者降低运营成本的目标。 1)新建员工 前面提到的用户注册即为新建员工的过程。包括被动邀请和主动注册两种形态,主要目标是将员工信息注册至系统,并建立员工和企业的关联关系。 2)建立员工汇报关系结构 为了实现精细化管理,企业内部一般按照组织结构设定员工的汇报关系,因此从CEO到基层员工会形成组织关系树,该结构可以和组织结构完全一一对应,即该部门下的所有员工均汇报给部门负责人,但也有部门内部分不同的小组,不同的人汇报给不同的小组负责人。 因此汇报关系和组织结构关系有一定关联,但并不是完全一一对应,所以我们需要设计员工汇报关系功能。 3)员工离职设定 为了保证企业数据的安全,员工离职后,需冻结员工账号,离职员工将不能以该企业员工的身份登录系统,以确保企业数据的安全性。 设定离职:将员工账号设定为离职状态,员工账号被冻结; 数据转移:员工离职后,其业务需要其他员工来接替,因此该员工在职时负责的业务数据需要被转移给新的用户,此部分功能需要在数据转移功能中进行规划。 至此,2B用户系统的功能基本设计完整,其重难点在于组织结构、权限控制,需要重点关注。 以上,仅供参考。