泥沼中摸爬滚打：我总结的To B用户运营的6点套路

我们常谈到的

互联网运营，多数是针对c端的，b端由于其特殊性很少被人提及。

很偶然的机会，我有幸经历了一个互联网支付项目从0到1的过程，今天跟大家分享的

用户运营（鉴于tob产品的用户群体大部分是企业，用户

运营

在本文中更多的是指商户运营，但两者也有共通之处）经验和心得，也都是泥沼中摸爬滚打总结的。

b端用户偏理性的属性，在产品

推广

前期，让获客比想象中的难。获客之后，我们需要跟用户进行大量的沟通工作，且不同阶段沟通的要点也不一样的，比如：

所有的沟通，我们都是通过qq、微信

或电话进行的。沟通中很多技巧都是建立在双方平等，尤其是对用户的尊敬上，比如口气平和，多用敬语（您、很抱歉……）。通过创造轻松愉悦的交流气氛，能够让用户

得到

认可和获得归属感，我们产品的价值才得以实现。

b端产品有一个很大的特点就是其专业性和复杂度较高，一般人都不太熟悉甚至完全没有概念。用户在使用我们产品的时候，我们更多的是扮演专（砖）家的角色。因为面向企业用户，所以有两类人需要从我们这里获得专业的信息：一类企业决策者（老板或则管理者），负责拍脑袋，；一类技术人员，负责实现产品技术对接。

我们做的支付sdk产品，在面对这两类人的时候也需要表现出不同的专业性。

所以，一旦用户有问题，千万不要急着回答，想清楚这个问题到底是谁提的，问的是什么，疑惑在哪里，他需要怎样的回答来说服自己相信这就是自己要的那款产品。答案和解决方案一定要正确要专业，这也是突出公司和产品形象的机会。如果不小心给错解决方案，也不需要太焦虑，谦虚地承认了错误并重新提供更加专业的方案，也会赢得用户的认可。

通过学习专业知识，来辅助运营工作的开展

诺曼在《未来产品的设计》里面讲到，宾馆因为环境嘈杂且坐电梯的人较多，自己即听不见电梯门开关的声音，也看不到指示灯，导致坐错了好几次楼层。这正是反馈机制不完善，带来的后果。反馈告诉我们现在处于什么状态，应该怎么做，没有反馈会让人感觉到焦虑和失去把控。

企业用户一方面是理性的，他有耐心等待一个解决问题的答复；另一方面等待是需要时间成本的，用户也希望有一个时间期限。

不要一味地说，等一下，我们在处理这类模糊没有意义的话，除非你可以在短时间内给出答复，否则用户漫长的等待得不到真实的解决，就会变的焦虑和失控。

正确的回答应该是，运营根据实际情况，评估出处理问题的时限，比如：告诉用户我们已经在处理，预计10分钟后可以正常使用／问题会在12点前会等到解决……这样的好处就是用户有一个预期，他能够感觉事情处于自己的控制下，在情感上感到放松。如果临近或超过时限没有给商户反馈怎么办，那就态度谦虚的道个歉，提前或及时(在商户反问我们之前)的通知到用户变化（原因），然后告知后面的方案。

这里的原则就是，我们应该主动去反馈，而不是让用户苦苦等待和烦恼。

倾听用户诉求，进行需求分析，这活一般都是

产品经理

干的，但事实上与用户接触最多的还是运营，他们才能获取一手的信息。从某种层面来看，运营完全可以充当用户需求分析的角色，就看运营人有没有这样的自我定位。

我们自己的产品在很多时候，都会碰到商户提出的各种要求，比如：收银台页面要定制化，logo能不能修改，数据传输要更多的加密方式，请求和响应参数需要自定义，需要各种语言的demo……用户的要求不等于真实的需求，就像在

诺基亚

时代，用户说我们要打字更快的键盘，结果键盘倒是设计成符合人体工学的了，可还是被iphone打败了。

运营怎么平衡产品和商户之间的需求，就是一门很重要的艺术了。平衡的前提，就是一定要了解我们产品目前在公司的战略地位，高层重视程度，资源投入的比重，以及目前产品适用的人群占比。如果产品本身战略地位低，意味着资源少，那么商户的需求就要考虑到重点。如果目前产品已经满足80%的商户需求，那么其他合理的需求就应该纳入到后期的产品规划中去，不合理的自然剔除掉。

但有时候迫于某些所谓的内部大客户，我们会优先去满足他们的要求，这样就会无形中占用过多的资源，打乱产品开发的阵脚。比如我们之前的sdk考虑到90%以上的用户需要接入难度低，技术硬件要求低的需求，故只支持app内签名，缺点就是安全级别比较低。这时候有内部技术实力较强的大客户，提出了异议，需要加强签名安全，我们便立马进行产品修改，最后客户还是横挑鼻子竖挑眼，放弃使用我们的产品。虽然说此类需求是符合我们未来产品的趋势，但前期因为一个客户的要求而消耗的成本也不小。当然这是老板拍的决定，大家只能硬着头皮上。

针对不同的

目标用户，如果产品本身确实存在不完善的功能，也要及时反馈给产品，并告诉用户等待我们的新功能。学会适当的画饼，要让用户看到希望和预期，但也要考虑到用户的承受期限。

长尾理论，说需求曲线的狭长尾部分布着大量的产品和用户，这里是一座机会的宝库。中国第三方支付发展也确实符合这种理论，银行不愿意涉及的小企业给了第三方支付公司发展的空间。但我们不要忽略了，哪怕是长尾，也逃不开

二八定律，就像现在的

支付宝

和财付通就已经占据了市场70-80%的份额，获取了绝大部分的利润。

运营的工作非常杂乱，而且时间有限，要实现高roi，就要服务好20%的核心价值用户。我们产品刚推广初期，用户量少，故把每一个用户都当成小心肝一样呵护。尤其是商务或内部同事随手扔一个大客户过来，我们也得接过来好好伺候着。大部分的结果是，好不容易把产品接入了，却一点交易量都没有。

随着业务量的增长，就需要建立用户筛选和分级策略。运营应该快速的判断这个用户：……

同时根据一些简单具体的规则，比如企业注册资本、背景实力、盈利模式、交易规模、用户数等，来识别核心用户，把更多的资源倾斜在他们身上。要警惕非核心用户，尤其是一些干扰用户，他们可能有无穷的要求和刁难，会不断消耗公司的资源，这类用户必要时要敢于放弃。

当然，产品的每个阶段，对于用户的分类标准都是不一样的，重要的是在实践中不断的迭代和优化。

在越来越重视数据的互联网时代，数据化运营的工作越早开展越好，但不同阶段侧重点会不一样。初期，支付产品没有用户或用户极少的时候，我们更多的是关注品牌传播、网站

流量、拉新

数据等。等到用户量级上去以后，我们开始重视用户业务层面数据，比如交易数据、交易成功率、失败率、渠道

分布等。再过一个量级，用户的活跃度、沉默流失数据也开始关注。

我们最早的数据也就是以日报的形式发出，有系统发的简报，数据组的报告，但他们的数据更偏向说明数据本身，业务方面的分析太少。这个时候运营就需要在已有

数据报告

的基础上进行优化，加入更多的业务分析，比如网站流量下滑是推广的力度减少，还是品牌传播的疲软，还是竞争对手的崛起，商户交易的减少是流失还是沉默，是业务出了问题还是项目问题等。

其中的一个交易数据模版，学会版本管理

这里需要说明一点，做运营的一定要掌握很强的

数据分析

工具

吗？我的理解是，在公司有专门的数据组存在时，运营只需要具备数据敏感性和思维即可，让更加专业的数据组处理海量的数据。专业的人做专业的事，他们可以在几分钟内处理完你可能需要几个小时处理的数据。

有了数据和分析，我们就要呈现给相关团队看，可以用excel表格，word或ppt展现，工具不重要，重要的是展现的内容要有价值。有价值可以参考：领导和同事时间都很宝贵，报告要简洁突出重点，告诉他们我们做了什么，有什么成就，有什么问题，我们未来的方向。