写点什么

远望资本程浩:做 To B,一定要避免 9 类错误!

  • 2020-08-03
  • 本文字数:6999 字

    阅读完需:约 23 分钟

远望资本程浩:做To B,一定要避免9类错误!

售后服务≠客户成功、难获客户/用户真实需求、难以满足碎片化需求……

To B 红火,可坑也不少。大鹏学社学员、远望资本创始合伙人程浩结合自身工作经历,分享并总结了「To B 创业的 9 类主要错误」,既受到广大创业者的欢迎,也成为了资本圈难得的经验输出和积累。

InfoQ 获授权转载,全文如下,敬请欣赏!同时也欢迎有志者加入大鹏学社,与程浩线下交流,共同前进。


最近几年 To C 创业红利消失,很多人开始关注 To B,特别很多从业者是从互联网的 C 端业务转去做 To B。我在这里总结出做 To B 业务最易犯的 9 类致命错误,希望能让大家在创业的路上少走弯路。

To B 产品卖出只是开始,售后服务≠客户成功

第一类想强调的错误是,To B 获客不易,企业决不能以做 To C 业务那样简单的售后服务形态,来处理 To B 业务。


To C 业务是把东西卖出去了,消费者收到货。或者把 APP 上传到应用市场,用户下载安装后使用,就完成了价值交付。


但对 To B 来讲则不然,卖出去产品仅仅是一系列工作的开始。要实现产品价值,还有漫长的过程。首先你得把实施交付做好。有时候因为客户的认知有限或者 IT 水平有限,你还得手把手的教会对方怎么用。对于 SaaS 类产品,如果产品没有使用,明年就一定不会有续费和留存。


大家知道 B 端获客周期长,获客成本高。能否维护好客户关系,让客户在下一年继续订阅产品,是企业发展成败的关键。


所以为了能够让客户续费,除了专业的交付服务,基本有一定规模的 To B 公司,还会有一个部门叫客户成功。这个部门就是要针对客户留存,展开维护工作。


比如产品售出后,作为客户成功部门,我一定会观察用户到底有没有使用产品,记录每天、每周、每月用了多少次。如果我发现客户平常每天登录 5 次,最近 3 天仅登录了 1 次。


那客户成功部门立刻就会去了解客户发生了什么:


  • 是不是遇到了一些挑战?

  • 我们的产品是不是易用性做的不够?

  • 还是你们公司业务有了一些新变化?


客户成功部门必须要第一时间杀过去,要 make sure 客户把产品用起来。不管是提供咨询、服务,还是需要提供培训,必须要确保客户持续使用产品。


所以与 To C 完全不同,客户成功绝不是售后服务这么简单的事儿。对于 To C 端,售后服务就是退换货,如果用户卸载了你的 APP,老实说你也没有太好的补救办法。只要消费者不到淘宝投诉、不到应用市场给产品差评,这个就 OK 了。


但对于 To B 产品尤其是 SaaS 类产品,都非常依赖于 recurring revenue,就是客户留存带来的持续性收入,例如客户按年或季度付费。所以 To B 对于留存的重视程度,远比 To C 要高很多,要做的工作也重很多。


打一个类比来说,对于 SaaS 类产品收入的重要性,相当于一个 APP 的 DAU 的重要性,也等同于一个电商的 GMV 重要性。你的客户续费率高,收入留存好,说明你的产品做得好,产品有粘性,产品的迁移成本高,竞争对手打不进来。


一句话,能否留住客户是衡量 SaaS 类公司能否持续做大的关键指标。

难获真实需求,主观臆想易犯低级错误

第二类想强调的错误是,以 To C 心态做 To B,往往会主观臆想用户的需求,这个错误更可怕。因为 To C 创业者,大多数情况下自己就是核心用户。所以在定义用户需求中,不会犯特别低级的错误,例如我当年做迅雷,我自己就是核心下载用户。但对于 To B 来讲,大多数情况下创业者自己不是核心用户,你满足的是别人的需求,所以你对需求的把握天然就要远很多。


而且在 To B 业务流程里面,有些感觉反常的地方,其实还有他自身的合理性。因为 To B 业务的痛点经常是在工作场合的一个特定场景下产生的。这时候也很难通过传统的调研、观察的方法去获取。所以做 To B 业务,一定要在需求探索和客户访谈中多花几倍的精力,详细了解对方到底要什么,以及什么是最刚需的。否则你做出来的产品可能只是“你觉得”对方需要的。除此之外,To B 还复杂在,To B 客户的决策者和使用者还经常不是一类人。

决策人与使用人不同,难以两头讨好

To C 往往购买者和使用者是同一人,做 To B 一定要区分客户的决策者和使用者。


因为大多数企业软件,他的决策人跟使用人往往不是同一拨人。决策人通常是这项业务的负责人或者公司老板,使用人通常是他的下属。当然决策人也不是完全不用,可他用软件的频率肯定会比较低。例如一周看个报表,一个月看看进展。


所以如果你只搞定了部门负责人或老板是不行的。虽然老板是决策买单的人,但如果老板发现我下面的人根本用不起来,他以后绝不会续费。


因此这两拨人都要搞定,既要让老板买单肯定你产品的价值,又要让下面的人真正使用起来,让产品在客户的企业里创造价值。这就凸显了前面提及的客户成功部门的重要性。


还需要注意,决策人和使用人有时候利益是冲突的。举个最简单的例子,比如说钉钉。钉钉跟微信最主要的一个功能区别,就是聊天中的【已读】。在钉钉上,老板在群里发的信息,他是知道谁看谁没看的。如果你是老板,你肯定需要这个功能;但如果去问员工,员工肯定不想要这种被监视的感觉。


还记得钉钉惹恼小学生被怒刷差评吗,也是典型决策人和使用人的冲突。所以对于 To B 端的产品经理,在产品设计时到底该偏向哪头,这是个比较有意思的权衡。

缺乏耐心,To B 创业注定周期长

做 To C 产品,有爆发性增长的机会。举个最简单例子:滴滴打车仅用 3 年就冲上了 100 亿美元市值。在大家惊叹之余,这个记录随后又被拼多多打破了。拼多多是 3 年就干到了 300 亿美元,而且现在不足 5 年时间,市值已超 1000 亿美元。


这种速度,只有在 To C 领域才能发生,在 To B 里面是不可能的(当然有特殊,后面讲)。


To B 都是线性增长的。假若我今年做到了 3000 万收入,明年做 5000 万,后年做 8000 万,每年增长百分之几十,就已经是很不错的 To B 企业了。


原因也很简单:首先,如上已提及,企业的真实需求的获取,To B 就要长一些,那自然研发速度也就跟着慢下来;到了采购阶段,To B 用户决策流程也会偏长,导致你的获客周期就会比较长;通常客单价越高的产品,客户决策周期越长;到了交付产品的时候,To B 还有一个实施周期的问题。


所以 To B 的创业节奏相对于 To C 一定会慢很多,很少听到哪个 To B 公司 3 年就独角兽的,因此做 To C 的人转行去做 To B,心态千万不能崩,不能急于求成。


当然获客周期和实施周期,对于 To B 来讲还算是小问题,更大的问题是定制化。

项目制深坑,用标准化产品满足碎片化需求

碰到大的项目,很麻烦的一点是,对方会有很多定制化的需求。你只想提供标准化产品,人家大客户不买单。如果屈从做定制呢,面临的风险是,团队可能就全搭进去了。往往会从一个产品公司,变为项目制公司。对企业来说,虽然定制化服务也能挣钱,但很难实现规模化。


所以浩哥认为企业服务的核心壁垒是:要用标准化产品满足碎片化需求。


当然 C 端也有这个问题,微信的张小龙说过一句挺有意思的话:全中国有 1 亿人在告诉我怎么做微信。其实他说的就是这个道理:每个人都有这种碎片化需求。但相比之下,C 端的碎片化需求和标准化之间的冲突,并没有 B 端这么明显。


在 B 端,每个客户企业的业务流程,面临的经营环境和要解决的实际问题都是不同的。企业服务的竞争力核心,就是如何尽量用标品、尽量用产品化的方式,来解决用户不同的问题。产品化做的好,你实施可能就 2 星期;产品化做的不好,可能是 2 个月;如果产品化做的很烂,这事你得做半年。


这个对团队的消耗可是天壤之别,所以说产品化、标准化非常重要。在这里我引用好友神策数据桑文锋的一个观点:解决客户的问题,能用产品解决,就不要用服务解决,能用服务解决就不用咨询解决。咨询工作尽量服务化,服务工作尽量产品化。因为一旦你的模式越来越依赖于高阶的人力,企业一定很难规模化。


大家听懂了吧,在服务客户的过程中,不要图省事直接把客户的需求当成一个“项目”做,而要把需求抽象为一个产品功能:想想用户提的这个需求是不是一个通用需求,或者哪类客户可能有同样的需求,甚至未来这个需求能不能独立包装成一个可收费的模块。你这样去做,性价比一下子就变高了,否则的话每个项目你都单独定制,你的公司慢慢就做成了项目制公司。


针对这点,浩哥想强调,所谓标准化不仅仅要体现在产品上,还要体现在销售上:一名真正好的销售,不仅仅要能把产品卖出去,让客户买一个很大的单。而是还要能够说服客户,在前期放弃或者推迟一些个性化需求。


比如你会跟客户讲,您这个需求我觉得很有道理,但是研发有周期,产品上线可能半年之后了。咱们能不能先上线解决您最紧迫的问题?至于您刚提的这个需求,未来我们在 2.0 版本里给您做个免费升级。


这样才是好销售。而不是说客户什么需求,都尽量去满足。客户是高兴了,那产品经理和研发可就郁闷了。而且接了几个这样的项目,你的团队资源就全被消耗投入进去了。大家都在项目里,谁还有精力打磨标准化产品?这样的企业就会被销售牵着鼻子走,成为了项目制的公司,很难做强做大。


所以想做标准化产品,这不仅仅是产品经理、研发的任务,同时也是销售的任务。

重产品,轻销售

谈及销售,这里要特别说一下,To C 的人做 To B 业务,经常犯的一个错误就是:重产品、轻销售。为什么这么讲?我过去讲过,To C 创业公司的老板,都是首席产品经理;To B 创业公司老板,都是首席销售。


以前做惯了首席产品经理,再去做 To B 服务,自然会重产品、轻销售——但这绝对是一个很大的风险。因为对 To B 业务来讲,最早的 pilot customer 都是 CEO 自己卖出去的。你如果只重视产品不重视销售,前期启动都很难。


还有一个影响在于,如果过于产品导向,你公司就难建立起来为客户服务的文化。大家知道阿里的文化,客户第一是排在首位的。其他互联网公司,很少有说客户第一的,为什么阿里这么说?


因为阿里最开始就是一个 To B 公司。2007 年 11 月,阿里最早于香港上市时,上市的主体就是 B2B 业务。所以阿里深知客户第一对 To B 业务的重要性。


如果产品和技术做老大,销售文化往往不够狼性。举一个简单的问题,当客户的一个需求,你认为不对时,是客户需求优先,还是你自己产品优先?因为不是销售背景出身,往往就不会以客户需求和客户服务为第一导向。这其实这不利于 To B 公司的发展。


我们心目中的优秀的 To B 团队,一定是销售和产品能力互补的团队。甚至希望一把手就是超级 Sales。这个道理不难理解:拿美国来说,企业软件的老大都是销售出身。从创办甲骨文公司的 Larry Ellison,到 Salesforce 的老大 Marc Benioff,到 Siebel 的创始人 Thomas Siebel。


所以我们标准的 To B 创业公司 CEO 的画像就是 8 个字——行业老炮+超级销售。

To B 是价值敏感,To C 是价格敏感

对于做惯 To C 业务的人,搞 To B 上来就喜欢免费。免费行不行?不是完全不行,但是在大多数情况下,To B 免费不一定是好事。


我们之前也做 To B 端的采购,我跟大家分析一下心理。首先作为客户,我买你的软件,你告诉我免费。我第一个就会想,有没有陷阱,比如你把我的数据泄露出去赚钱,我会有这方面的担心。此外更主要的隐忧是,你给我免费,那你公司靠什么生存呢?


采购方最担心的就是他的服务提供方哪天挂了,我好不容易实施完了,用上了你们的产品。结果没两个月,你们公司经营不善倒了。这对我打击太大了,我跟我老板没法交代。就像所有的硬件公司都会压榨他的供应链,但绝对不会希望供应链死掉的道理一样。


所以对于 To B 业务,我宁肯付费给你钱,但是要求你必须给我提供最好的服务,所以 To B 是价值敏感,To C 是价格敏感。


什么叫价值敏感?假设我们公司采购 HRM 软件,我会跟人力总监说,你帮我找几套适合我们公司的产品。可能有 A、B、C 三套备选,然后通过试用对比后,我们会总结,每个产品有哪些功能,哪些功能对我们最有用,然后打分。根据评分,可能选出来了 A。


大家听明白了?我们到这个时候,并没有考虑价格的问题。我只考虑价值,哪个产品对我公司最有价值。我绝对不会因为 B、C 年费比 A 少几万,就改为 B 或 C,当然我也会让 HR 同事努力去把 A 谈到 B、C 的价格。


所以企业采购从来不是谁便宜我采购谁的,一定是谁对我最大价值采购谁,价格会放在第二位。这跟 To C 很不一样。To C 对价格有相当大的敏感度。比如苹果的产品质量再好,但因为贵,必然会丧失一定的客户。


总结一下就是:To B 对价值的敏感,远远高于对价格的敏感。

To B 绝不能忽视,组织能力的建设

To C 人转型做 To B 还易掉的一个坑,是忽视团队建设和组织能力的打造。通常来讲:To B 对组织能力的要求比 To C 更高。


在这里援引腾讯咨询李晓红的一个观点:To C 的用户需求相对标准化,3-5 个人的小团队如果能切准用户需求,就有机会做出爆款。所以 To C 业务的价值链比较短,通过产品就能完成用户价值的交付,因此团队就可以比较轻,对组织能力的要求相对而言没有那么高。


To B 业务的价值链就长很多,首先做好产品本身就不容易,因为客户个性化需求多。其次光做好产品还不行,还需要销售、服务、客户成功等多部门的协同配合,这就对组织能力提出了更高的要求。


所以做 To C 业务要更注重发挥个体的创造力,做 To B 业务要注重基于流程的执行力。需要打造围绕客户的端到端流程型组织,以保障服务品质和价值交付。


桑文锋在他新书《企业服务从 0 到 1》中也写道:产品要经历可用、可卖、规模化三个阶段。特别是规模化,最早买你产品的都是关系户,所以从服务几个客户扩展到大规模,也是考验你的组织能力。

To B,先服务大 B 还是小 B?

对于很多初创企业,先服务大 B 还是小 B,这是一道送命题。


大家知道,2015 年是中国的 To B 元年。当时以纷享销客、销售易、Teambition 为代表,切入点都是想做 SME 中小型企业。因为当时大家还是 To C 思维,追求用户数量,忽视了用户质量。特别这个阶段,很多投企业服务类项目的,都是之前投 To C 的 VC,习惯了按客户数量给估值。


但很快这些做 To B 服务的“前浪”创业者们就发现,SME 一是付费能力比较弱,二是死亡率高。特别是如果你的客户都是互联网创业公司,会发现很多公司根本撑不过 1 年。


在前面我们已经提及过,To B 产品\SaaS 类产品,都非常依赖于 recurring revenue,就是客户留存带来的持续性收入。在前期的合作中你投入了大量的资源促成了这个单,但如果只服务一年,那你有可能是亏损的。


所以当时这些做 SME 的 To B 企业活得都很艰难。很多人不禁反思:是不是在中国不能做 SME?大家又都开始转型,针对政府和付费能力很强的传统企业做大 B 的生意。


做大 B 的好处是,客户方有钱,信誉比较高,可能拖一点账期,但不会不给你,同时对你的品牌有帮助。像现在很多在人工智能领域体量做得比较大的公司,它们的重要收入其实都是安防。安防基本上全是大 B,都是政府买单,客单价都是几百万甚至上千万。


但做大 B 的缺点就是个性化需求太多,通常越大的项目个性化需求越多,但创业公司看在钱的份上还得满足他,不然人家不买单或者不结款。但你要是满足了了他,连续接几个单后,你会发现有所有人都投入到项目中去了,就没人做产品了,所以这是一个矛盾。


现在浩哥感受到了一些苗头,很多做 To B 的企业又开始重视做小 B 了。这要归功于移动互联网的普及,让民企老板们的 IT 水平提高了。很多管理人员,开始习惯于用手机,习惯了在微信(企业微信)或者钉钉上管理员工、阅读报表。


做小 B 的好处是产品标准化程度高,没有个性化定制。但是坏处也很明显,就是小 B 付费能力弱,因此你必须得把获客成本降下来,所以要做小 B 的生意首先要考虑通过已有的平台获客,可以是微信、企业微信,也可以是钉钉或者飞书。


这点非常重要,一定要用巧劲,要善用平台的流量红利,把获客成本降下来,同时实现业务的快速增长。


所以做小 B 还是大 B,各有利弊,也各有各的打法。

One More Thing…To B 业务 To C 化

最后谈一点观察,希望对大家做 To B 业务有所启发。


浩哥发现这两年涌现了一些 To B 的公司,他们的打法其实和 To C 的很像。最典型的代表就是 Zoom。Zoom 的每日会议参与者,已经从去年 12 月的 1000 万人,飙升到了现在的每月 3 亿人。虽然这个数据不是 DAU,但这样的增长速度和爆发性同样非常恐怖。


Zoom 为什么能爆发?当然有疫情的原因,但是更本质的原因就是 Zoom 虽然是个 To B 产品,但他的打法和 To C 非常像 —— 例如产品直接下载即可使用、没有实施成本、也没什么销售成本。收费方面,采用 Freemium 模式,基本功能免费,靠增值服务收费。


而且 Zoom 的获客,还有一个很牛的,几乎所有的 To B 公司都没有的优势 —— 他们有天然的病毒式营销的属性。例如浩哥就给 Zoom 带来了很多客户。我是一年多前就开始用 Zoom。因为做投资,我在北京,很多其他城市的项目,大老远让人跑一趟过来不合适。让我飞过去,我又有点懒。怎么办,咱们先 Zoom 一下。


我跟大家约 Zoom 会议的时候,对面的团队绝大部分人都是第一次使用。他们用过感觉不错,公司内就可以用起来,还会推荐其他人使用。大家听懂了吧?这就是病毒式获客,ToB 也可以病毒式获客!


当然不是所有 To B 的项目都能 To C 化。这和 To B 的业务属性有关,Zoom 是视频会议系统,足够通用、足够标准化、足够独立,同时还非常轻。


客观讲大部分的 To B 的项目是不能 To C 化的,因为大部分项目还是会有获客周期,还是会有实施成本,会涉及到跟企业内部数据、内部流程的对接,甚至还有一些个性化需求,这些是很难用 To C 化的方法去操作的。


你作为一个 To B 的创业者,可以找一找你的业务里面,有没有一些类 Zoom 的打法能够借鉴,如果有的话,也许你就找到了一条快车道。


2020-08-03 10:252803

评论 2 条评论

发布
用户头像
我司是也有汽车行业SAAS的产品,文章所说的问题,我们全都遇到了。
2020-10-26 14:51
回复
用户头像
有些问题没回答啊
2020-09-30 08:32
回复
没有更多了
发现更多内容

学习新语言步骤(有其他语言基础前提)

周周

大数据知识专栏 - Zookeeper的Shell操作

小马哥

大数据 zookeeper ZooKeeper原理 28天写作

CSS12 - 清除浮动

Mr.Cactus

html/css

DevSecOps:把合规融入DevOps

啸天

DevOps 安全 法律 DevSecOps 应用安全

CodeDay#5 启动报名| 带你深入探索支付宝终端动态化实践

蚂蚁集团移动开发平台 mPaaS

小程序 mPaaS 2021年度技术盘点与展望 热门活动

云原生动态周报 |华为云主导抗疫药物筛选科研成果"神农项目"登上国际化学顶刊封面

华为云原生团队

GitHub 疫情 云原生 Prometheus 华为云

区块链即时通讯系统开发方案,IM聊天社交软件开发

v16629866266

2020中国云计算生态峰会召开 浪潮云摘得三项大奖

浪潮云

云服务

Redis学习笔记01:SDS 简单动态字符串

架构精进之路

redis 七日更 28天写作

2020DevOps状态报告

禅道项目管理

DevOps 运维 开发 趋势 自动化测试

2020DevOps状态报告——平台模型:扩展DevOps的新方法

禅道项目管理

DevOps 运维 开发 趋势 自动化测试

专科出身Java开发,2年进入苏宁,5年跳槽阿里,我晋升这么快的秘诀是什么?

Java架构追梦

Java 阿里巴巴 面试 架构师 成长路线

华为云张昆:支持全场景全业务,GaussDB加速企业数字化转型

华为云开发者联盟

数据库

代码编译时自动完成白盒测试,这真的可以

华为云开发者联盟

c++ 测试 代码 框架

Python 使用SQLServer

IT蜗壳-Tango

七日更

anyRTC-语音连麦demo上线

anyRTC开发者

音视频 WebRTC 直播 实时语音 语音聊天室

再谈跨界 互联网+的建筑行业

张老蔫

28天写作

云上独享资源池 自主灵活更安全

浪潮云

产品推荐

Java单例7种测试实践

叫练

单例模式 单例 手写单例 饿汉式 懒汉式

关于2020 我有12个关键词

浪潮云

阅读

前端代码书写规范

Mr.Cactus

大前端 html/css

链上智能合约APP开发|链上智能合约系统软件开发

系统开发

智联招聘的微前端落地实践——Widget

智联大前端

大前端

重学JS | 异步编程 Promise

梁龙先森

大前端 编程语言 28天写作

初识 D3.js :打造专属可视化

vivo互联网技术

JavaScript 数据分析 可视化 图表 D3

2021,加料!

浪潮云

云原生 工业互联网

5 天开发接口系统技术小结

老魚

laravel 建站 接口开发 28天写作

CSS11 - 浮动

Mr.Cactus

html/css

浪潮云防勒索一站式解决方案,让勒索病毒“上云”无门

浪潮云

产品推荐

关于“存在”的一点思考

石君

28天写作 量子 世界为何存在

前端大佬们都在推荐的“绿宝书”你值得拥有

华章IT

JavaScript typescript 大前端 web开发 犀牛书

远望资本程浩:做To B,一定要避免9类错误!_行业深度_远望资本_InfoQ精选文章