写点什么

远望资本程浩:做 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:252835

评论 2 条评论

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

雄安新区设立四周年,看天翼云以数字底座托起未来之城

天翼云开发者社区

企业在线产品宣传册应该如何设计?

小炮

产品宣传手册

VuePress 博客之 SEO 优化(六)站长工具

冴羽

Vue 前端 vuepress SEO 博客搭建

OpenHarmony 3.1 Beta版本关键特性解析——探秘隐式查询

OpenHarmony开发者

OpenHarmony 隐式查询

Gartner发布中国IaaS PaaS市场服务报告,天翼云强势入选

天翼云开发者社区

天翼云成为首个加入openGauss社区的运营商云

天翼云开发者社区

内存之旅——如何提升CMA利用率?

OpenHarmony开发者

内存 OpenHarmony

2022年最热门的招聘技术技能是什么,您绝对想不到

禅道项目管理

项目管理 开发技能

限量独家!濒危动物数字藏品免费发放!

百度开发者中心

开学季 | 飞桨AI Studio课程学习,小白也可以成为一名优秀的算法工程师!

百度开发者中心

一文来了解关于分布式锁的那些事儿

Linux服务器开发

redis 分布式 分布式锁 Linux服务器开发 Linux后台开发

DevOps落地思考

火线安全

DevOps 云原生 云安全 DevOps认证

融云直播 SDK 升级,让直播「PK」起来

融云 RongCloud

直播 IM 场景化

译文《Java并发编程之volatile》

潘大壮

并发编程 volatile 后端 Java EE

融云互联网通信安全揭秘之链路安全

融云 RongCloud

网络安全

安全Linux 内核提权漏洞分析

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 漏洞挖掘

墨天轮访谈 | Pika数据库陈磊:云时代下,键值数据库是否会被替代?

墨天轮

数据库 KV存储引擎 国产数据库

Rust 用于移动开发的几种方式

非凸科技

Java c++ Python rust 量化

信通院推出数字化赋能者新标准天翼云获评数字化转型赋能服务集体

天翼云开发者社区

以太坊的扩容革命:ETH2.0

不登山的小鲁

以太坊 扩容 Ethereum eth eth2.0

跑马灯带你深入浅出TextView的源码世界

vivo互联网技术

android 源码分析 TextView

长连接网关技术专题(七):小米小爱单机120万长连接接入层的架构演进

JackJiang

网络编程 websocket 即时通讯 网关 长连接

多场景推进 服务网格在联通的落地实践(下)

百度开发者中心

公有云市场百舸争流!天翼云稳居第一梯队,进入领导者象限

天翼云开发者社区

中台和多云管理是伪问题?运维要集体下岗了吗?

火线安全

DevOps 云原生 云安全

QoS 设计:车联网平台消息传输质量保障|车联网平台搭建从入门到精通 04

EMQ映云科技

物联网 IoT mqtt coap emq

Linux云计算之linux grep命令详解

学神来啦

云计算 Linux 运维 grep

春分耕种时,AI“现身”田间地头

百度开发者中心

Docker Build时的安全问题

火线安全

Docker 云原生 云安全 docker build

恒源云(GpuShare)_这个春天,GpuShare与你同行

恒源云

抗疫

百度希壤元宇宙平台上线首个汽车数字展厅,领克探索汽车营销新方式

百度开发者中心

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