【彭斌说】“产品思维”和“业务思维”浅析，及售后服务标准 ...

客户成功经理在一家SaaS企业究竟担任着怎样的角色？该如何去做客户运营？又该具备哪些能力和呢？本文作者从“产品思维” 和“业务思维”这两个方面，分享了他的看法，一起来看一下吧。

客户成功经理在一家SaaS企业究竟担任着怎样的角色？该如何去做客户运营？又该具备哪些能力和思维？这是笔者初入SaaS行业一直在思考的问题。

这篇文章，笔者想先简单聊聊“产品思维”和“业务思维”。

在聊为什么之前，笔者想先解释自己关于“产品思维”和“业务思维”的看法。

产品思维：在已有的软件或者系统的功能上，按照产品设计的逻辑和去帮客户解决问题；

业务思维：在已有的软件或者系统的功能上，按照客户实际线下场景，以最贴合客户业务流程、客户最能理解的方式去解决问题。

在达成定义上的共识之后，我们接着聊一聊为什么客户成功经理需要同时具备“产品思维”和“业务思维”。

1. 岗位重要日常工作之一——跨部门沟通

客户成功经理，向下对接线下的销售同事，向上对接产研团队，并且日常还要和客户保持紧密的沟通。面对不同的部门和个体，则需要以不同的思维去沟通和对接。

在和产研部门讨论时，客户成功经理需要带着“业务思维”去讨论。我们要告诉产研部门，这个需求的线下业务场景、现在客户的使用体验、遇到的问题、需求要如何实现才能让客户更好理解和使用。

而在与销售、客户沟通时，客户成功经理则需要带着“产品思维”。首先尽快明晰业务场景，了解他们真正的问题或者需求，进而做出初次的过滤。因为有些需求，的确很难去实现，即使做出来，“使用率”也是可预见的少。

2. 两种思维解决问题的优劣势

其实不管是“产品思维”还是“业务思维”，本意都是为了解决客户问题。但在实际运用的过程中，还是会发现很多本质上的区别：

①产品思维：按照产品设计的最优路径去解决问题。

优势在于不太可能触发产品的隐藏BUG，极大程度上保证了客户业务、的准确性。但劣势也很明显，就是很多时候，客户无法理解这种解决思路。

我们不得不承认，在做产品设计的过程中，很多时候，往往是以结果为导向的，从而极大地弱化了客户体验。

②业务思维：按照客户最能理解的路径去解决问题。

优势在于客户最能够理解，因为与实际业务流程是贴合的。但劣势在于没有按照产品正常的设计流程，可能在操作上更繁琐，甚至有时候会触发产品的隐藏BUG，从而影响客户已上线的数据准确性。

尤其是SaaS的产品，往往是“去定制化”的，因为客户不规范的操作，测试出了产品的隐藏BUG。

二、如何将“产品思维”和“业务思维”有效结合

分享一个笔者真实的案例：

目前笔者所在的公司，主要是做农批SaaS收银记账系统的。说得通俗一点，就是给全国大型一二批农产品批发的商户，实现传统手工账到线上数字化的转型。

当时遇到客户的问题，线下的场景是A操作和B操作同时进行。但是，我们产品因为一些条件的限制，无法同时实现A、B两个操作。

这个时候，我第一反应是通过“产品思维”去解决客户问题。首先去思考客户线下场景的合理性、目前产品设计的合理性，最后还是给不出一个好的解决方法。

突然一个业务同事过来，告诉我，A和B操作虽然在线下是同时进行的，但是可以分开操作，并且不会对线上的数据产生影响。

这个业务同事对于我们产品的了解不一定有我深，但是他这次的提醒让我迅速解决了客户的问题。后来我专门复盘过这个案例，的确在当时，我的确会更倾向用“产品思维”去解决客户问题。

所以，后面如果我处理问题，我会优先用“业务思维”尽快给出解决方案，然后再用“产品思维”简单和客户解释出现这个问题的原因。

三、哪类客户可以适当沟通产品设计的逻辑

其实，很多客户的心态就是希望自己的问题能够尽快被解决，对于产品的设计逻辑、操作带来的影响并不在意。

所以，对于哪类客户可以适当的沟通产品设计的逻辑呢？因为一旦客户愿意去和你讨论这类问题，那么至少可以说明两个问题：

客户已经认可你的产品，或者认可你这个人了；

客户已经真正参与到产品的设计中来了。用文艺一点的说法，客户开始参与到产品的长大中来了。

1.信息化接受程度高

信息化接受程度的高低，与年龄的相关性并不高。

判断客户的信息化接受程度是否较高，可以从产品使用深度、需求和新功能反馈上体现。对于这类客户，是推动市场深耕、甚至推动整个行业的燎原星火。

在平时的沟通互动中，除了日常的售后问题，适当和客户讨论产品的设计，会让客户更有参与感、亲切感，甚至从侧面产生较高的粘性。

2. 产品功能使用较深

只有客户深度使用，才会有更多地的互动和诉求（即需求）。

这类客户可能信息化接受程度不高（因为环境、教育程度或者其他因素），但他们至少是认可系统功能价值的，我们全流程教学了，他们也愿意去使用起来。

对于这类客户，我们在沟通的过程中，尽量多做线下业务调研、少讲产品设计逻辑。

因为这类客户功能使用相对较深，对于线下的流程，他们都尽量搬到线上系统上管理了，所以对剩下档口线下的其他业务或流程，他们至少是愿意去线上化的。所以多了解这类客户的线下业务场景，多做调研，每次迭代更新的功能，是贴合、有用的。

至于产品的设计逻辑，讲得不必太多太深。既然产品功能使用的比较深，至少说明客户是认可我们的设计模式和逻辑。对于这类客户而言，更在意的是产品使用体验。

3. 互动频繁

愿意互动的客户，是最可贵的。

愿意互动，代表着愿意了解、学习、反馈和推动。这类客户，可能使用的不深，甚至都没有使用，但因为某个人或者某件事，他愿意和我们互动沟通。

如果正确去做引导，完全有可以朝着“产品功能使用较深”这类客户发展。

适当与这类客户进行调研和设计逻辑沟通，客户会觉得被认可。如果到最后，哪怕真的因为某些主客观原因没有使用系统或者没有深度使用系统，至少在口碑上，这类客户会起到一定的正向作用。

四、如何应用到日常的售后服务

最后总结一下，如何相对标准化的去做好售后服务？

对于目前我所在的公司而言，整体的流程应该是“及时响应——明晰问题——输出方案——解决问题——其他输出”。

前4part其实是一个标准的流程，目前我们也是按照这么一个流程去推进的，但对于“其他输出”上，做的还不够。

我认为的“其他输出”，包括但不限于“问题为什么产生”、“为什么是这种解决方案”（因为我们很多解决方案是比较蹩脚的）、“后面如何避免这类问题的再次发生”……

对于售后服务标准化，可以理解为解决问题思维的标准化。在这条主线明晰的前提下，把握好处理问题的口吻和态度。在相对标准化的框架下，再去弹性执行，在工作中，做到外方内圆。方是规则、圆是变通！（本来源于网络，编者略有改动，如有侵权，请及时通知删除。）