近十年互联网行业井喷式发展，C端产品基本触顶，流量的红利逐渐消退，不少企业也开始从C端业务向B端业务倾斜。各大互联网巨头经过多年扩展之后，各自版图内涵盖的企业越来越多，集团内各个企业间业务协作，IT系统建设过程中资源复用，内部系统、数据，资源产生整合需求，企业服务的就业岗位占比在不断增加，那如何转战B端抓住机遇？今天我们就来聊一聊如何入门B端：

1.了解B端产品

1.1目标用户

B端顾名思义是To B业务，B（business）意为企业用户或商业用户，B端产品往往是为针对这类用户开发的系统型软件、工具或平台。例如：CRM 系统、 ERP 系统、OA系统、SAAS等等。产品更多的是在企业内部使用，为了满足企业相关用户在“工作场景”下完成协同工作的一些特定组织需求。

举个例子：B端财务公司的资金系统，甲企业向乙企业支付一笔资金，由企业内部业务人员在固定的办公室操作系统完成支付，是组织内的支付行为。C端天猫购物平台，个人要在平台上购买一件商品，是独立的自然个人购买行为且使用场景不限。

目标用户

1.2产品概念

产品的本质就是能够解决“目标用户”的“问题”。为了便于理解，我们先以C端产品为例。C端产品比较热点的微信、美团外卖、滴滴出行、抖音，基本围绕衣食住行来为C端客户创造价值。来看下面这副图：

C端产品解决痛点

上面列出的七个词语，对应的是”七宗罪“C端产品是利用人的各种欲望，来挖掘生活中的各种痛点。

例如：

各种摇奖、打折——>“贪婪”；

美图、直播——>“虚荣”

滴滴、单车——>懒惰

在此强调的是：C端产品，解决痛点是针对“自然人”自身的需求。是自然人直接的需求！需求即“人”欲！再来看看B端产品解决的是什么痛点？

首先自然人会在组织（公司）中工作，担任一定的角色，负责在公司的工作流程中承担某些职责。公司的工作流程又是根据公司所处行业特征、业务类型总结制定的。并且公司还为工作流的执行，制定了相“符合”的组织架构。

以上这些可以总结为“组织特征”，跟C端相比，自然人已经被组织赋予了特定的角色和职责，自身的欲望在这个过程不在展现（至少从公司角度，希望完全不展现！）

这个时候由多个自然人组合而成的集合”公司“，又成了一个需要解决问题的基本单位。

根据组织（公司）的特征，结合当前行业发展阶段，总结B端产品对应的组织需求共三类：

①提高工作效率：通过提高团队的工作效率，更快的完成任务，适应当前快节奏的市场。例如钉钉、HRM、ERP、CRM；

②节省成本：通过减少重复建设、统一管理，来减少建设、管理成本投入。例如统一认证中心、各种中台；

③资源整合发挥价值：公司规模较大之后，各个子公司之间往往可以进行互相利用。例如各大公司的中台战略；

如下图：

B端产品解决痛点

在此强调的是：B端产品，解决痛点是针对“组织”需求。是自然人间接的需求！需求即“组织”欲！

虽然B端产品的使用者仍然是自然人，但是针对的并不是自然人的属性，而是自然人组成的”组织（公司）“的属性。

很多B端产品设计，其实是违反自然人诉求的，例如钉钉消息已读/未读状态，淘宝、美团外卖的IM也有这个状态。微信这种C端产品就没有加。B端产品有已读状态是因为公司需要更好的管控员工，C端没有是为了保护用户的隐私。很明显能够感受到他们在解决谁的问题：B端---组织；C端---个人。

明确B端产品这个特征之后，我们在进行B端产品设计过程中，就可以以此为设计出发点和依据！这就是帮我们认清Ｂ端产品的核心。

另外，商业行为总是要以盈利为目的的，B端产品当然也一样。但是B端产品的购买决策与真正使用者，往往是不同的角色，这就需要B端产品经理在设计产品的时候，兼顾更多的干系人意愿。

综上，这里给出B端产品的概念：

解决“组织痛点”，实现“商业价值”！

1.3 产品分类

B端产品类别如下图：

B端产品分类

下面再从两个维度的分类：

• 产品提供和使用方组织关系；
• 产品服务特征；

进行分类，也是希望更进一步的区分产品特征：首先是可以作为产品设计依据，其次也可以为想转行做B端产品经理的朋友做个参考。

1.3.1 产品提供和使用方组织关系

(1)产品提供方和使用方为不同企业

 产品提供方和使用方为不同企业

特征如下：

• 交易过程涉及到商务条款；
• 获客需要销售推进；
• 与传统软件模式接近；
• 团队中产品经理话语权较少；

(2)产品提供方和使用方为同一企业

产品提供方和使用方为相同企业

特征如下：

• 一般无直接商务条款；（也有例外，腾讯提倡内部结算）
• 产生目的多为提高内部工作效率；
• 面对真正外部市场机会较少；
• 产品+技术，两个因素驱动；

1.3.2 产品服务特征

     （１）企业内部工作协同（定制化功能较多）

               这类接近传统软件产品，例如ERP、WMS。

企业内部工作协同（定制化功能多）

特征如下：

• 专业性：依赖行业、专业知识。与企业业务流程结合紧密；
• 通用性：个性化定制功能较多，每次部署边际成本较高；（企业间业务流程、规章制度、组织架构差别较大，很大一部分功能需要针对企业现状进行定制化改造或新增）；
• 产品用户：产品直接使用者往往是特定岗位的少部分专业工作角色使用（财务、法务、物流）；
• 学习成本：功能复杂度高，操作学习成本较高，迁移成本高；
• 市场策略：产品购买者往往是较有一定规模的企业，获客成本较高。开拓市场偏向传统软件，以销售为主；
• 部署访问方式：本地化部署、PC端访问为主；

（2）对外标准产品（定制化功能极少）

        这类更接近C端互联产品模式，扩张边际成本低，例如钉钉、阿里云。

对外标准产品（定制化功能少）

特征如下：

• 专业性：具有一定专业性，但专业性没有那么强。更多切入普遍适用的工作流程。（有些是模式创新倒推原有各异的工作模式改变，形成统一的模式，例如阿里云、百度统计）；
• 通用性：最大限度的抽取了通用功能，减少定制化功能；（产品“接近”标准化，使得这种B端产品，与C端产品最为相似）；
• 产品用户：产品直接使用者为企业大多数员工。同一企业，使用者较前一种分类，比例高很多；
• 学习成本：学习成本较低，一般通过对工作常识性的理解即可上手。（因为是标准化产品，更加重视用户体验，也使得学习成本降低）；
• 市场策略：产品购买者可以更加轻量级，付出成本较低。市场推广方式采用“B类销售+C类线上”结合方式。
• 部署访问方式：SAAS为主；PC端为主，但在迅速的向移动端转移；

（3）中后台产品（定制比例很高）

        这类主要是企业内部开发的一些支持功能模块，例如各个公司的中台。

中后台产品（定制化比例高）

特征如下：

• 专业性：具备一定业务专业性，但更多的是基于技术解决方案考虑。减少重复建设、整合资源等目的；
• 通用性：通用性很低。根据每个公司的业务特征，发展阶段。系统建设历史不同。解决方案都会不同；
• 产品用户：没有真正意义上的使用者。更多倾向于技术功能模块。为其他IT系统提供支持，通过接口互通；
• 学习成本：需要“公司业务知识”+“技术知识”+“公司IT系统现状”+“公司发展规划”都了解，才能胜任设计和使用工作；
• 市场策略：绝大多数是公司内部各个部门之间协同使用，不涉及商务内容。少部分标准产品，可能会对外开放，例如统一认证中心对外开放第三方登录功能；
• 部署访问方式：本地部署；技术同事后台访问操作；

以上分类希望可以帮助产品设计在工作中：

识别干系人；

根据用户特征进行设计；

根据所需能力进行自身能力完善；

根据商业模式，决策产品规划和功能取舍；

当然分类不是绝对的，只是根据当前B端产品现状的总结。各个类型之间会互相转化，例如阿里云最初为内部解决方案，慢慢的开始对外提供服。

未来B端会大致会朝着“SaaS、移动端、重用户体验”方向发展！

2.B端产品设计重点

2.1功能设计

2.1.1 配置化

较复杂的信息化系统实现上若做成固化方案(前端写死)，后期维护优化的成本会随着不断的迭代更新而增加

在设计功能字段时，可以通过建立数据字典的方式可以充分满足业务场景的多样化，提高产品使用的灵活性。业务发生动态变化就调整配置项

界面-数据-流程-功能

• 业务流程：功能配置，数据配置，界面配置，流程配置
• 基础信息：角色配置，权限配置，组织配置，字段配置，审批配置

但是若将产品的大部分功能/字段/数据进行配置处理，会导致实施成本高。过于灵活也会导致用户组织使用的学习成本增加，系统本身变得越来越复杂。把握好配置方式/分类的灵活度可以满足用户的大部分场景与需求，通过实现合适的可配置化，可以提高用户的使用体验

2.1.2 耦合度

前期避免过于扩散导致后期产品可塑性变弱，难以进行拓展，促使迭代成本异常高昂，导致产品缺少体验的一致性和功能的复用能力低，投入的成本与获取的价值不成正比。要不断的降低耦合，否则迭代将越来越困难，甚至会导致重构/增大研发成本。不同模块之间简化拆分成相互独立的环节，降低需求问题分析的复杂度。

耦合性

• 在模块化设计的前提下思考业务流转，内部的逻辑兼容；
• 基于业务的形态考虑功能的边界，扩展三方合作(硬件设备，接口支持等)；
• 高耦合度往往体现在功能逻辑出现较大的交叉重叠，如同牵一发而动全身；

2.1.3 结构化

在分析系统时，将不同业务角度的需求功能进行分割，以功能易用/数据安全为基本准则，同时考虑未来的扩展性/数据在业务之间的流转，来平衡整个系统的设计方案

结构化

• 信息结构层级区分：系统路径层级过于深入。需要减少结构层级，模块化设计；
• 功能规范不一致：相似操作性质无法保持统一，数据不够结构化。操作不够灵活；
• 考虑系统与外部系统的对接关联；
• 考虑系统内部各个模块之间的数据流转，以及模块内部的数据关联；

2.2 体验设计

2.2.1 数据的定位展示

数据维度展示：提供精确的数据可视化参考，并突出核心指标。在后台产品存在大量的数据报表和可视化的图标。这些数据的实时变化指标注重"可读性""可对比性""易操作性"。用户可快速定位有效的数据信息

数据展示

• 基于业务：列表的数据信息都是基于业务、基于使用场景的；
• 追求效率：用户能够快速定位有效的数据；
• 辅助分析：展示的数据对用户作用都是有价值的，且能起到辅助分析的；
• 引用数据字典的应用方式，后期应用于数据标准化的整合与分析；
• 聚合搜索所有一次性搜索列表中所有颗粒度(业务字段)的数据，虽然可以快速定位所有匹配数据，但当检索数据过多会造成搜索时间过长，结果不够精确等；
• 颗粒度搜索(业务字段)将主要的字段信息单独列为搜索条件，虽然可以改善聚合搜索的劣势，但可能会造成页面展示字段过多，影响视觉体验；

2.2.2 卡片化和步骤化

B端展示给用户的信息密度过高，缺少层次性。而通过聚类相似信息的卡片化的方式，分割差异化信息，有助于降低信息的复杂性，帮助用户快速定位信息、浏览内容

而且将复杂的信息内容分步拆解，把用户的关注点带到步骤进度上，通过节点信息页可以帮助用户理解业务流程

步骤化

2.2.3 转化引导

通过业务节点了解业务流程的传递方式，评估业务流程的总量，耗时以及效率。简化长流程的同时也要时刻注意因为流程过长导致的节点信息是否可进行有效存储的问题

转化引导

如同钉钉的实时存储，或多角色同一节点的同时操作等待

• 将次要信息在某个节点通过弹窗的形式填入，节约流程跳转的步骤；
• 页面区域提供用户存在的信息(最近引用信息，历史信息等)，选择点击后为用户快速填入；

提升各个模块之间的内容辅助引导(帮助中心，关联性提示等)，使业务功能的使用在流程上易于过渡，一方面减低业务过于独立造成的利用率不高，也能促进用户更快认知系统产品。在体验上减少隔断的感觉。辅助用户决策

2.2.4 数据量

系统型产品往往有大量的业务数据需要在服务端与应用端之间进行导入或导出，这种情况会考研服务器本身的响应时间。服务端可以通过代码分布等方式进行优化，产品功能层面可以先让系统生成数据，然后让用户下载数据

数据量

导入数据的注意点：导入Excel表中的重复数据识别，导入数据与系统数据重复值的匹配更新与新增。导入数据本身重复值的识别。导出的Excel表最要用【名称+导出年月日+序号数作为名称】作为名称标识

2.3. 设计总结

2.3.1 设计原则

做好功能的归属分析，归类功能的所属业务范畴，避免因"耦合性"过高增加系统的复杂程度/导致难以维护和扩展。平衡系统涉及的整个业务链路(角色，流程，目标)

产品不仅要精准触达用户，又要促进用户决策。理论上说产品和功能可以无限迭代。达到某种完成程度则对应投入的资源的分配，交付的时间与功能的体验感

• 要保证MVP可用；
• 要保证MVP为用户痛点；
• 要保证MVP的用户体验感；
• 要保证MVP足够小/一定要砍掉非必要功能；

MVP（最小可行性）

当系统完善到一定程度后，通过接口集成其他产品功能，个性化的拓展功能设计。因系统本身的复杂性(多平台的对接)也需要了解相关技术的知识，如接口文档相关输入输出参数规范，可配置化的数据字典，功能逻辑调用关系，以及影响产品迭代的“耦合度”

• 系统的公告/通知很容易忽略；
• 操作指南的内容过多一般不会关注；
• 功能的默认值因为用户的警惕性一般不会去主动变更；

2.3.2 设计策略

让用户最大限度体会到产品的核心价值，用户使用产品的意识不够强烈，使用产品的场景不够高频，提升客户的业务价值是需要重点关注的指标。

• 反馈：在合理的时间用适当的方式向用户提示或反馈程序的状态，例如上传文件时的进度条；
• 回退：用户不小心的操作错误，对应一个恢复到错误发生前的状态的功能，例如撤销功能；
• 一致：产品不同功能模块页面的风格一致，避免和减少高成本操作；
• 简约：减少没必要的信息，强化重要信息。例如视觉上的“突出标记”；
• 灵活：简单易用的前提下，还需支持个性化的灵活性。兼顾少数需求。充分发挥功能价值；
• 隐喻：运用专业的文字描述，符合使用用户的认知行为习惯；
• 防错：在程序执行过程中未结束时，尽量给出系统的提示。防止错误连续发生；
• 记忆：程序在用户使用时呈现相关信息给用户，例如搜索的历史记录；
• 容错：程序运行错误时，避免用户疑虑，提供用户能明白的内容引导建议；
• 引导：辅助减少产品的学习成本。通过文档，操作指引等方式引导用户；

写在最后

随着企业业务的转变，我们求职者也必须跟上步伐，快速做好角色的转换。当然，想从C端产品快速切换到B端产品，或是从B端产品快速切换到C端产品并非易事。因为C端和B端产品设计存在较大的反差。其商业属性、产品定位、目标用户、设计表达、业务流程等都会有很大的不同，但无论哪个行业刚入门时都是比较迷茫的，要找准自己的定位，明确自己的方向，朝着方向去努力，就一定会有结果的。

Powered by Froala Editor