查看原文
其他

Product-Led Customer Success 产品驱动的客户成功

hidecloud 潜云思绪 2021-12-22

 PLG? 

PLG (Product-Led Growth) - 产品驱动增长,是 SaaS 行业最近很火的话题。
随着 Notion、Figma 等产品的大热,一夜间几乎所有同行都在谈论自家产品是如何 PLG,或者即将要如何 PLG 的。
至于那些刚知道 PLG 概念的 CEO,则正在催促产品团队赶紧拿出一个 PLG 的方案,作为 2022 年公司的重要投入方向。
作为一个四年前从 toC 转型至 toB 的古典产品经理,这一幕真是似曾相识。六七年前 Growth Hacker - 增长黑客这个概念开始在国内火起来时,十来年前 Big Data - 大数据这个概念火起来时,几乎都和 PLG 目前在国内的情况一模一样。当时行业里有句话非常有意思:
“ Big Data is like teenage sex: Everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they are doing it too.” 
「大数据就像是青少年谈性:每个人都在聊它,但没有人真的知道如何做,可每个人都觉得其他人在做,因此他们都说自己也在做。」
因此我们看到,有从用户交互层面解读来证明自己是 PLG 的,也有从收费模式去论证自家属于 PLG 的。更有甚者会说,你看我们在市场与销售侧投入这么少,但规模还在涨,这除了 PLG 外还有其他可能么?
PLG 到底该怎么做,怎样的做法算 PLG,这是个太大的话题,也不是一个已经四年没做产品的人能够掌控的话题了。
但在 SaaS 行业经营客户成功体系的这四年里,我反倒是对于产品设计及运营如何助力客户成功,有了不少思考。那今天就借着 PLG 的热气,来聊聊我胡诌的一个新词:PLCS (Product-Led Customer Success) - 产品驱动客户成功吧。


 为什么要拥抱 PLCS? 

通常我们提到客户成功,脑子里想到的第一个角色肯定是 CSM (Customer Success Manager) - 客户成功经理,毕竟目前绝大多数的 SaaS 企业都配备了这一岗位。在招聘网站上搜索「客户成功经理」,出来的工作内容描述大多是这样的:

总结一下,关键工作内容大致如下:
  1. 维护客户关系
  2. 推动产品在客户侧的落地(实施部署)、持续使用(长期服务)
  3. 解决客户在使用过程中的问题
如果你对我们这个行业有所了解,那么这三件主要工作的日常状态大概就是——不断的与客户沟通:
这几乎是目前国内绝大多数公司在客户成功这个工作领域里唯一的投入,招一个 CSM,然后把签单后一切和客户有关的事都扔过去,大功告成。
大功真的告成了么?难说。当公司处在早期,产品复杂度不高、客户规模不大、公司内组织结构简单,几个高效的 CSM 确实能把客户关系和使用情况经营得有声有色。
但随着公司的发展,单款产品的复杂度不断变高、多条产品线并行、客户数以及所覆盖的行业及场景变多、公司内部门丛生,这些问题都会使得完全依赖 CSM 单点人力与客户多点人力对接的服务模式逐渐失效。从而产生如下问题:
  1. 产品变化太快,新功能太多,CSM 来不及学习每一个功能细节。
  2. 市场、销售、研发、产品,都有对客户调研、测试的需求,上面部门很多,但落地只有 CSM 一个,难以应付。
  3. 使用深度加深后,同时需要服务的客户企业内的员工数激增,如何解决他们的问题,以及日常触达他们,都成了难题。
  4. 增购或者交叉销售时,需要向客户论证产品为其带来的价值,时常讲得费力还不清晰。
  5. ……(欢迎在评论区留下你所在组织遇到的问题)
近半年,访谈并贴身顾问了十家不同领域的 SaaS 公司后,我开始反思这些问题出现的根源,真的只是因为 CSM 部门人力不足,或者人员能力不够么?在「客户成功」这个工作领域里,是否还应该有其他角色参与?
在与我所顾问的一支团队聊产品方案的过程中,因为一个功能设计上的讨论,我突然顿悟了一点:
在一家成熟的 SaaS 企业中,客户成功应该成为公司全领域的工作内容,每一个角色均应为之做出贡献,从各个视角完成客户成功工作最重要的目标——续约。
这里的「各个视角」,其中一个很重要的就是「客户-用户」两个视角。从前面总结的 CSM 常见工作内容可以看出,目前大部分 CSM 的工作对象仍然是「客户」,是一个由大量「员工用户」构成的虚拟实体。而面对这个对象,自然做的工作就会集中在企业运营上。
可真实世界里,企业这个虚拟的实体并不会真正做出续约的决策。一家企业要不要续约,最终还是由企业中一个个使用产品的员工,以及决策者从员工使用产品过程中创造的价值来进行判断。
这就需要我们不仅仅面向「客户」传递价值,也需要面向「用户」传递价值,才能把客户成功工作完整的做好。
简单来说,从上图可以看到当前 CSM 大多在做 toB (企业运营) 的客户成功工作,那么 toC (用户运营) 的客户成功工作该有谁来承担最合适呢?
有的公司目前有考虑这块工作,并且仍然由 CSM 来负责。可随着客户规模越来越大,需要运营的用户基数更是成倍上涨,因此在这上面的实际精力投入,以及效果,都非常有限。
而产品本身,作为与用户接触时间最长的触点,自然是最佳选择。如何利用产品设计及运营策略驱动用户侧的客户成功工作,我称之为 PLCS。


 从用户视角重新思考客户成功 

说了半天,这里定义的 PLCS 到底是什么呢?前文既然说到用户运营,那我们就围绕客户成功工作最重要的目标——续约——用 toC 用户运营常见的 AARRR 模型来分析一下,看看产品设计及运营机制在这其中能发挥哪些作用。
客户成功工作的主要目标是续约,续约是一个企业行为,对应到用户行为则可以看做是留存,如果能把企业内大部分用户的留存做好,那续约难度自然小了很多。因此在 AARRR 模型中,我们重点关注截止到留存的前面三步,后面顺带讲一下和收益有关的部分。

Acquisition - 获取用户

 定义 

这里的 Acquisition 与 SaaS 行业通常面向企业为对象所说的获客不是一件事,而是指站在客户成功工作的角度,在已经和一家企业合作的前提下,如何让企业内部更多的员工开始使用产品,从而增加用户基础,在客户内部形成更强的组织黏性。

 PLCS 如何做?

  1. 邀请机制

  2. 产品存在网络效应,或需要多人协作的产品。在前期体验过程中,通过正向激励或者在流程上设置障碍节点,让用户去邀请更多的其他用户参与进来。

    常见的做法有:

    1. 红包激励,粗暴,但在用户规模很大,需要各个企业快速完成冷启动的场景却很适合。


    2. 作品发布后,他人查看时,要求注册。这里有个小技巧是在产品界面上鼓励使用者直接使用链接分享,讲解其好处,而不是使用截图、导出文件的方式分享。从而增加接收者被转化的可能性。

    3. 屏蔽部分产品功能,需要企业内用户数到达某一水平后再开启。

  3. 便捷的批量账号创建工具

  4. 不少还不支持统一登录的产品,在冷启动时需要客户公司员工一一注册,或者由管理员、CSM 代为创建账号。费时费力不说,还往往因为一些特殊的需求而变得更为复杂。

    这时候如果在产品层面上能提供一个方便的账号批量创建工具,则能大大减轻产品在前期推广过程中的阻碍。

    通常这类工具需要考虑的需求有:

  • 权限分配(按角色、按部门)

  • 随机密码生成,安全通道发放

  • 面向管理员的激活状态监控

Activation - 用户激活

 定义 

一个走入成熟期的 SaaS 产品,往往沉淀了一路走来不同行业、不同场景、不同角色的需求。这直接造成系统过于复杂,新用户在上手期,往往会因为低易用度、缺乏价值获得感而逐渐弃用,如何帮助用户迈过这个门槛,理解产品价值,就显得尤为重要。

 PLCS 如何做?

  1. 落地引导 - 小细节,省大力

    1. 虽然新用户引导大部分产品都会做,但 C 端常用的点击引导式做法收效甚微。因为在企业服务软件中,用户更需要不是「怎么做」而是「为什么做」。重要功能更新时,放一个简单的场景介绍视频或海报,说清适用场景和价值,往往比功能引导式点击更有效。




    2. 围绕产品核心价值设立任务线,通过强提示,及适当的界面引导,确保新用户完整的体验到价值。比较常见于一些工具属性较强的产品,或者需要使用者付出一定的成本的产品(如绑定微信、手机号、银行卡、日历等)。

    3. 将庞大的使用、技术文档「拆散」,融入到产品中,在用户最需要、最恰当的场景里,提供对应的文档内容或入口。


  2. 最佳实践 - 行业实践

    有一类产品,我称之为 Meta product -「元」产品 :特指某些需要通过功能配置、组件拼装从而匹配各个企业不同需求的产品形态。

    其产品无法直接使用,而是需要用这个「元」产品,配置出在当前企业真的能用的产品。而这个配置工作很多时候是由实施或者 CSM 来做,不仅耗费人力,而且往往是一次性的。

    这时候可以引入行业模板、场景商店等概念,让普通用户也能直接参考本产品在行业里的最佳实践,并方便的引入到当前的工作中。




  3. 最佳实践 - 公司内实践

    另一类实践则来自于公司内其他同事在使用过程中的积累和分享。这种结合了本公司业务逻辑的沉淀,往往比上面提到的外部行业实践更为有价值,更容易让新用户体会到产品的价值。

    具体的做法可以是自定义模板、配置参数分享,又或者是直接使用其他用户配置完成后的结果。

    例如我最为熟悉的神策分析这款产品,其漏斗分析功能十分强大。但在使用上需要对公司的数据基础有了解,然后经过配置,才能看到结果,这使得不少新用户望而却步。

    而在产品上只需要将其他人创建出的漏斗进行展示,则没有经验的新用户也可立即从他人创建的漏斗中得到这个分析模型的价值。




Retention - 用户留存

 定义 

续约本质上就是留存,如果能把企业内大部分用户的留存做好,那续约自然不是问题。

 PLCS 如何做?

  1. 线上办公,营造社区感

  2. 人是社会性动物,如果一个产品对用户来说只是一个冷冰冰的工具,那么他不会投入更多的精力来深度使用,也不会认为这是一个虚拟的内部办公空间。

    但这里说的营造社区感,并不是说要在产品里加个论坛或者留言区。社区的核心是交流,那么在一款 SaaS 产品里有什么可以交流?很多人没想到的是 SaaS 产品本身的不少产出物也可以作为交流的内容。

    例如一个文档工具,只要不是加密不可见的,企业/部门/项目内部新创建的文档,在首页自动对全员公开最新动态,能够促进同事间的交流。也让用户对这个区域产生了期待,会时不时回来看看有什么新东西。

    再例如一个自动化营销工具,可以将所有在跑的计划放到公共看板里,让全员都知道现在在运行的计划有哪些,其表现如何:

    因此可以看出在 SaaS 产品内营造社区感,主要是要做到:

  • 有一个公共广场/空间/推送通道,可以看到其他人在做什么

  • 某种方便的机制能把工作中的过程产物和结果方便的分享出来

  • 参与者可以方便的在内容发布和消费两个角色中切换

  • 酒香也怕巷子深,产品价值前置露出

  • 不少 SaaS 产品在功能丰富起来后,其信息架构往往非常严谨,一级导航接着二级导航,主菜单接着子菜单,有的功能和信息可能到了某个具体页面都还得再点几下才能出来。

    这是产品设计上犯的一个典型毛病,就是没对用户进行分群,设计对象不具体,就只能把所有的功能、流程都堆到一起。作为一个普通用户,几乎不可能掌握产品的每个细节,直接造成的问题就是价值感知不强,除了自己熟悉的几个操作外,找不到频繁回访的理由。

    一旦弄清楚产品内不同角色的定位后,可以通过重新组织 UI 界面,或采用 Dashboard 的形式,来将不同角色用户所需要的功能和信息提到更容易访问的入口。

    例如 思码逸 Merico,他们是一家基于深度代码分析,为研发团队提供一站式软件工程数据分析平台。从功能模块以及能提供的有价值信息上来看,有代码当量分析、迭代质量分析、工程质量分析、项目进度分析。

    但 CTO、项目经理、技术总监、工程师这四个不同角色在日常关注的层面上肯定不一样。如果仍然按照一级导航、二级导航的方式将功能规整起来,那么不同角色要想在不同模块中寻找自己需要的功能和信息就变得非常复杂。其实有时候复杂都不可怕,最担心的是用户根本不知道还有哪些功能和信息对他有用。

    因此清晰定义出角色后,就能围绕其需求进行常用页面的布局调整,从而使得产品的价值体现得更充分,用户也有更多理由频繁回访:

    再比如思码逸 Merico 有一个智能分析功能,能够根据当前的项目表现情况给出一些管理动作建议,这个信息非常有价值。但这个建议之前只能在一个二级页面里的图表模块那才能找到。

    产品设计讨论中,我提到能不能将这个智能分析结果直接前置到首页去,甚至后面效果更加确定后,直接把每天的智能分析结果通过邮件、短信等形式自动推给技术管理者。毕竟这些建议这才是产品价值,而不是打开产品这个动作。大多数具备智能分析、建议功能的产品,都可以从这个角度考虑试试。


    Revenue - 获得收益

     定义 

    客户成功在收益上主要体现在增购和交叉销售上,前面讲到的用户激活和留存做好,增购通常是水到渠成的事,而交叉销售过往则更多依赖于销售或 CSM 的主动营销,或者商机挖掘。但如果产品上可以考虑更多,则这部分能够更具规模化的来做出效果。

     PLCS 如何做?

    1. 新产品试用
    2. 如果新功能或者新产品使用门槛不高,且单用户也能体验,不需要整个组织参与。那么其让销售和 CSM 一个个地去拜访对接人,介绍新产品。不如在产品里直接开放新产品的试用入口,让用户自由体验。
      这样一方面扩大了新产品、功能的销售对象范围,而新产品、功能不一定是之前对接人所负责的领域,有时候他觉得没用的功能,也许在其他用户那里确实很实用的。
      另一方面这也不失为一种给 CSM 持续提供增购商机的方式。



     写在最后 

    从上面这些例子可以看出,客户成功工作,在 SaaS 企业规模变大后,变得不再只是单一部门的工作职责所能覆盖。其解法即可以是在客户成功部门内扩充角色,也可以是全员参与客户成功工作。
    今天聊到的只是 PLCS,那么 Marketing-Led 行不行呢?Sales-Led 呢?Engineering-Led 呢?
    忘掉部门界限,回归公司之所以要做客户成功的初心——通过价值传递与价值落地,让客户与用户感知到产品价值,从而能够长期续约——其实每个角色都能在这个目标里贡献许多。
    欢迎各位读到这里的读者,在下方留言区发表你的看法。


     往期文章▼ 
    SaaS - Solution as a Service
    告别,开始
    潜潜静听,在这喧闹世界摘取一个故事给你听
    潜潜静听,在这喧闹世界摘取一个故事给你听(第二季)

     作者介绍▼ 

    张涛 - hidecloud
    三年媒体运营,八年产品设计&运营,四年企业服务管理经验,最近一段职业经历为神策数据副总裁。
    目前 gap year 中,同时也为 4 家 SaaS 公司提供管理顾问服务,帮助其解决产品 PMF、交付体系组织和流程建设、售前体系搭建中出现的问题。
    业余时间于北京、重庆两地推广鸡尾酒与苏格兰威士忌文化,目前已举办四次线下活动。
    : . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存