时间: 2021-07-30 11:50:53 人气: 12 评论: 0
文章结合最近公司几个产品模块的替换选型过程中的苦逼与吐个槽这个活动，用一个虚拟的选型故事，分享一下产品/功能选型的坑，以及吐槽功能的迭代优化点。
因此【吐个槽】细节层面不展开。如果是有应用要新增吐槽反馈的功能，笔者是力荐各位接入【吐个槽】。结合一下最近公司几个产品模块的替换选型过程中的苦逼与吐个槽这个活动，用一个虚拟的选型故事，分享一下产品/功能选型的坑，以及吐槽功能的迭代优化点。
一个水平一般的研发可以坑死3个优秀的研发，一个规划不好的产品可以坑死一群人。
TIPS1：选型基本纬度
TIPS2：问题分析法：5W1H要多用
TIPS3：【用户体验五要素】的战略层与结构层与选型/产品方案的方向基本一致。
目录：
- 突如其来的老板任务
- 激烈的方案讨论
- 产品的定位与初衷
- **议纪要
- 【吐个槽】简单分析
- 功能上线是新的启程
- 【吐个槽】的落地现状
- 【吐个槽】的新功能遐（瞎)想
某日即将进入下班倒计时，办公室大伙还在讨论得热火朝天（下班吃啥），突然微信群弹出了老板的一段话，办公室顿时沉寂下来，最后还是背锅王主动站出来为老板分忧
在背锅王的组织下，公司内部迅速成立一个小组，准备解决的老板需求，在群聊内，大家初步贡献了在线型、非实时型、运营/社群型，爬虫型的方案，由于为群聊，沟通成本较大，准备次日开**讨论。
次日上午，召开了跨部门沟通**，**议上大家讨论了在线型、非实时型、运营/社群型，爬虫型的方案讨论。
营销老王先抛出了在线客服1.0方案，他认为，直接听到用户的心声是最简单明了的沟通方式，因此公司采购一套400电话客服系统，客户就可以直接通过热线电话反馈问题，通过系统配置IVR**语音，能便捷引导用户使用公司的业务。老王本以为这个方案能让大家服气，结果遭遇大家一面倒的质疑。
财务莉莉：我先提一个疑问，购买一套电话系统要多少钱？听说还要购买服务器，还要做开发？这个采购报价我提给老板，估计立马被开了，你想过采购成本么？
运营喵小花：电话系统客服顶多支持1对1沟通，如果多个**话进入，就要排队，客服人少了，排队时间长就影响用户体验，客服人多了，如果没那么多的反馈，那么就没什么意思了。这个还得考虑人力成本进去。
攻城狮（砍需求）：上次公司的服务器差点被冲垮，公司都说没钱买新服务器，怎么可能通过这个方案，要我说，还不如直接把公司的前台固定电话公布出去，还省钱呢。
前台美美：你以为我很闲么？还要我负责接听电话，我还负责很多跑发票，办证等业务呢，谁爱听就公布谁的电话。
产品汪无声：老板说要数据报表怎么办，我们还得另外做开发么？老板说了这个需求很急喔。
背锅王：电话客服系统不满足我们当前的公司现状，我们人少，业务不多，为了一个不确定的业务，采购电话客服系统再付出人力成本与技术开发维护不现实，而且到时候节假日，谁回来公司上班处理进行值班？如果公司业务大了，那么电话客服系统还能结合电话营销，进行相关的运营促销，如果没有更好的方案，那么就攻城狮说说他的方案吧
营销老王不死心地提出在线客服2.0方案，既然在线客服只能1对1服务，而且需要回来公司上班，那么可以接入**在线客服，那么就可以实现在家值班，且能1对多服务，沟通完还能获取客户的**号，可以后续回访。结果再次遭遇暴击。
攻城狮（砍需求）：**在线客服系统，是PC上嵌入代码，虽然简单，但是我们是PC+APP，这个功能无法覆盖业务场景，做了没有多大价值。
营销老王试图再挽救一下，试图用旺信这个例子说明IM是可行的方案，因为已经集成了知识库，自动应答，这个方案具备一定的可行性，最终在线IM这个思路暂时得到大家的认可，细节待定。
攻城狮（砍需求）提出了非实时，内容沉淀型的概念，认为相比在线客服这类单纯的1对1服务，很难找到问题的共性，而且对于公司而言，在线客服消耗的都是公司的资源，无法通过KOL等方式把成本转移出去。因此借助开源的论坛，可以形成一种公司与客户直接，客户与客户之间的良性互动，常见问题，热点问题也可以通过置顶帖子的形式来展示，而且开源的功能足以满足公司的功能诉求。更为重要的是，不再需要实时回复客户的问题，可以大大降低大家的工作压力。
攻城狮（砍需求）看到大家陷入了思考后，再抛出京东、天猫的商品评论。论证这种交流互动是一个强需求。于是大家的目光转移去了运营喵小花。
运营喵小花：我先说说我的看法，我承认这个内容沉淀是一个很有价值的思考点，但是公司现在就我一个运营，我还得负责**，微信群，要我还负责社区，有点吃力。
产品汪无声：换我说，如果只是收集用户反馈，建立一个留言板或者更合适（实现了英雄救美）。
背锅王：攻城狮和产品汪无声这种论坛/留言板的非实时型的方法很不错，我们再看看其他人的方案。
运营喵小花提出了运营/社群型的概念，如同她培养种子用户那样，建立**群，微信群，或者成立公司的微博号就可以与用户实现点对点的沟通，依赖于**当前的**号和微信号，微博的覆盖情况，认为这种方案成本低，无技术门槛，完全符合老板的好用，简单，成本低（近乎0）的想法。
营销老王：我不太认同你的观点，**群、微信群、微博号，后续都是用于做营销活动的多，而且这种里面产生的内容很多是没有营养的，而且非在线/加入对应群组，对内容无感知，即使加入群聊，仍需要翻查相关聊天记录，较难实现信息沉淀。
攻城狮（砍需求）：依赖于**群，微信群，微博，万一老板要问题反馈来源的统计，估计大家都得崩。
于是大家陷入了寂静。
产品汪无声：我来说说我的观点，由于这次老板是在应用商城看到应用评价的，我们能不能做一些爬虫的工具，去搜索我们相关的内容呢？我们再二次整理，收集，那么这样的工具开发之后，以后定时看下结果就行了，大家也不用那么折腾。
营销老王：我不太认可这种做法，虽然爬虫获取的数据很多，但是很多都是其他途径获取的内容，我们缺乏最关键的联系方式，无法与客户进行二次确认。
攻城狮（砍需求）：目前很多网站，都有防爬虫的机制，这个效果得看下实际情况才能得出。
背锅王看到大家讨论得非常热烈，但是跑题越来越远，忍不住泼了大家冷水。
背锅王作为主持人，重新掌握话题：老板是反馈功能要好用，简单，成本低，大家在讨论方案的时候，真的以公司的实际情况调研和方案选型么么？产品运营必读的【用户体验五要素】，某种程度上，也是功能选型/产品思路的方向，大家有以这个作为产品选型的起点么？
商业目的：明确定义成功的条件，而不是成功的路径，才能保证我们在这个阶段不至于目的太抽象，也不至于由于目的太过于具体而限制了创新和思考。
成功标准：比赛都有终点，理解产品成功的标准，就是告诉我们是否达成了用户的需求和我们的目标。
范围层：把用户需求和产品目标转换为“应该给用户提供什么内容和功能”，战略就变成了范围。包含产品的各种特性和功能，任何一个功能是否该包含在这个产品当中。
战略层与范围层，本身组合起来就是一个选型的基础方向，在这个阶段，我们可以复用问题分析法：5W1H进行论证。
问题分析法：5W1H
5W1H套用现实场景就是：导航去目的地，要考虑路途的长远，自己有的交通工具，其他交通工具，时间和效费成本。每种方案各有利弊，需要综合考虑。
对于背锅王提出的**依据，参与**议的各方没有异议，于是大家针对好用，简单，成本低的思路逐一对于已有方案进行选型论证。
营销老王的实时型思路首先PASS，原因是成本。
实时型对于用户的感知是有帮助的，能快速响应问题。即使到了现在，客服仍是很多大型企业的必要岗位，把客服作为面向客户的第一道防线。但即使银行，运营商，也在逐步从电话客服转移到在线客服，然后再辅助各种知识库？
科技是在进步不假，但是客服本身需要有专业的能力和素质，但人的精力毕竟有限，在线客服撑死了能同时对接10个左右客户的问答，但前期投入较大。因此业务量少的时候，投入大量人力物力不划算，业务量多的时候，还得继续增加客服人数，成本还是不划算。
公司属于拓展阶段，暂时没有相关同事能及时响应客户问题。再者即使到了需要客服支撑的阶段，也不能作为一个核心入口来收集客户反馈，而是要解决客户问题。
运营喵小花的运营/社群型方案也出局了，原因是好用。
这个对于公司而言，**/微信/微博，前期开发成本近乎为0，只要双方登录**和微信，微博就行了。但是这个是一把双刃剑，把问题的反馈放于社群，要么就是各种聊天记录把有用的信息覆盖掉，这个对于数据报表是一个非常不利的一种方式。
而更为关键的是，这个反馈模式，只能依托于当前的社交工具，无法植入我们的APP，也无法植入相关的PC/小程序，因此只能用于营销类型，辅助收集一下问题，但不能作为问题反馈的主入口，这个方案只能PASS。
产品汪无声爬虫型方案待定。
爬虫型方案虽然有短板，即使有些网站无法爬虫爬虫，但是在基数大的情况下，仍可能收集到大量的数据，但是爬虫型与其他方案最短板的，在于没有联系方式，可以反向回访客户。再者现在很多【云用户】随意发表意见情况下，如何收集到有用的信息，是一个值得考虑的问题，这个可以作为是一个拓展方案，论证现有已经接收到的反馈是相对吻合的。
只能说，现阶段的优先级不高，可以作为后续辅助拓展使用。
攻城狮的非实时型的论坛/贴吧方案待定。
首先得肯定，这是一个很好的内容沉淀的模式，与其他模式相比，最起码划分了聊天的板块，实现了内容的聚焦，置顶帖子也是可以勉强替代为知识库的功能，基于开源的技术，也可以实现一些报表功能，是一个比较完美的形态。对于一个产品而言，收集到用户的信息，敏捷处理是可以大幅满足用户的满足。
比方说：小米论坛，产品与研发经常与用户沟通，获取用户的反馈加以改进，但是现有的模式，仍有一定的局限性，比方说要内嵌到APP及小程序内。这样的功能，是否能满足，还需要论证。
最后背锅王开始了小总结。
产品选型要回归到公司的人力现状。员工合计48人，大部分都是技术和运营，不适宜投入过多的人力。
公司的产品涵盖APP+小程序+网站，未来可能涵盖公众号+H5乃至其他业务场景，要考虑拓展性问题。
关于这种情况，我个人倾向于论坛贴吧的方案，但由于存在较大的投入，可以尝试用户留言板类似的功能代替，实现快速开发，敏捷上线，内容沉淀在公司服务器，便于抽取数据报表等功能，可以对于用户的信息也能实现追踪回溯。
攻城狮补充，如果只是一个留言板的功能，那么只是作为一个数据的承载，对于开发的工作并不是很多，关键是要明确需要怎样的功能纬度。只有需求明确的情况下才能进行工时的估算
to： all
cc ：boss wang
【**议纪要】问题收集产品的选型方案暂定为留言板
上午对于现有的收集用户信息的方案进行讨论，针对公司的现状及未来发展所需的功能进行广泛沟通，认为留言板功能目前比较适合公司的现状，输出各类产品优劣对比如下：
两分钟后老板又在微信群给大家加油鼓劲了。
吐槽反馈功能5W1H：
吐个槽，如同一个精简版但更垂直的反馈板块，无论是前台和后台，都可以明显看出都是为反馈内容而打造的吐槽功能。
（1）关于反馈的这个需求，西蒙半年前曾收到过，曾想着用文本记录敏捷上线，最终3个月前这个需求从需求池被清理掉。需求无法落地在于业务方仅仅把这个功能作为一个用户吐槽的入口，无运营方案，无相关对接人，真的就是一个【吐槽】，既如此，要来何用？若业务方带着运营方案重提吐槽功能，说能给产品带来更好的设计理念，我**选择【吐个槽】，无他，敏捷省事。
（2）于笔者而言，一个功能的上线，只是另一个坑的开端。因此功能的开发前要有运营方案，与运营人员进行讨论，功能上线后要验证功能是否满足运营需求，一个无法为公司带来实质性效果的需求，某种程度上也是一个伪需求。
（3）一个功能上线后的运营/技术/产品复**，能让产品的成长有更多的可塑性。
（4）从**产品接入的情况来看，产品的特性，公司的环境不一样，未来发展趋势，功能诉求点不一。那么对于选型，都是一个不可忽视的内部因素。因此在选型前后，都要综合考虑。这又回到了开头的小结，一个水平一般的研发可以坑死3个优秀的研发，一个规划不好的产品/功能模块可以坑死一群人。
【吐个槽】功能足以覆盖很多没有专职客服的中小型企业，让他们在较低成本与内容沉淀方面，与客户进行对接，但是如上一段的功能上线是新的启程，关于【吐个槽】的功能，在客户使用层面有更多的改进空间（非纯粹工具本身）。
在吐个槽的官网首页，我们可以看到企业微信是作为一个标杆，恰好西蒙公司也是用企业微信，于是对于这个页面进行体验，吐个槽的定位在实际场景中：从吐槽功能的入口演变成咨询客服的入口。
一个置顶帖子里，告知用户要怎么遇到解决问题。然而理想很美好，事实很骨感，帖子下面都是问问题的……
而这个在线客服的入口究竟在哪呢？
虽然最终找到了客服中心，但是这里面引申自己很多的思考：
**视频虽然有了常见问题，但是由于产品特性，把常见问题，无法搜索的问题放大了。因为涉及费用，**，**视频等常见问题，心疼Dolly天天在论坛回复客户的问题。已经是一个客服的工作了。
虽然**视频的吐槽场景问题也有涉及**的问题，但是却是另外一个客服支持的页面，最终能够支撑大量问题的，只能通过【**帮助中心】才能找到更核心的内容与在线客服。
吐个槽某种意义上，就是一个SAAS化的服务，只要接入了这个服务，就能享受通用的服务，我想这也是这个产品能迅猛发展，攻城略地的一个基石。但就如用户的需求是各种差异化的情况一样，对于单一只使用吐个槽的产品而言，已经基本上满足了日常的反馈需求，但供应与个性终究是一个要面对的一个门槛，针对吐槽的情况，西蒙瞎想了以下功能的拓展情况。
瞎想1：就如企业的发展，终究**升级为在线客服，可依托**的**客服与微信客服，可以提前预置相关的**客服入口，微信客服入口，允许接入方升级相关服务，提升合作方与**产品体系的粘合度及替换成本，甚至还能打包卖一个组合套餐。
瞎想2：对于【吐个槽】而言，一个常见问题的模块固然能满足吐个槽的功能，但却没有与合作方的具体需求形成强关联，用户需要在【吐个槽】才能查看常见问题，那么或者可以考虑把这个模块抽离出来做大做强？做成一个通用的模块或者接口？但是实际上还是使用吐槽后台来调用和配置？且做到多端统一，从而提升常见问题的效费比，基于这个还能深度切入**系产品，降低自身产品体系的维护成本。
瞎想3：当前【吐个槽】设计初衷是只是一个反馈问题的入口，但是在需求与问题混杂的情况下，是否需要区分2个或者2个以上板块来满足用户的反馈诉求？这个就如一个论坛贴吧的模式，区分交流、问题反馈的归集，从而形成一个微型的社区空间。众所周知，开展且维护一个用户社区的成本较大，通过新业务以及从而给吐个槽产品带来更多的想象力与其他附加价值？
瞎想4：吐个槽可以新增运营活动的投票等情况，某种程度上也是帖子的一种属性，也可以提升与用户的沟通，比方说：下期活动是送皮肤还是**石，这个可以结合上面的社区空间进行结合，提升工具的实用性。
瞎想5：依据曾自研并上线过吐槽相关功能的电商产品反馈，他们下线吐槽功能，是因为用户在找不到客服的情况下，把吐槽当初问题的反馈问题的场地，遗憾的是当时他们设计时未与OA系统形成关联。因此客户反映的问题在吐槽层面与用户回复页面形成数据断层，客服无法处理的情况下最终只能黯然下线。
以目前看，吐槽的功能在产品层面能实现功能的可用，但是对于需求，基本上还是一个很原始的记录。那么要成为【需求池】里面的需求，以及跟踪调研和上线，这个问题也未实现闭环，是否在增强版内，形成一个简单的OA类流程？
瞎想6：让我觉得更有意思的是，一个吐槽社区的官网最下方，还附上反馈群与联系邮箱。本次活动也是用**群交流，可以建立为一个独立的板块（DEMO2号），针对热点问题进行问答，或者可以在【我们的故事】分拆多一个模块作为公告栏，则版本号更新或者活动的更新则同步更新。
毕竟对于产品而言，产品的升级公告也是刚需，也是可以那么是否可以通过各种手段，再节约人力与效能。期望下次的吐槽活动，能用吐槽产品进行处理~
感谢各位百忙之中阅读，预祝各位新年快乐。
**吐个槽产品测评大赛报名启动，iPhone XR等你来拿！
作者：西蒙书策，人人都是产品经理专栏作家，电商后台产品。
本文为「人人都是产品经理」社区和**吐个槽联合主办的“**吐个槽产品测评大赛”中的三等奖作品，未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
