To B | 运营人的打工手册

岗位职责
市场部网
2020-06-01

前阵子在给团队招人,策划岗还比较明确,到运营岗这块,突然有点拧巴了。当时组里的大佬跟我说,就先对标你的工作来招个运营吧。

“诶?我是运营吗!”我惊讶地叫出声,和大佬面面相觑,他笑了笑,你想是什么就是什么,但运营该做的事你可基本都没落下。

于是我趁着这次机会,大胆地起草下我眼中to b运营(苦逼)人士的“打工手册”。


一、为什么需要运营?


回答这个问题前我也在思考,招募运营的目的是什么,他能解决什么问题?

在我以前接触运营的时候,似乎大多数人都容易把互联网运营等同于市场营销策划、活动运营、用户运营等一系列工作的集合。细数运营的JD要求,有创意、会沟通、懂数据、贴市场是基准,在此之上能有几个不得了的高ROI的市场策划case就更棒了……

这么说来,也难怪不少人都困惑于运营与市场营销之间的关系了。运营究竟走的是产品通道,还是市场通道?从C端运营转到B端运营,究竟哪里不一样了?运营本质上是为了达成什么目的?

那我也尝试着把运营目标定义如下:

运营就是找到需求并通过交换价值提供供给,再逐步扩大规模、站稳脚跟,辅助产品在商业竞争中获胜。

把这话掰开看下:

1、找到需求:产品负责做东西,但究竟这东西值不值得做,做出来后有没有市场,需要运营在前期多琢磨,多接洽前线的需求,做好充足的需求调研和分析,确保该产品值得投入;

2、交换价值:产品做出来后还不够,谁来负责把产品卖给客户?谁去刺激客户的C level明确采购意向?谁去联盟更多的合作伙伴向更多的客户兜售方案?这需要运营拉通销售、售前、项目经理的资源去统筹。

3、提供供给:怎么把产品/方案交付给客户,交付的过程中客户遇到问题了怎么办?运营要严防死守项目交付中可能存在的风险,并及时与内部团队互通有无。

4、扩大规模、站稳脚跟:你的商业模式是什么?有无标准化的产品服务交付体系?是否能发展更多的服务商完成项目交付?整个产品的价值链能否持续地刺激更多客户的青睐?

没错,这些都需要运营,有些得运营去参与,有些是运营来驱动。

而目前大多数运营人都自成一派,C端运营和B端运营似乎泾渭分明、各有章法。究其本质的差别:B端运营的核心在于利益撬动,C端运营更倾向于利益诱导和情感连接。

二者的运营策略和实现手段各有千秋,但有个相同的目标——让用户认可产品或品牌的价值,从而愿意付出对等的交换物来交换使用权。


二、运营误区


搞明白B端运营的目标后,再来看常见的几种运营思路。

1、砸钱搞活动?

品牌包装、市场运营的确重要,但更重要的是,搞市场地推活动营销能掀起多大的水花,这点你要拿捏分寸。在C端运营上,你可以从拉新、促活、回流的用户数上去衡量这波推广亏不亏,但对to b产品而言,你的客户在哪?你要打动的是哪些人?这一招能有多大成效?

注意,你要打动的不是消费者,是客户决策链上的那群人,尤其是C level。

2、运营只要关注产品就好了?

答案是否定的。

似乎一提起运营就有几个热门的岗位,产品运营、活动运营、市场推广……但实际上在B端运营里,大概率是你挂着产品运营的title,但实际上做着远超出产品范畴的运营工作。

懂产品还不够,你要懂行业懂市场,知道怎么二次包装,怎么传递价值;支持客户项目,从LTC到MCR全线拉通;管理生态,从产品到服务的生态搭建;产品商业化,做好销售支持,持续打磨商业模式……

3、有缝就钻,无孔不入?

按前文的说法,运营好像就是在打杂?所有需要临时投入、擦屁股堵枪眼的、或是处于模糊边界的工作,运营都可以掺和一脚?

从我个人的经验来说,这话听起来没毛病,我在前期工作时也确实深受其扰。但现在想来,不管是运营还是策划都注意遵守这个原则,你就会轻松很多。即:搞明白你所负责的产品的业务价值是什么,沿着业务价值创造的关键环节去筹划运营,以小带大,将单点动作不断沉淀为系统化的积累。


三、运营的关键要点


1、运营规划:从赛道出发

在B端运营的工作中,产品和项目从来都是互为反哺、互相成就的。以服务最终客户为目标,从交付项目前产品自身的规划到交付项目时配套的运营支持,全程都需要倾听客户和市场的声音。

1)产品立项前

在产品决定要做什么之前,运营要配合产品做好市场调研和产品分析工作,明确即将规划的产品能力可以覆盖的客户场景。

a. 要不要做:这功能的目标用户是谁?他们是什么样的?没这功能前,他们有什么痛点?有这功能后,能帮到用户解决这个问题吗?市面上是否有其他产品也在做规划?

b. 值不值:产品确定要做这功能后,预计要投入多少资源?投入产出比如何?对于一些没有办法立即决策和量化的点,是否考虑先投入尝试再推演成效?

2)项目的销售和交付支持

当产品完成迭代并交付到项目后,运营的一大任务就是KA项目的销售和交付支持,从售前、售中到售后各环节的关键路径上分别做好把关。

a. 用得怎样:了解客户使用产品的情况,上手是否方便?功能是否足够标准化?是否真正解决了客户前期反馈的需求/问题?如果没有,那还有哪些地方可以优化?

b. 效益如何:有哪些产品能力可以作为产品关键控标点?为推动销售进展还需要布局哪些产品矩阵?为促进更多项目的交付是否还需要更多的产品标准化支持?

3)倾听市场的声音:

一条赛道的开拓,不仅要对内看:懂产品、跟项目,结合这些信息不断去调整你的行动轨迹,打造你的专属赛道;还需要向外看:看行业、看市场,把你的赛道置身于大赛场里,让你时刻知道自己是否偏离路线。

a. 行业趋势:你的产品/方案面向什么市场,属于什么行业领域?行业趋势是否向上?这行业的客户预算吃紧吗,是否能够持续性付费?

b. 对手底牌:了解你的同行吗?它的主打能力和商业模式是什么?客户选择它的原因是什么?你的产品业绩相比同行如何?

立足于以上几点,那么不管产品或项目处在哪个阶段,你都会被拉回原点思考,一些在颅内激荡的想法慢慢冷却下来,你所在的赛道始终是在行业大盘上的,你的团队在主路径上就不会跑偏。

2、运营量化:数据、价值和成本

据我观察,很多产品团队都不太重视项目的运营,辛辛苦苦规划好了功能,组织了一帮人投入需求的迭代建设,好不容易熬到产品封版发行,然后就此落下帷幕。

说出来有点不可思议,但这种情况的确很常见,问及原因,他们给出的解释是:交付项目的事就交给下一棒了,跟我关系不大,下个版本的需求还热乎着呢。

这些团队即便关注了项目,对于项目数据的获取、提炼、总结和分析也只是蜻蜓点水。试想下,如果你无从复盘项目数据的运营情况,那么又从何考量产品研发团队的投入产出呢?

1)数据

a . 项目大盘:累计有多少项目,项目有区域特性或行业特性吗?商机的转化率如何,交付情况怎样,哪些项目交付了哪些产品,产品的授权情况如何……

b. 专项盘点:该项目的用户最喜欢用什么产品、用户的活跃度如何、业务相关数据的变化趋势、从确定商机到签约花了多久时间……

这些都是非常基础的数据,但足够你了解整体项目的情况了。更多运营数据需要结合业务需要去定义。

2)价值

除了关注运营数据之外,你还需要了解产品给客户带来的价值。

不妨试着紧贴项目全生命周期,从售前、售中、售后各环节不断挖掘客户需求,响应客户缺陷,并及时通过从合作伙伴、销售、售前、项目经理等了解客户对产品方案的反馈和评价,转化成定性数据的分析。

3)成本

以我自己为例,在之前运营项目的时候,我们会做好资源成本的把控,了解项目每个环节中的各个角色的时间、人力的投入情况,一来方便梳理服务成本时有据可循,二来在汇报项目时,结合项目成员的资源更能直观地了解投入产出比。

3、运营一个生态位

所有产品都在某个生态系统中生存,你的产品在生态系统里的位置是什么?是正在发展还是正在消亡?基于你的产品发展的生态是丰盛还是贫瘠?这都构筑了你产品的竞争力。

1)产品生态

在对外交付项目前,尝试着去寻求与其他团队的产品合作,建立更为稳固的方案联盟。运营要时刻关注着潜在的合作机会,公司内的、公司外的团队都可能是你的合作目标,你始终要跳出产品本身,检视你的产品的内外部环境是否发生变化,是否可以通过与其他产品的结盟让你的产品发挥更大的价值。

2)服务生态

发展服务合作伙伴,协助产品更快更好地在更多的项目中落地。从服务商的引入、培训、考核、陪同交付、独当一面、奖惩等各个维度入手,运营需要铺设好这条路,确保项目是有人交付的,出问题是有人兜底的。

除了确保人员就位之外,服务本身的标准化也需要运营联合项目经理共同去持续优化,做到服务的标准化、自动化、工具化。

一旦一个动作开始固化和重复,往往意味着它的效果已经变得可测量了。

前文提到,运营的事情的确琐碎、庞杂,看起来似乎都是一个个游离的点,但是你可以将单点动作不断沉淀为成套体系。

同理,在发展服务生态时,重要的不是有多少服务商参与了多少项目,而是你通过搭建服务生态促进了产品的服务标准化进程。

回想下,你的产品标准交付的内容基本上是共通的,除了部分需要交由合作伙伴定制处理,大多数情况下你完全可以在把项目给到服务商交付前,定规范、建标准、立标杆,让服务商能越做越轻松。

3)从LTC到MCR

前面提到你产品所发展的生态土壤,那么在这块土壤上滋生的项目,你要如何去运营呢?

a. Lead to Cash

从管理线索、管理机会点到管理合同执行,整个过程都需要运营配合销售、架构和项目经理共同去完成,具体包括:

  • 管理线索:配合销售和售前架构师收集线索、跟踪商机的培育情况;

  • 管理机会点:辅助架构师验证机会点(方案编写、产品体验、概念验证等),做好标前引导;

  • 管理合同执行:管理PO的合理性,产品和服务的报价是否符合预期,工作说明书是否从时间、资源和范围上明确清楚。

b. Manage Customer Relationship

  • 管理客户信息:组织项目干系人定期同步项目进展、计划、风险和需求,确保团队内部对客户的认识是一致的,也有利于我们对产品整体方向的把握。

  • 制定客户的应对策略:该客户的定级如何,是否要调配更多的资源支持,或是适当抽离一些资源出来。


四、小结


写到这,我也不得不停下来感叹下,B端运营要做的事情可真不少。

叹一口气后再追问下,难道其他岗位的事儿就不多么?也不见得。

不仅是运营,做to B产品,你本身就选择了一条相对不那么轻松的路,很多岗位的工作边界都不够清晰。尤其在中小公司里,一人身兼数职再正常不过,而摆在你眼前最紧迫的需求就是,你要动用你能牵动的所有资源,产品也好、运营也好、项目经理也好,去打造最小版本的产品,验证产品在市场商业化的可行性。

不仅是产品,产品经理也需要打造最小可用版本的自己,投身到瞬息万变的市场里,去试着牢牢地运营你的生态位。


参考文献:

《从零开始做运营:运营人的进化》张亮

《增长思维30讲》 梁宁

作者 | 林壮壮,来源 | 健壮的大姐姐(ID: is_strong)

参与讨论

回到顶部