我们常谈到的互联网运营，多数是针对C端的，B端由于其特殊性很少被人提及。很偶然的机会，我有幸经历了一个互联网支付项目从0到1的过程，今天跟大家分享的用户运营（鉴于To B产品的用户群体大部分是企业，用户运营在本文中更多的是指商户运营，但两者也有共通之处。）经验和心得，也都是泥沼中摸爬滚打总结的。
1、用户沟通，让他们感受到尊重和爽
B端用户偏理性的属性，在产品推广前期，让获客比想象中的难。获客之后，我们需要跟用户进行大量的沟通工作，且不同阶段沟通的要点也不一样的，比如：
- 前期：这个时候的用户通过网站了解到我们的产品，表示出了兴趣，并进行注册。但因为信息不对称的存在，用户依然会表现出疑虑和不稳定性，所以该阶段的沟通侧重挖掘用户真实的诉求，突出自身产品的差异性和优势，抓住用户的心。
- 中期，用户已经认可我们的产品，就要安排双方进行技术上的调试。所以该阶段如何协调技术资源，如何快速响应技术问题，如何抹平用户对产品功能不完善的情绪就很重要了。
后期，用户产品上线后，存在的各类交易问题、系统问题、功能缺陷问题，也需要我们耗时耗力的沟通解决。 - 所有的沟通，我们都是通过QQ、微信或电话进行的。沟通中很多技巧都是建立在双方平等，尤其是对用户的尊敬上，比如口气平和，多用敬语（您、很抱歉……）。通过创造轻松愉悦的交流气氛，能够让用户得到认可和获得归属感，我们产品的价值才得以实现。
截图
2、用专业的知识，说服用户
B端产品有一个很大的特点就是其专业性和复杂度较高，一般人都不太熟悉甚至完全没有概念。用户在使用我们产品的时候，我们更多的是扮演专（砖）家的角色。因为面向企业用户，所以有两类人需要从我们这里获得专业的信息：一类企业决策者（老板或则管理者），负责拍脑袋，；一类技术人员，负责实现产品技术对接。
我们做的支付sdk产品，在面对这两类人的时候也需要表现出不同的专业性。
- 对于决策者而言，他们关心的是：你们的费率为什么这样定价、如何进行资金清结算、每种支付产品有什么区别、业务的支付场景是否合规等业务层面问题。这需要运营通过不断的专业学习，形成支付行业的知识积累。
- 对于技术人员而言，他们关心的是：数据传输的安全性是怎么保障的，签名方式是怎么实现的，前端和后端如何实现接入等技术细节问题。这个有专门技术团队解答，运营也需要简单的了解自家产品的内部技术实现方式。
所以，一旦用户有问题，千万不要急着回答，想清楚这个问题到底是谁提的，问的是什么，疑惑在哪里，他需要怎样的回答来说服自己相信这就是自己要的那款产品。答案和解决方案一定要正确要专业，这也是突出公司和产品形象的机会。如果不小心给错解决方案，也不需要太焦虑，谦虚地承认了错误并重新提供更加专业的方案，也会赢得用户的认可。
通过学习专业知识，来辅助运营工作的开展
3、及时响应和反馈
诺曼在《未来产品的设计》里面讲到，宾馆因为环境嘈杂且坐电梯的人较多，自己即听不见电梯门开关的声音，也看不到指示灯，导致坐错了好几次楼层。这正是反馈机制不完善，带来的后果。反馈告诉我们现在处于什么状态，应该怎么做，没有反馈会让人感觉到焦虑和失去把控。
反馈的重要性
企业用户一方面是理性的，他有耐心等待一个解决问题的答复；另一方面等待是需要时间成本的，用户也希望有一个时间期限。
不要一味地说，等一下，我们在处理这类模糊没有意义的话，除非你可以在短时间内给出答复，否则用户漫长的等待得不到真实的解决，就会变的焦虑和失控。
正确的回答应该是，运营根据实际情况，评估出处理问题的时限，比如：告诉用户我们已经在处理，预计10分钟后可以正常使用／问题会在12点前会等到解决……这样的好处就是用户有一个预期，他能够感觉事情处于自己的控制下，在情感上感到放松。如果临近或超过时限没有给商户反馈怎么办，那就态度谦虚的道个歉，提前或及时(在商户反问我们之前)的通知到用户变化（原因），然后告知后面的方案。
这里的原则就是，我们应该主动去反馈，而不是让用户苦苦等待和烦恼。
4、用户要求的不一定要做
倾听用户诉求，进行需求分析，这活一般都是产品经理干的，但事实上与用户接触最多的还是运营，他们才能获取一手的信息。从某种层面来看，运营完全可以充当用户需求分析的角色，就看运营人有没有这样的自我定位。
我们自己的产品在很多时候，都会碰到商户提出的各种要求，比如：收银台页面要定制化，logo能不能修改，数据传输要更多的加密方式，请求和响应参数需要自定义，需要各种语言的demo……用户的要求不等于真实的需求，就像在诺基亚时代，用户说我们要打字更快的键盘，结果键盘倒是设计成符合人体工学的了，可还是被iPhone打败了。
要求≠需求
运营怎么平衡产品和商户之间的需求，就是一门很重要的艺术了。平衡的前提，就是一定要了解我们产品目前在公司的战略地位，高层重视程度，资源投入的比重，以及目前产品适用的人群占比。如果产品本身战略地位低，意味着资源少，那么商户的需求就要考虑到重点。如果目前产品已经满足80%的商户需求，那么其他合理的需求就应该纳入到后期的产品规划中去，不合理的自然剔除掉。
但有时候迫于某些所谓的内部大客户，我们会优先去满足他们的要求，这样就会无形中占用过多的资源，打乱产品开发的阵脚。比如我们之前的sdk考虑到90%以上的用户需要接入难度低，技术硬件要求低的需求，故只支持app 内签名，缺点就是安全级别比较低。这时候有内部技术实力较强的大客户，提出了异议，需要加强签名安全，我们便立马进行产品修改，最后客户还是横挑鼻子竖挑眼，放弃使用我们的产品。虽然说此类需求是符合我们未来产品的趋势，但前期因为一个客户的要求而消耗的成本也不小。当然这是老板拍的决定，大家只能硬着头皮上。
针对不同的目标用户，如果产品本身确实存在不完善的功能，也要及时反馈给产品，并告诉用户等待我们的新功能。学会适当的画饼，要让用户看到希望和预期，但也要考虑到用户的承受期限。
5、关注20%的核心价值用户
长尾理论，说需求曲线的狭长尾部分布着大量的产品和用户，这里是一座机会的宝库。中国第三方支付发展也确实符合这种理论，银行不愿意涉及的小企业给了第三方支付公司发展的空间。但我们不要忽略了，哪怕是长尾，也逃不开二八定律，就像现在的支付宝和财付通就已经占据了市场70-80%的份额，获取了绝大部分的利润。
运营的工作非常杂乱，而且时间有限，要实现高ROI，就要服务好20%的核心价值用户。我们产品刚推广初期，用户量少，故把每一个用户都当成小心肝一样呵护。尤其是商务或内部同事随手扔一个大客户过来，我们也得接过来好好伺候着。大部分的结果是，好不容易把产品接入了，却一点交易量都没有。
随着业务量的增长，就需要建立用户筛选和分级策略。运营应该快速的判断这个用户：
- 是不是我的目标用户。
- 是否认可我们的产品和服务。
- 对价格是否敏感。
- 是否容易抱怨。
- 预期会带来多大的回报。
- 合作过程是否顺利
- ……
同时根据一些简单具体的规则，比如企业注册资本、背景实力、盈利模式、交易规模、用户数等，来识别核心用户，把更多的资源倾斜在他们身上。要警惕非核心用户，尤其是一些干扰用户，他们可能有无穷的要求和刁难，会不断消耗公司的资源，这类用户必要时要敢于放弃。
当然，产品的每个阶段，对于用户的分类标准都是不一样的，重要的是在实践中不断的迭代和优化。
二八定律
6、数据驱动运营
在越来越重视数据的互联网时代，数据化运营的工作越早开展越好，但不同阶段侧重点会不一样。初期，支付产品没有用户或用户极少的时候，我们更多的是关注品牌传播、网站流量、拉新数据等。等到用户量级上去以后，我们开始重视用户业务层面数据，比如交易数据、交易成功率、失败率、渠道分布等。再过一个量级，用户的活跃度、沉默流失数据也开始关注。
我们最早的数据也就是以日报的形式发出，有系统发的简报，数据组的报告，但他们的数据更偏向说明数据本身，业务方面的分析太少。这个时候运营就需要在已有数据报告的基础上进行优化，加入更多的业务分析，比如网站流量下滑是推广的力度减少，还是品牌传播的疲软，还是竞争对手的崛起，商户交易的减少是流失还是沉默，是业务出了问题还是项目问题等。
其中的一个交易数据模版，学会版本管理
这里需要说明一点，做运营的一定要掌握很强的数据分析工具吗？我的理解是，在公司有专门的数据组存在时，运营只需要具备数据敏感性和思维即可，让更加专业的数据组处理海量的数据。专业的人做专业的事，他们可以在几分钟内处理完你可能需要几个小时处理的数据。
有了数据和分析，我们就要呈现给相关团队看，可以用Excel表格，Word或PPT展现，工具不重要，重要的是展现的内容要有价值。有价值可以参考：领导和同事时间都很宝贵，报告要简洁突出重点，告诉他们我们做了什么，有什么成就，有什么问题，我们未来的方向。
数据运营
最后
其实运营的很多东西都是老生常谈，要快速地成长，最快的捷径就是一个字：干！
网友评论