本文是作者根据自己实际工作的一个复盘总结，谈谈要如何才能构建一个合理的B端运营体系？

躲不掉的运营坑

笔者曾负责过某云平台IAAS云服务的产品及运营工作，很幸运得利于同一集团关系的原因，在云服务推广过程中，轻易的获取了几百家B端公司的云服务市场。通过产品及技术，构建一个云服务平台，承接了这几百家企业的业务。

另外，也根据业务的发展开发了一个运营平台，可以支持合同、订单、结算、活动促销等日常的工作。但是初期缺少专职的运营人员来负责运营工作，都大家轮流兼职处理日常工作，有时是产品、有时是研发、甚至有时是运维来弄，大家都觉得这些是运营的事自己做的也不专业，那么我们就是招一个“运营人员”吧。

于是，我们就从互联网型公司招聘了若干专业的运营人员过来负责运营工作。面试时应聘人员给我们灌输了互联网流行的运营理念及做法，让我们自惭形秽，我们也认真听取了这些应聘者的专业经验后，开始了各种PRD、朋友圈各种秀、组织了各种高逼格的活动、接触各种行业大咖、参加各类行业评比等，大家也忙得不亦乐乎，仿佛自己也快是行业大牛，领导对我们的工作也大加赞赏。

忙了大半年后，大家才缓过神来，新来的运营人还没有把原来大家原来认为是运营的工作给承接起来呢。我们去找的运营新同事沟通这些合同、订单及结算工作时，我们新同事犹如看怪我一样看着说这些工作不归属运营啊。

啊，这下轮到我懵了，那这些工作不是运营是什么呢？

当然，我并没有贬低我们这些运营的同事，他们的工作能力、人脉资源、媒体资源，我是非常钦佩的，他们让我们接触到了更加广阔的人和事，视野也开阔了不少，但是我们原来希望专职的工作还是没有人负责。

另外，更加严重的问题是，这些新的、轰轰烈烈的运营工作，并没有给我们营收带来实际性的影响，客户还是原来那些客户，各种PRD传播、行业大会等新运营花费不少，但是却没有给我们带来新的客户、新的市场，订单还是按照原来的速度在缓慢增长，甚至出现了负增长的情况。

从现在看来其实就是C端和B端运营存在的差异，最后没有办法只能招聘应届毕业开始培训产品并摸索进行B端运营工作，这个过程中碰到很多坑，好多至今也没有完全解决好。

最近，笔者由于各种原因又回来原来岗位继续产品及运营的工作，也被迫继续思考如何构建一个合理的B端运营体系的问题。

不同的运营类型分析

在开始讲B端运营之前，我们从企业类型来区分一下C端运营型公司、B端运营型公司、B端销售型公司。

运营在国内是随着C端类型互联网的快速发展，而逐渐受到人们认识和重视的。面对C端的运营工作也有的理论指导，常见比如AARRR模型、漏斗模型、RFM模型、痛点路径模型等等，就连运营职位也分得很细，比如：

• 内容运营类岗位：有社区运营、热点运营、H5/短视频运营、新媒体运营等。
• 活动运营类岗位：有平台活动运营、商务活动运营等。
• 用户运营类岗位：有粉丝运营、KOL运营、流量运营、客户增长运营等。
• 产品运营类岗位：有资源配置运营、数据运营、APP运营等。

这4种经典的运营工作，都有不同的侧重点：

• 内容运营：重点关注内容数量、内容浏览量、内容互动量、内容传播数等。
• 用户运营：关注用户的拉新、活跃、存留等，如拉新就要考虑用户从那里来，比如朋友圈、抖音、微博、豆瓣、广告、下线地推、现有用户推广等。
• 活动运营： 各种活动及达成的效果。线下活动就要考虑活动的规格、参加的大咖、活动的影响力及媒体传播等；线上平台活动如电商18促销活动，就要考虑访问量、成交量等。
• 产品运营：某个产品的运营。产品运营相对要求就更加全面，首先最起码的要求就是保证产品能够生存下来，那么运营就要关注产品的功能、用户量、PV、UV、IP等。

C端运营的日常工作，更像是短期的项目式工作，每项运营工作都是一个具体任务，有明确的任务目标或者PKI、有明确的工作时间计划等，常见的运营工作流程如下：

C端运营：负责创造短期用户+协助产品完善长期价值  

而在B端销售型公司中，没有运营体系的概念，可能以市场部的形成存在，工作职能更多是公司品牌及影响力的打造，常见也是一些商务活动及非专业的内容运营，比如年终的客户答谢会、自运营的公司公众号等等。

那么B端运营工作又有什么不同，需要构建怎样的运营体系及核心运营工作流程呢？

有关这方面的材料真的很少，大家都是从某一个或几个角度来讨论，缺少一个成体系的东西可以参考。在上面我们提过几个典型的B端运营公司，我们可以从组织架构入手，笔者手头也缺少相关材料，但是我们可以从其招聘岗位入手，窥探其组织架构的组成。

典型B端运营公司岗位分析

salesforce

AWS

阿里云

从这三家公司的招聘岗位中，我们看到销售是三家需要销售，运营都没有过于凸显，但是由于资产是属于企业本身的，客户只是租赁使用，在资源协调、服务提供、企业认证、账户管理、费用结算等方面的工作都是需要运营专职处理的，比如AWS 账单中心、阿里云的运营中心。

Salesforce是非常注重销售的一家公司，其建立了一支世界级的销售团队，在从免费到付费过程中有销售的介入来转化；在从小客户到大客户的重心转变，也需要销售，因为在企业级市场，尤其是大型企业，面对面谈单对促成交易十分重要。至今，Salesforce的收入中超一半来自大型公司，剩下部分由中小公司贡献，但是大公司的续费意愿是很强的。

亚马逊官方披露的信息表明，AWS的云服务业务已经逐渐成熟，从面向小型初创企业的现用现收（pay-as-you-go）服务发展成为了面向企业客户的多年合同模式。这样中业务转变使得AWS需要销售、解决方案case by case 对大客户进行服务和关系维护，运营更多的精力在于账单结算、企业账户管理方面。

阿里是强运营型企业，在C端及小B端的运营都做很好，但是现在阿里云在面对大公司及政府时，是无法通过纯碎的运营手段来获取的，更多需要销售及解决方案的介入才行。这是也是为什么，阿里云开始大规模招聘传统软件行业的销售和解决方案人员。

苦逼B端运营工作的复盘和思考

笔者从客户、合同、订单、产品、售后、渠道、采购、营收及活动等多个方面对运营工作进行一个复盘和思考。

1. 客户部分

客户，即客户管理。 与C端运营直接面对具体化的、人性化的用户不同，B端运营面对的是具有组织性质的客户管理，通俗一点就是C端运营面对个人用户、B端运营面对企业客户。

C端运营一般围绕拉新、促活、留存等来开展用户运营工作。传统的软件厂家或者行业解决方案商是销售Case By Case 的进行客户拓展、签单及关系维护，常常通过CRM这样的软件来进行客户关系管理。

B端运营中，大B端客户，一般都需要销售介入才能更加容易达成交易。此时，运营的工作更像一个销售助理的工作，协助销售帮忙客户进行账户注册、客户类型识别、认证、订单规模成本收益测算等，但与大B客户关系还是依靠销售一对一进行维护。

小B端客户可以通过运营、渠道或者市场的手段获取，交易依靠运营手段促成（比如免费体验、限期抵用卷等等），关系维护也是通过运营1：N进行维护，常需要对应的运营平台协助进行线上关系维护。这些小B如果采用大B的销售维护关系模式的话，公司的销售成本会急剧增长。另外，运营要及时发现快速成长的小B客户，以便销售尽早介入，以提高此类潜在成为大B客户的忠诚度和满意度。

后续，客户的价值管理、满意度、忠诚度、客户行为等都需要运营进行分析，对于大B客户需要及时把异常情况告知销售。

客户运营工作如下图：

总结，我们在客户运营这块基本是缺失和错位的：

（1）缺少销售及售前，原来的大B客户都通同一集团关联关系获取的，公司并不认可在这些客户上需要销售的投入，并给予销售佣金。虽然这些客户资源的获取我们并不需要销售，但是实际各个公司和我们之间是相互独立的法人，公司间基本按照正常的市场化操作进行交易的，包括合同、交易、结算等都是市场化的行为，销售的缺少，使得合同工作、结算工作很少能够按照计划时间完成。

另外，客户也常常提出需要专业的架构师或者解决方案工程师帮忙解决上云过程的问题，而我们这些刚刚毕业的运营同事只能作为传话筒，把工作任务实际是丢给了研发或运维的同事，客户的售前服务工作质量可想而知。

（2）运营工作的错位，前面也说过，我们前期的运营工作是实际上是C端模式的，这些运营手段可以适当提高公司产品的曝光度，但是很难吸引理性考虑的B端客户的兴趣和行动。

在缺少销售的情况下，平台初期的B端客户一般都需要生态关联或渠道才能获取，而且基本上都是小B客户。比如：阿里云的电商生态初期就能吸引众多生态内的小B客户的加入，我们也是通过与创业园区的渠道合作才获取了第一批外部的小B端客户，虽然质量也不是很高，但是在这块我们已经摸索着走对了方向。只可惜的是由于产品质量、产品服务成本及公司经营策略改变等多方面的原因，也没有很好把这批用户发展起来。

（3）后续的客户关系维护、客户价值分析之类更是没有了，这些基本客户管理工作的缺失，使得我们服务很难向关联关系之外的大B端客户推行。

2. 合同部分

与C端运营不同的是，由于产品及服务涉及金额较大，而且是长期合作模式，一般都需要签订合同，作为双方权利及义务的保障。另外，合同也是双方进行后续服务提供、费用结算的基本依据。

和传统软件销售合同不同的是，运营型合同一般都框架性合同，需要约定好服务或者租赁年限、结算周期、产品折扣、服务目录等核心内容，具体费用又客户订单购买的产品和服务形成，并最终形成账单结算。

大B客户合同签订和续签，需要销售一对一的跟踪和推行，这些客户一般都是业务收入主要来源，像笔者所负责的业务，Top 10的客户，已经占据55%的营收比例。如果这些大B客户合同的签订和续签推进不力，给后续的财务结算工作带来较大的阻碍，对业务收入及现金回款造成了不利的应用。另外，大B客户一般都有自己的合规流程，合同基本都是线下签订和续签的。

小B客户合同签订和续签，一般由运营人员负责，线上线下皆可，流程相对快捷。

在合同审核环节，运营需要根据运营成本情况、客户回款情况、现有服务目录等对合同的服务周期、产品折扣、服务目录等进行审核。

如下图：

总结，我们在合同运营这块存在的问题：

没有专职的销售，基本都是运营人员在推进合同签订及续签，这些身兼数职的运营人员在推进大B客户的合同，基本都是延期完成的。运营人员没有佣金激励、缺失合同谈判能力、缺失客户高层关系维护、难以各个击破客户内部的阻碍（比如技术部不认可我们产品、采购部有自己的渠道、财务部严格控制预算等等），这些需要专业销售推进的工作，直接给到运营人员，就是赶鸭子上架——强人所难。

在运营过程中，我们和客户哪怕是同一集团的关联关系，但由于双方都是独立市场主体，业务推进过程中，我们也常常碰到外部的竞争对手，也丢失部分核心的客户。

3. 订单部分

订单日常工作基本都是由系统平台自动完成，基本不需要运营过多参与。运营主要是跟踪订单数据，并根据订单数据调整产品策略、测算业务收入、做采购计划、做资源补充计划、做客户回访等等。

这块我们有自己的运营平台，运营人员也容易进行分析和监控，订单部分的工作，我们基本没有大问题。

4. 产品部分

在B端，产品定价是运营最为重要的工作之一，运营负责平台的整体业务收入，成本管理、采购计划等，运营人员要清楚产品固定成本及变动成本，能够测算产品的盈亏平衡点，最后根据盈亏平衡点和外部竞争对手的市场价格，来进行最终的产品定价。

其他的产品运营工作，个人认为，可以参考C端的产品运营模型，运营需要熟悉产品的功能、用户使用情况、产品使用反馈、某个新产品推广、产品生命周期管理等。当然，这块更多还是产品经理来负责。

这块说来惭愧，由于经营成本、研发力量、资源规模等多方面的原因，我们也只是提供了IAAS服务中，最为常见的云服务器、负载均衡、弹性伸缩、VPC、云硬盘、EIP等等约20多种产品服务，和业内领跑者在数百种的产品相比，在产品丰富度、价格、性能、易用性等方面还是存在相当的差距。

最好的产品策略应该是，根据自身的企业经营情况，进行精细化运营，不能追求大而全的产品运营，以保证产品的功能、性能、易用性等，并通过成本控制降低产品价格等才能有更好的生存空间。

5. 结算部分

结算部分这块其实分两种情况，我们属于第二种：

• 一种是平台强势，比如阿里云等，基本需要客户预付费才能使用产品及服务，比如在下订单前就要进行费用支付或者充值，这种结算方式是最简单的。
• 一种是平台弱势，尤其是产品或者平台尚未得到大家认同前，就很难要求客户预费用支付。一般都是客户先使用或者体验，觉得符合自己的需求后，才愿意支付相应的费用。此时，都需要一个合同来保障和约束双方的权利和义务，并根据产品及服务使用情况（表现为订单），进行结算。

在第二种情况下，运营人员就要根据合同的结算周期，及时给客户发送账单、根据结算回款等。

6. 售后部分

就是客户服务的工作，处理解决客户使用产品和服务过程中的问题。任何一个最初接触运营的同事，基本都要兼职售后客服，解答客户使用产品过程中碰到的问题，尤其是产品不够完善的情况下。

7. 渠道部分

传统软件销售渠道：分销商、代理商、合作伙伴等渠道。

C端运营型渠道：各类平台渠道、大V合作、媒体等渠道。

B端运营型渠道：客户获取参考软件销售渠道、品牌宣传参考C端渠道。

8. 采购部分

由于为IAAS服务平台，需要及时更加业务需求进行物理服务器、存储、网络设备等进行采购，构建或者补充资源池。运营需要根据合同和订单情况，测算需要补充的资源，并提供相应的采购计划。IAAS服务真的是一个重资产的运营项目，这些设备的采购成本基本决定了产品服务的成本，运营一定要控制这些设备采购成本，才能使得业务能够长久的发展下去。

采购这块由于很容易存在滋生腐败想象，大部分公司都一套严格的采购流程来进行各种物资的采购。这些采购流程和制度是否合理很大程度上，决定着我们是否能够快速及合理拿到低成本的物资，而任何一家公司的采购或多或少都存在一些相关方的利益关系，很难通过自下而上的进行合理调整。

为此，这块笔者目前也没有更好办法，也常常被这些僵化的采购流程逼得火急攻心，甚至也在上面跌过大跟头，至今对物资采购心有余悸。

9. 营收部分

B端运营，需要进行成本管理、营收测算、现金流回款等运营收入相关的管理管控，以保障平台能够生存下去。

10. 活动部分

和C端运营活动类似，也是包括线下线上活动。线下活动就要考虑活动的规格、参加的大咖、活动的影响力及媒体传播等；线上平台活动如产品促销活动等。

说在最后

运营和产品一样，看似简单，入门门槛低，但是做好真是要付出很大的代价，所谓入门容易修行难啊。

作者：老格，擅长产品规划和设计，擅长解决方案，擅长PPT制作，是一个懂技术的产品PM，会设计的售前咨询。

本文由 @老格 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议