半年来接触客户，我学到了什么？

到了数据分析这里，用户反馈一直以来是我的一个痛，原因是：

（1）之前网课上学的理论，更倾向于 C 端产品，好像在 B 端领域不适用，而且我也没找到对应的方法论。

（2）客户反馈不仅包含需求，还有很多操作上的问题。

但随着工作中与客户接触的越来越多，才发现自己对这两点的理解太表面了。

下面我会围绕以上两点分享自己思考，希望对你有用

一、C 端产品的用户反馈

我大致捋一遍网上最常见到的， C 端产品收集整理用户反馈的方法与流程。

01、 明确收集渠道

在这个互联网发达的时代，获取用户的反馈不是难事。

最重要的是要能把这些渠道梳理清楚，形成没事就去看、去了解的习惯。

02 、收集与整理数据

通过上面的渠道，我们就能收集到包含各种字段的用户反馈。

为了便于分析，我们肯定要按统一的表头处理这些数据。

拿我之前网课中的小作业，整理的是 foodie 这款美食相机的用户反馈，如下图：

当然，如果公司有现成的格式那就更好了，如果没有就得自己梳理，切记要「简约明了」。

03 、分析反馈，并给出行动计划

C 端产品的用户体量大，必然要对同类问题进行规整，比如我当时在表头特意加了个「类似评论条数」的字段。

紧接着，就是针对每条的分析提出解决方案，并纳入需求池里面排期开发了。

小结

上面的方式，主要还是从用户评论的角度入手，还有一些其他方式，比如：

无论是产品调研，还是数据分析，这些都是发现产品问题的手段，也是我们理解产品的重要方式。

二、这套方法能用在 B 端产品上吗？

方式不可以照搬，但流程却是可以参考的，重点是如何在工作中形成自己的 SOP。

以我这段时间的经验举例，流程照旧：

01、 明确收集渠道

与C 端产品不同，B 端产品的使用者是扮演着业务流程中的角色。

操作难度高，对用户提出的问题也需要进一步深挖，但有时候公开渠道没有追问的条件。

02 、收集与整理数据

这段时间与客户对接的多了，发现对方的反馈大致可以分为两类：

（1）、操作上的不明白

对方如果只是不懂怎么操作，那其实还好，只需要解答就好了。

但有些操作问题，是隐藏在对方提出的“需求”中，像是客户前阵子跟我说，期望在导出数据中能区分任务状态。

对于 B 端产品来说，一定要追问对方的目的、场景、操作等信息。

还是那句话：“谁在什么场景下，因为什么遇到了什么问题，现在是如何解决的。”

按这个套路，在后面细聊的过程中发现，对方其实是想看哪些门店在规定时间内「未完成」。

但从功能上，其实在详情页面直接筛选就好了。

明确反馈的类型，是需求还是问题，这个步骤很关键。

说句题外话，其实客户经常会提各种各样的问题，这时为了便于解答，整理出一套「帮助 + QA文档」是很好的方式。

（2）、功能不能满足业务场景

拿我们的周期任务设置来说，目前是不支持「次日」这种隔天设置的。

而对于餐饮行业来说，夜间经营又是很常见的情况，比如 22:00 到次日 4:00 这种。

在收集到这类问题时，首先还是去了解信息。

其次就是跟客户沟通，当下系统已有的功能如何能解决他们的问题。

在这个过程中，不断收集信息，挖掘整理成需求，规划排期进行开发。

三、写在最后

在输出这篇文章的时候，我才发现自己在工作中，潜移默化在用着之前学到的方法论。

并不是完全照搬，而是使用过程中不断的删减与调整，慢慢成为了自己做事的习惯。

仔细想想，工作本身就不是一成不变的公式，要结合人、团队、公司做出调整。

希望这些分享，能带给你一些启发。

 -END-