无论是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用户系统的功能基本设计完整，其重难点在于组织结构、权限控制，需要重点关注。
以上，仅供参考。
