工作1年后，我对B端产品用户行为有了新的理解

编辑导语：B端产品也叫“2B(Bussiness)”产品，使用对象是组织或企业。B端产品往往是基于某个业务领域，解决客户在办公或经营过程中遇到的问题，为客户提高效率、增加收入、减少成本，一句话概括就是“为客户赚的更多，省的更多”。本文作者结合自己的工作经历，总结了对B端产品用户行为的看法。

最近一直在分模块复**自己做过的项目，从流程上到了「用户行为」这部分，如下图。

在复**前，我有查过一些文章，但都是在 C 端产品领域上做的分析，总结来说：

1. 用户行为 = 动机 + 能力 + 触发条件，动机：用户底层的诉求；能力：用户是否能做到，或者愿意做到；触发条件：触发行为的最后一根稻草。
2. 借助数据，通过用户行为事件、页面点击、路径、漏斗、健康指标等等的分析，观测用户的行为。借助观测的结果，做产品迭代上的**支持。

以上这些分析思维和方式肯定是没问题的，但并不完全适用于 B 端产品。

接下来，我**从宏观和微观两个方面，谈谈自己对 B 端产品用户行为的理解，希望能对你有所启发。

一、业务驱动用户行为

就拿钉钉来说，里面的功能五花八门，可以说公司的很多业务流程都可以在上面完成。但作为个体的我们，真的都**用到吗？

肯定不是的。

除非是公司要求，否则一个人也无法在上面完成流程闭环，举个钉钉的例子。

1. 钉钉打卡

打卡，是钉钉的核心功能之一，管理员设置好打卡时间、地点等信息，员工到公司按时打卡上下班。

到了月底，人事**根据打卡数据，按公司要求判断是否要扣工资。

从 B 端产品的角度，做个简单的分析。

1）公司期望

管理员工上下班情况是否符合公司规章制度，为奖罚提供数据支持。

2）行为流程

管理员设置 → 员工打卡（上下班） → 管理员查看统计记录。

3）涉及角色

管理员（细分下**有统计人和监督人）、普通员工。自上而下来看，是公司需要管理，而钉钉能很好地满足这点，所以要求我们员工使用它。直白点，如果公司不要求员工打卡，谁**主动打卡呢？

如果公司说，我们换企业微信打卡，谁还**坚持用钉钉打卡呢？

回到一开始提到的 C 端产品用户行为模型：用户行为 = 动机 + 能力 + 触发条件，那么到了 B 端在这里，我们该如何理解呢？

套用的话肯定要重新理解这 3 要素。

1. 动机：业务诉求，即公司经营想要解决什么问题。
2. 能力：业务流程能否闭环，能否真正解决公司的问题。
3. 触发条件：公司的规定。

从这 3 点来看，其实 B 端产品执行层的员工是没有话语权的。老板说好，那就是真的好。

2. 数据反馈和指导意义

既然 B 端产品的使用者都有点被“胁迫”的意思，那像是日活、留存、平均使用时长这些数据指标，观测起来意义就不大。

那我们重点应该怎么看数据呢？

既然 B 端产品都是业务流程，那肯定要是「线性」的分析方式。不用多说，用户行为路径分析和漏斗模型分析是最常见的。举个我的例子，之前我做的一个「创建事件」的功能，埋点如下图所示。

以上筛选的是从首页，到「创建事件」功能用户操作路径的埋点。根据埋点，在数据分析平台上做漏斗分析，如下图。

对于 B 端产品来说，每一步的转化率还是很低的，从 ROI（投入产出比）来看，并没有达到当时的预期。为此，后面也做过简单的分析了解。

结论是：并不是功能流程上的问题，而是客户没从内部要求员工使用起来。所以说，单纯的功能好、流程对是没有意义的，最终还是要了解客户真实的业务情况。

以上，就是我对 B 端产品用户行为的宏观理解。

二、用户视角体**用户行为

之前我做产品，满脑子想的是流程该怎么走，逻辑上应该怎么样。

现在回头看看自己设计的功能，真的不堪回首，也拿出来让大家瞅瞅。

1. 设置下的拍照水印开关

1）背景

客户管理要求督导在巡检门店时，要有自己的定位信息，证明他们确实是在目标门店巡检。同时，上传的图**也需要有「时间」和「定位」的信息，便于后期归档留证。

2）问题和目前的解决方案

我们 App 执行任务时虽然可以定位，但上传的图**没有对方要的「时间」和「定位」的信息。因此，他们只能通过水印相机拍好了之后，在通过我们的 App 上传图**。

3）解决方案

在得知这个问题简单分析后，我决定做「拍照水印」的设置，包含「时间」和「定位」。开启对应项后，拍摄的图**可以带时间、定位或二者都带。

4）我的问题

当时我下意识的认为，用户巡检一定是边拍照**边上传。而忽略了他们可能是整个巡检全部完成后，再统一上传图**。

其实简单的换位思考一下，这就跟出去旅游玩完后，再发朋友圈是一个道理。说实话，这就是办公室产品经理典型的“想当然”，归根究底的原因是：对业务场景不熟悉，没有跟着用户去现场实际上手操作。

百闻，百思，都不如实际一见。

2. 门店巡检后的整改行为

有了这段时间的经验之后，我在设计功能时**习惯多想。

1. 谁**到这个页面？
2. 他们来了之后，分别要做什么？

拿我最近在做的业务闭环来说，当督导巡检完门店之后，提交了报告，有谁**看这些报告？

1. 管理者：看的不多，大多是抽着查看，或者直接看统计后的结果。
2. 督导：如果巡检完之后有问题，**继续跟进直到问题解决。
3. 店长：关注自己门店的违规情况，毕竟跟奖罚相关。

紧接着，再看看这 3 类角色针对「整改」，**采取怎样的行动。

1. 管理者：这里怎么能有问题？不行，我得让店长改掉。此时管理者，需要「发起整改」让店长改进。
2. 督导：检查之后，跟店长确认你这些地方都有问题昂，没冤枉你吧，抓紧时间改掉。此时督导，也需要「发起整改」让店长改进。当然，并不是所有的督导都**跟店长确认，也有可能直接对结果「发起整改」，不告知店长。
3. 到了店长，**有两种情况：店我这里明明没问题，为什么让我改？不行我要「发起申诉」；这里我确实做的有问题，那我整改好了就提出「整改审核」吧。

以上，就是在用户视角下，细微理解用户行为得出的结论。

三、写在最后

说实话，B 端产品想要理解用户行为，最好的方式还是跟着用户跑。

比如我之前，有机**跟着客户去门店巡检，几趟下来发现了可多的问题。这可比在办公室光听、只想，效率要高的多。尤其是观察他们怎么用我们的 App ，这当中感受到的问题，更细节也更真实。

所以，也是应了那句话：“与其听用户说，不如看用户做。”

作者：空；公众号：小木盒产品记

本文由 @空 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议