前账号体系对于SaaS产品来说十分重要，一方面很多SaaS产品的收费模式和账号数量有关，比如OA系统、CRM系统、协作平台大多数是按账号数量收费。另一方面账号又对应到租户用户的登录方式，设计不清晰的话可能导致用户体验不太好。本篇我们来介绍常用的几种账号体系，各个体系各有优缺点，大家可以根据自己的产品特点来决定选用哪种体系。

平台账号模式

平台账号模式是指租户的用户实际上是在平台注册，然后再与某些租户绑定。这种通常出现在产品同时对企业用户和个人用户开放的情况，比如钉钉、飞书。个人用户可以直接通过平台侧注册，注册后成为个人用户，可以使用一些面向个人的功能。如果要使用团队、企业相关的功能，要么是被邀请加入团队或公司，要么需要用户自己创建团队或进行企业认证。整个账号的变化流程如下图所示。

这里的团队其实是有两种模式，一种是弱化的团队概念，即不需要主动创建团队，默认就是个人团队，可以直接邀请其他用户加入到个人团队，比如协作类的Teambition，可以在项目里直接邀请成员；另一种是强化的团队概念，需要用户主动创建团队，而且团队数据和个人数据是分离的，比如钉钉就是这么设计的。当然，这个和底层的数据设计有关，比如Teambition更多是项目协作，因此实际上邀请的是项目成员；而钉钉除了文档、沟通、云盘（即将下线个人版）少部分功能外，大部分功能都依赖于团队，因此要求创建团队才能使用很合理。

平台账号模式的用户账号信息其实是存在平台侧的，也就是登录需要先经过平台应用，具体简化的数据对象关系如下图所示。平台侧除了存储了个人账号信息外，还存储了个人与租户的关联关系，以便登录后能够查询到当前账号是哪些租户的成员，从而允许用户登录时选择租户，登录后可以在不同租户间切换。

将个人账号、个人与租户的关联关系数据存储在平台，好处是可以统一登录体验，比如可以支持微信（支付宝）扫码登录、验证码登录等快捷登录方式。通常来说，为了提高登录时的用户体验，平台会默认将用户常用的租户（或最近使用的租户）作为默认租户，用户登录后直接进入到默认租户的界面。比如钉钉的设计。

当然，这样的设计是考虑了大部分情况，一个人只会就职一家公司。但是，如果涉及到多家公司，有时候可能会出现跨租户的误操作。比如，我在即刻社区上就看到一个人反馈说在飞书云文档里，经常搞错个人和公司的账户（因为飞书云文档需要跳转到浏览器操作，而浏览器会缓存登录信息）。

平台账号还有一个问题就是账号归属权是个人的，如果涉及到IM （即时通讯）功能，可能会导致公司内部的聊天记录外泄。比如，在钉钉里，离职后，依旧能够看到与旧同事的聊天记录，包括传输的文件（目前钉钉专业版已经支持企业账号模式，即员工账号由企业分配，离职后账号自动回收）。

租户账号模式

租户账号模式相对平台账号模式来说，更为简单直接一些。这种模式下，租户的成员账号由租户自己创建，比如租户可以指定成员的账号、密码信息，之后分发给相应的成员，成员登录后直接进入到对应租户的工作空间。这种情况下，所有租户的成员账号信息都存储在租户侧，平台侧无法直接获取租户的成员账号信息（从安全角度考虑，也不应该获取租户的成员账号信息），而且不同租户的成员账号可能重复。这个时候，就会出现一个问题，那就是登录的时候怎么区分当前账号对应哪一个租户？常见的做法有三种：

1）平台统一登录界面，登录时需要输入租户代码，例如平台自动给企业分配一个比较好记的代码，或者有些直接使用企业统一社会信用代码。这里从体验上，建议是浏览器缓存历史的租户代码和名称，方便输入时有提示。

2）租户独立登录网址：给租户一个独立的登录网址，通常是通过子域名标识，这个标识租户甚至可以自定义。有点类似早期博客的个人主页，高级博客可以有自定义域名。例如平台的域名是product-dophin-bay.com，可以给A企业独立的子域名a.product-dophin-bay.com作为独立的登录网址。这种方式实际上就是把域名和租户代码绑定了，这样租户的成员登录时不再需要输入租户代码。对于网址，可以收藏也可以添加桌面快捷方式。当然，如果是有客户端（桌面版或移动版），那么这种形式需要先配置默认的子域名。假设租户成员在多家公司任职，有多个子域名还是需要切换。

3）特殊账号：通常是在账号后增加租户独立标识，实际上和租户代码相同，比如使用企业域名，如account@product-dophin-bay.com。当然，从记忆上来说，如果租户的成员经常用自己的企业邮箱倒也还好。阿里云除了主账号外，其他成员账号的登录称之为RAM用户登录，其实账号就是一个包含了租户代码的特殊账号。

两种模式对比

如果是垂直类的SaaS，其实选择租户账号模式会更简单一些。垂直类的SaaS通常与客户的核心业务深度绑定，客户往往需要培训后才会使用系统，因此一般不提供自主注册。比如我们之前的物业SaaS采用的就是这种模式，我们设定了一个租户代码自动生成规则，采用城市代码+序号的形式自动生成租户代码。基本上6位数的代码能够覆盖一个城市（超出后可以增加到7位或8位）。

对于通用型SaaS，如CRM、协作类、IM类，大部分其实是允许用户自主注册的，这种情况下采用平台账号模式显然会更合理，一方面用户可以自行注册体验，另一方面用户也可能邀请同事加入，从而推动产品用户数量增长。另外还有类似钉钉、企微、飞书这种平台型的SaaS。他们不仅仅提供自家应用，还有第三方的SaaS应用（比如在钉钉里可以使用纷享销客的CRM）。这总情况下，显然使用平台账号模式会更好，可以使用一个平台统一的账号，通过授权的方式接入到多个SaaS应用中。

外部账号互通

上面我们也提到了平台型SaaS支持接入第三方的SaaS应用，如果我们的SaaS产品要上架到这些平台上销售的话，或者是与其他SaaS产品打通账号体系，那么就需要考虑账号体系互通。如果是产品被集成到其他平台，那么按照其他平台的规则获取账号授权信息即可。例如，钉钉平台授权用户信息的获取方式如下：

其中用户userid可以确定账号的唯一性，然后获取有用户详情可以得到用户的姓名、所属部门、职位等信息。当然，有可能有用户在我们自己的SaaS产品也有账号，这个时候可能会出现同一个人不同入口有两个账号的情况。这个时候，就需要有其他确定唯一性的手段，通常来说是通过手机号（海外一般是邮箱）来确认。这块，由于涉及到个人信息，因此需要单独使用用户授权的方式获取，类似于我们在微信里授权手机号给第三方小程序。

如果说我们的SaaS产品影响力足够大，企业客户数也很多，那么自然会遇到一个问题，就是自研的功能满足不了客户的很多诉求。这个时候，我们自己也需要搭建开放平台，允许第三方的SaaS应用入驻，那么就需要有一套账号授权体系，将我们自己SaaS的账号信息安全可靠地授权给第三方应用。这种可以参考像钉钉、企微的做法。

平台运营人员账号

平台侧应用和租户侧应用的业务系统是完全独立的（数据层面，平台侧可以从租户侧抽取数据做平台运营数据分析），市场上目前的SaaS平台不可能给我们去看到他们的平台侧应用。实际上，平台侧的登录入口和租户侧的也是完全分离的。甚至从安全性考虑，有的SaaS产品的平台侧登录可能只能内网登录或使用VPN远程登录。

实际上，SaaS的平台侧可以理解为一个独立的单体应用，而平台运营人员就是我们SaaS企业的员工，这里不存在多租户的概念。因此，对于平台侧的账号管理体系需要单独设计，包括有菜单管理、角色管理、权限设置和账号管理。