用户运营的几点套路,你都知道吗?

目录

我们常谈到的互联网运营,多数是针对C端的,B端由于其特殊性很少被人提及。

很偶然的机会,我有幸经历了一个互联网支付项目从0到1的过程,今天跟大家分享的用户运营(鉴于To B产品的用户群体大部分是企业,用户运营在本文中更多的是指商户运营,但两者也有共通之处)经验和心得,也都是泥沼中摸爬滚打总结的。

       用户沟通,让他们感受到尊重和爽

B端用户偏理性的属性,在产品推广前期,让获客比想象中的难。获客之后,我们需要跟用户进行大量的沟通工作,且不同阶段沟通的要点也不一样的,比如:

前期:这个时候的用户通过网站了解到我们的产品,表示出了兴趣,并进行注册。但因为信息不对称的存在,用户依然会表现出疑虑和不稳定性,所以该阶段的沟通侧重挖掘用户真实的诉求,突出自身产品的差异性和优势,抓住用户的心。

中期:用户已经认可我们的产品,就要安排双方进行技术上的调试。所以该阶段如何协调技术资源,如何快速响应技术问题,如何抹平用户对产品功能不完善的情绪就很重要了。

后期:用户产品上线后,存在的各类交易问题、系统问题、功能缺陷问题,也需要我们耗时耗力的沟通解决。

所有的沟通,我们都是通过QQ、微信或电话进行的。沟通中很多技巧都是建立在双方平等,尤其是对用户的尊敬上,比如口气平和,多用敬语(您、很抱歉……)。通过创造轻松愉悦的交流气氛,能够让用户得到认可和获得归属感,我们产品的价值才得以实现。

       用专业的知识,说服用户

B端产品有一个很大的特点就是其专业性和复杂度较高,一般人都不太熟悉甚至完全没有概念。用户在使用我们产品的时候,我们更多的是扮演专(砖)家的角色。

因为面向企业用户,所以有两类人需要从我们这里获得专业的信息:一类企业决策者(老板或则管理者),负责拍脑袋;一类技术人员,负责实现产品技术对接。

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

对于决策者而言,他们关心的是:你们的费率为什么这样定价、如何进行资金清结算、每种支付产品有什么区别、业务的支付场景是否合规等业务层面问题。这需要运营通过不断的专业学习,形成支付行业的知识积累。

对于技术人员而言,他们关心的是:数据传输的安全性是怎么保障的,签名方式是怎么实现的,前端和后端如何实现接入等技术细节问题。这个有专门技术团队解答,运营也需要简单的了解自家产品的内部技术实现方式。

所以,一旦用户有问题,千万不要急着回答,想清楚这个问题到底是谁提的,问的是什么,疑惑在哪里,他需要怎样的回答来说服自己相信这就是自己要的那款产品。

答案和解决方案一定要正确要专业,这也是突出公司和产品形象的机会。

如果不小心给错解决方案,也不需要太焦虑,谦虚地承认了错误并重新提供更加专业的方案,也会赢得用户的认可。

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

       及时响应和反馈

诺曼在《未来产品的设计》里面讲到:

宾馆因为环境嘈杂且坐电梯的人较多,自己即听不见电梯门开关的声音,也看不到指示灯,导致坐错了好几次楼层。

这正是反馈机制不完善,带来的后果。反馈告诉我们现在处于什么状态,应该怎么做,没有反馈会让人感觉到焦虑和失去把控。

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

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

正确的回答应该是:运营根据实际情况,评估出处理问题的时限。比如:告诉用户我们已经在处理,预计10分钟后可以正常使用/问题会在12点前会等到解决……这样的好处就是用户有一个预期,他能够感觉事情处于自己的控制下,在情感上感到放松。

如果临近或超过时限没有给商户反馈怎么办?那就态度谦虚的道个歉,提前或及时(在商户反问我们之前)的通知到用户变化(原因),然后告知后面的方案。

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

       用户要求的不一定要做

倾听用户诉求,进行需求分析,这活一般都是产品经理干的,但事实上与用户接触最多的还是运营,他们才能获取一手的信息。

从某种层面来看,运营完全可以充当用户需求分析的角色,就看运营人有没有这样的自我定位。

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

用户的要求不等于真实的需求,就像在诺基亚时代,用户说我们要打字更快的键盘,结果键盘倒是设计成符合人体工学的了,可还是被iPhone打败了。

运营怎么平衡产品和商户之间的需求,就是一门很重要的艺术了。平衡的前提,就是一定要了解我们产品目前在公司的战略地位,高层重视程度,资源投入的比重,以及目前产品适用的人群占比。

如果产品本身战略地位低,意味着资源少,那么商户的需求就要考虑到重点。如果目前产品已经满足80%的商户需求,那么其他合理的需求就应该纳入到后期的产品规划中去,不合理的自然剔除掉。

但有时候迫于某些所谓的内部大客户,我们会优先去满足他们的要求,这样就会无形中占用过多的资源,打乱产品开发的阵脚。

比如:

我们之前的SDK考虑到90%以上的用户需要接入难度低,技术硬件要求低的需求,故只支持APP内签名,缺点就是安全级别比较低。

这时候有内部技术实力较强的大客户,提出了异议,需要加强签名安全,我们便立马进行产品修改,最后客户还是横挑鼻子竖挑眼,放弃使用我们的产品。

虽然说此类需求是符合我们未来产品的趋势,但前期因为一个客户的要求而消耗的成本也不小。当然这是老板拍的决定,大家只能硬着头皮上。

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

       关注20%的核心价值用户

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

但我们不要忽略了:哪怕是长尾,也逃不开二八定律。就像现在的支付宝和财付通就已经占据了市场70-80%的份额,获取了绝大部分的利润。

运营的工作非常杂乱,而且时间有限,要实现高ROI,就要服务好20%的核心价值用户。我们产品刚推广初期,用户量少,故把每一个用户都当成小心肝一样呵护。

尤其是商务或内部同事随手扔一个大客户过来,我们也得接过来好好伺候着。大部分的结果是,好不容易把产品接入了,却一点交易量都没有。

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

是不是我的目标用户。

是否认可我们的产品和服务。

对价格是否敏感。

是否容易抱怨。

预期会带来多大的回报。

合作过程是否顺利。

同时根据一些简单具体的规则,比如企业注册资本、背景实力、盈利模式、交易规模、用户数等,来识别核心用户,把更多的资源倾斜在他们身上。

要警惕非核心用户,尤其是一些干扰用户,他们可能有无穷的要求和刁难,会不断消耗公司的资源,这类用户必要时要敢于放弃。

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

       数据驱动运营

在越来越重视数据的互联网时代,数据化运营的工作越早开展越好,但不同阶段侧重点会不一样:

初期,支付产品没有用户或用户极少的时候,我们更多的是关注品牌传播、网站流量、拉新数据等。

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

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

我们最早的数据也就是以日报的形式发出,有系统发的简报,数据组的报告,但他们的数据更偏向说明数据本身,业务方面的分析太少。

这个时候运营就需要在已有数据报告的基础上进行优化,加入更多的业务分析,比如网站流量下滑是推广的力度减少,还是品牌传播的疲软,还是竞争对手的崛起,商户交易的减少是流失还是沉默,是业务出了问题还是项目问题等。

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

这里需要说明一点,做运营的一定要掌握很强的数据分析工具吗?我的理解是,在公司有专门的数据组存在时,运营只需要具备数据敏感性和思维即可,让更加专业的数据组处理海量的数据。

专业的人做专业的事,他们可以在几分钟内处理完你可能需要几个小时处理的数据。

有了数据和分析,我们就要呈现给相关团队看,可以用Excel表格,Word或PPT展现,工具不重要,重要的是展现的内容要有价值。

有价值可以参考:领导和同事时间都很宝贵,报告要简洁突出重点,告诉他们我们做了什么,有什么成就,有什么问题,我们未来的方向。

大佬分享的公式:谷歌SEO = 高质量内容 + 优质外链 + 技术端优化+用户交互行为

当你使用我的 推荐链接 购买产品时,我会赚取佣金并感谢你对我辛苦写文章的认可。

欢迎订阅本站深度内容:
◇万字长文
◇每1-3月出一篇
◇深度测评工具
◇网站案例研究

留下第一个评论