B端产品后台设计指导手册（1）——账号篇

B端产品的后台业务相对来说会更复杂，也更考验产品经理的功力。本文作者针对自己操刀过的账号管理、权限管理、业务流程、内容管理、数据平台、算法平台等子系统，尽可能详细地论述如何从0到1搭建一个B端产品后台。本篇为系列的第一篇，一起来看看B端后台如何设计账号管理吧。

笔者从事B端产品工作8年，其中有一半的时间在做中后台相关的工作。既有从0到1搭建后台的经验，也有负责迭代比较成熟的后台的经历。

B端产品的后台业务相对来说会更复杂，也更考验产品经理的功力。总的来说，复杂性主要体现在以下几个方面。

B端业务本身就相对复杂。不像C端产品是服务个人用户，业务流程清晰，后台更容易做得标准化。而B端服务的是企业客户，相同行业的不同公司都会有不同的业务特点和诉求。比较极端的情况是服务大型企业的业务，需要结合客户需求做大量定制化的工作。B端后台涉及到的客户的组织结构和更多的用户角，不同的角的用户既有不同的业务需求，也可能有重叠的业务需求。B端的后台可以分成两种。一种是服务自己公司内部的业务后台，一种是提供给客户使用的管理后台。大体上客户的管理后台功能是内部业务后台的子集，但是在具体实践上也有诸多不同。

对于软件系统来说，每增加一个要素，系统复杂度增加都是超线性的，因此B端与C端相比，后台具有更高的复杂度。

本系列笔者针对自己操刀过的账号管理、权限管理、业务流程、内容管理、数据平台、算法平台等子系统，尽可能详细地论述如何从0到1搭建一个B端产品后台。

虽然以B端后台为主，但是如果掌握了B端后台的方法论，相信对于搭建C端后台也会有裨益。

一、后台的核心逻辑

后台的逻辑虽然复杂，但是设计起来也是有迹可循。想要搭建好后台，需要想清楚后台的逻辑。

根据笔者的经验，认为后台最核心的对象就是数据，B端后台一切的操作行为，本质上是对数据增、删、改、查的操作。

数据可以大体分为产品数据（文音视等数字内容、实体商品、算法模型等）、用户信息（个人资料、账号、权限、组织等）、用户行为数据（PV、UV、点击、用户反馈等）、业务数据（如用户的订单、商家的库存、发布的内容等）。

那么如何理解这四类数据呢？我们可以参考下。

用户信息是为了确认使用者的唯一身份以及安全性，也可以用于分析用户画像。用户登录到平台或应用的是满足自身的某种目的，那么就需要服务方提供各种产品服务，比如视频平台的视频、电商平台的商品、商户端的营销服务等。用户使用产品的过程中会产生访问页面、点击、跳转等行为，将过程数据存储下来即为用户行为数据。用户使用产品的结果会产生业务数据，比如电商平台下的订单，社区发布的文内容，办公软件产生的各种办公数据等。

产品设计需要做的核心工作就是将实际业务流程转化为后台的工作流程，然后在用户体验五要素的不同层面进行产品设计，最终在后台系统中对数据进行增、删、改、查等操作。

比如对于电商来说，需要录入、管理商品信息、价格、库存、优惠等信息；为用户触达商品提供搜索、推荐等服务，并且可能还需要算法平台的支持；为商家提高销量提供营销工具；对用户购买过程中的待支付、已支付待收货、已收货等订单和物流信息进行处理和流转；为用户售后服务提供客服等服务；分析用户浏览、评价、意见反馈等行为数据，为改进业务提供数据支持等。

想要为用户提供长期的服务，先决条件是要为用户提供一个账号。那么我们就先从账号体系聊起。

二、账号体系

1. 登录信息

登录信息是账号最关键的信息，我们先从登录界面聊起。我们来看一个B端产品的登录界面。

包括客户码、账号和密码。对于比较复杂的B端业务，除了个人的账号和密码之外，有时还会需要输入客户码。引入客户码有以下几个目的。

对于保密级别高的账号，可以起到提高安全性的作用。当个人的账号信息不小心泄露之后，与客户码对应不上也无法完成登录。方便不同的客户数据做隔离。比如A员工从原公司离职到另外一家公司，就可以直接使用相同的手机、邮箱等注册，避免需要先解除之前的账号绑定才能继续使用。方便不同的客户使用重复的账号。比如说如果企业希望员工使用自己的员工号登录系统，那么不同企业的员工号会存在重复的现象。如果引入客户码，就可以解决这个问题。

当然，为了为了防止机器冒充人类做暴力、大规模在线注册滥用服务等问题，登录界面也同样需要验证码。可以根据需要默认要求输入，或者登录失败若干次后要求输入。

2. 客户信息

客户信息需要解决的是客户是谁、如何查、如何联系等问题。B端产品往往需要服务一个组织客户，其作为一个实体对象，就需要相应的信息以区别其它客户、描述和做数据分析。

客户信息的分类可以大致分为如下几类：

1）基本信息

用户在系统中的最重要信息，用于在数据库和后台界面识别、查询客户。

客户ID：客户在系统中唯一的识别编号，用于与其它客户区分。分配之后就不可更改，否则历史数据会产生大量问题。

客户名称：客户在系统中显示的名称，方便识别、查询。

客户码：可以作为客户在系统中简单的唯一编号，方便识别和查询。也可以应用到登录界面。

客户logo：可以录入客户的logo，即可以显示在后台方便识别，也可以显示在客户系统用户端和后台的界面上，提升客户体验。

2）联系信息

B端业务维系客户关系非常重要，因此需要有客户的。包括联络人（可以与系统账号关联）、（电话、邮箱、传真等）、联系地址等。

）组织关系

对于体量比较大的客户，还要考虑在系统中录入与客户实际组织架构一致的组织关系，可以将不同的用户分配到不同的组织中，方便统一管理、查询、统计数据等。

组织关系也与用户权限息息相关，该点会放到用户权限中展开详细讲解。

4）描述信息

对客户更丰富的、个性化的描述，非必须项。比如公司简介、公司规模、公司行业、公司域名等等。

5）标签信息

为了更好地对客户分层，服务好不同需求的客户，后台往往会有很多标准化、简洁的标签信息。一般不对客户展示。

例如客户的级别，VIP、大客户、重点客户、一般客户之类的，可以简单明了地标记出客户的重要性。

还有客户画像，行业特征、行业类别、公司规模、发展阶段、员工人数、营业收入、地理范围、业务类型等等。

还有客户的合作状态，如首次合作的客户、即将过期的客户、已过期的客户、续约的客户、潜在的客户等等。

这些信息尤其在CRM系统中尤为重要。

. 用户信息

用户信息大家都比较熟悉了，在B端和C端产品中都可以方便接触到。可以将客户为一个小区，其中有不同的单元楼、房间（各级组织），房间中的住户就是需要服务的具体对象。而且信息有很多相似之处，简单罗列一下，不再具体描述。

基本信息：用户ID、用户昵称、用户头像、用户密码等。

联系信息：手机号、邮箱（二者也可用于登录）等。

权限信息：用在系统中的角和拥有的权限等。该点会放到用户权限中展开详细讲解。

组织信息：部门、上下级关系等。

描述信息：性别、个性化昵称、自我介绍、心情、工作状态等。

标签信息：年龄、性别、偏好、地域、收入水平、消费习惯、用户分等用户画像信息。

4. 内部账号

需要注意的是，后台本身也是一个信息系统，同样要有账号体系，以用于登录管理后台。基本上与用户信息相同，描述信息和标签信息可以没有。

三、客户和用户管理

有了这些基本信息之后，需要在后台对客户信息进行管理，以及在客户的用户端和后台让客户自主管理。总的来说，一个比较完善的系统划分如下。

对客户和用户信息的操作增、删、改、查就需要相应的设计功能。客户和用户比较大同小异，我们以客户信息为例。引用之前的一个学校用户的管理后台为例。

1）新增客户

点击新增按钮，可以新增一个客户。

字段主要分成两类，非标准化的字段和标准化的字段。

非标准化的用输入框，允许自由输入，但是要注意字段的限制。比如说字段长度、是否允许特殊符号、敏感词、其它要求（比如手机号可以校验区号和前三位等）等。

标准化的字段如地址、日期、行业等可以使用下拉控件，提供标准化的内容，让用户点选即可。

各种控件的样式目前都已经标准化了，谷歌的Material Design、阿里的Ant Design、腾讯的TDesign、字节的Arco.Design等等，可以自行访问，其中有完整的设计规范、教程、控件等内容。

点击确定时，记得对必填字段和格式进行校验，出错时进行友好报错即可。

2）查询客户

新增客户之后，客户列表中便会多出一条数据。

后台推崇多使用平铺的列表，虽然不够美观，但是字段清晰、查询效率更高。内部的后台不必像用户端一般追求设计感，简单、清晰、易用即可。

列表中显示关键的用户字段并平铺显示，注意过长字段的省略和hover显示。

显示顺序也很重要，可以根据业务需求按创建时间、修改时间、某字段的字母顺序等方式排列。

为了方便查询，可以提供关键字搜索（模糊匹配或精确匹配）、筛选和自定义排序。

客户往往数量很多，因此还需要分页显示。翻页的时候记得继承搜索、筛选和定义排序，避免翻页后相关条件丢失。

）修改客户

修改客户信息和新增时类似，注意自动代入已有值和不可编辑字段即可。

4）删除客户

删除客户可以分成三类。

禁用：暂时禁用客户账号，可以方便地随时启用。软删除：在界面上的删除优先使用软删除，只是不在查询界面显示，但是数据库中仍然保存客户信息。避免误删除之后无法回。硬删除：在数据库中彻底删除客户信息。

对于禁用和删除这种危险操作，一定要记得增加二次确认弹窗！

对于用户前端和后台的设计，也是相同的逻辑，注意根据客户的需求选取重要的字段展示和编辑即可。

同时对于页面设计的美观度也会更高。

5）账号体系拾遗

另外，账号体系中还会涉及到手机和邮箱验证码的服务。

还有一种越来越重要的登录方式——单点登录（SSO）用户只需登录一次，就可以使用他们被授予访问权限的所有应用。

在B端经常运用到不同系统之间的对接，以实现使用本公司的一套账号，就能登录公司内部乃至第三方系统。

C端则使用、QQ、支付宝等被广泛使用的第三方账号完成注册、登录，以降低用户的注册和登录成本。

以上目前都是比较成熟的服务模式，因篇幅所限不再展开。感兴趣可以自行搜索。

好啦，本期就介绍到这里。

今天是双倍冲票日，亲不要吝惜手中的票票，给笔者继续更新《B端产品后台设计指导手册》其它模块的动力。

为我投票

我在参加人人都是产品经理2022年度作者评选，希望喜欢我的文章的朋友都能来支持我一下~

点击下方链接进入我的个人参选页面，点击红心即可为我投票。

每人每天最多可投5票，投票即可获得抽奖机会，抽取书籍、人人都是产品经理纪念周边和起点课堂会员等好礼哦！

专栏作家

一直产品汪，：apmdogy，人人都是产品经理专栏作家。逻辑型产品经理，致力于将科学思维与产品经理方法论结合。关注人工智能、教育领域，擅长产品孵化、需求挖掘、项目管理、流程管理等产品技能。

本文为人人都是产品经理《原创激励计划》出品。

题来自Unsplash，基于CC0协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。